Executive Summary The National Vulnerability Database has become foundational infrastructure for cybersecurity.

Its continuing importance, however, depends upon adapting it to a computing environment fundamentally different from the one in which vulnerability databases were originally developed.

The principal recommendation of this response is straighfforward:

NIST should evolve the NVD from a primarily record-oriented vulnerability database into the authoritative foundation of a federated, machine-readable vulnerability intelligence ecosystem capable of supporting continuous, contextual, and increasingly automated vulnerability management.

This does not require replacing CVE, NVD, CVSS, CPE, CWE, SBOM, SSVC, CISA KEV, vendor advisories, or established vulnerability-management practices. Those mechanisms constitute the foundation upon which the next generation should be built.

The significant change is context.

A vulnerability’s technical characteristics do not by themselves establish its operational importance. The same vulnerability may represent relatively little risk in an isolated system and an immediate critical risk when accessible through an Internet-facing service or an autonomous

AI agent possessing consequential delegated authority.

The next generation of vulnerability management therefore needs to connect:

Vulnerability → Product/Component → Dependency → Environment → Identity/Authority → Capability → Runtime Evidence → Potential Consequence → Response.

NIST does not need to collect an organization’s sensitive operational context or perform all of these analyses within the NVD. Rather, the NVD should provide sufficiently :mely, structured, trustworthy, provenance-aware, and interoperable vulnerability intelligence so organizations and their security systems can perform contextual analysis locally.

Artificial intelligence can substantially improve vulnerability discovery, enrichment, correlation, prioritization, and remediation. But probabilistic AI output should not automatically become authoritative vulnerability information merely because it can be produced at machine speed. AI recommendations should carry provenance, supporting evidence, uncertainty, and appropriate human review.

The attached Enhanced Agentic Security Architecture — 2026 Revision provides additional technical context for recommendations involving autonomous agents, Agent Bills of Materials, Capability Graphs, behavioral analysis, runtime contracts, consequence propagation, evidence chains, and human escalation. Those concepts are referenced where relevant below but are intentionally not repeated in detail.

1. Vulnerability Management Process

1(a). Where are the biggest bottlenecks that could be improved with greater AI-enabled automation?

The most significant bottlenecks are no longer simply vulnerability discovery. They occur throughout the process of transforming a vulnerability disclosure into information sufficiently accurate and contextualized to support action.

AI-assisted automation is particularly appropriate for:

• correlating information from CVEs, vendor advisories, security researchers, exploit intelligence, and other authoritative sources;
• extracting affected products, versions, configurations, and dependencies from unstructured
• normalizing product identification;
• proposing CPE and CWE mappings;
• generating preliminary severity and prioritization recommendations;
• identifying inconsistent or contradictory vulnerability information;
• correlating vulnerabilities with SBOM components;
• identifying dependency relationships;
• detecting duplicate or related vulnerability reports;
• monitoring for new exploitation evidence;
• identifying records requiring expert attention.
• authoritative sources conflict;
• vulnerability status is disputed;
• affected-product identification is uncertain;
• an AI-generated enrichment materially changes severity or scope;
• evidence is insufficient;
• the vulnerability presents exceptional national, infrastructure, or operational consequences;
• an automated action could itself produce substantial disruption.
• provenance of AI-generated enrichment;
• confidence and uncertainty;
• reproducibility;
• model or system version where relevant;
• source attribution;
• modification history;
• conflict resolution;
• human override;
• independent quality assurance.
• publication-to-ingestion latency;
• enrichment latency;
• high-priority enrichment;
• correction latency;
• affected-product completeness;
• provenance completeness;
• API reliability;
• synchronization with authoritative sources.
• new vulnerability publication;
• affected-product changes;
• new exploitation evidence;
• addition to CISA KEV;
• revised severity;
• vendor mitigation;
• patch availability;
• withdrawal or dispute;
• material correction.
• actual software and hardware components;
• dependencies;
• services;
• APIs and tools;
• identity and authorization relationships;
• AI-agent components;
• runtime state;
• observed exploitation evidence;
• downstream consequences.
• assets;
• software components;
• versions;
• dependencies;
• configuration;
• exposure;
• identity;
• privilege;
• authorization;
• business criticality;
• compensating controls;
• runtime activity;
• observed behavior.
• vulnerability scanners;
• SBOM systems;
• asset-management systems;
• vendor advisories;
• threat intelligence;
• security operations plafforms;
• configuration-management systems;
• remediation systems;
• cloud security systems;
• emerging autonomous cybersecurity systems.
• remediation identification;
• patch selection;
• configuration correction;
• code remediation;
• test generation;
• compatibility analysis;
• deployment planning;
• verification.
• remediation policy;
• authorization;
• testing;
• deployment;
• exception management;
• verification;
• rollback.
• least privilege;
• deterministic authorization;
• independent policy enforcement;
• sandbox or preproduction testing;
• staged deployment;
• rollback capability;
• monitoring;
• evidence collection;
• independent verification.
• incomplete asset inventories;
• inaccurate affected-product information;
• unknown dependencies;
• unclear system ownership;
• compatibility concerns;
• downtime requirements;
• insufficient test environments;
• legacy systems;
• unclear remediation evidence;
• difficulty determining whether mitigation actually removed exposure.
• continuous asset discovery;
• reliable software inventories;
• SBOMs where appropriate;
• dependency information;
• configuration management;
• identity and authorization;
• test capability;
• rollback mechanisms;
• continuous monitoring.
• automated validation;
• cross-source reconciliation;
• stronger provenance;
• explicit confidence where appropriate;
• better affected-product information;
• consistent versioning;
• correction history;
• machine-readable evidence relationships.
• agent components and dependencies;
• machine capabilities;
• delegated authority;
• tool and MCP dependencies;
• runtime behavioral evidence;
• downstream consequence relationships;
• remediation evidence.
• :mely;
• complete;
• normalized;
• versioned;
• provenance-aware;
• confidence-aware where appropriate;
• event accessible;
• interoperable;
• easily correlated with SBOMs and asset inventories;
• suitable for automated contextual analysis.
• scalable AI-assisted enrichment;
• stronger quality assurance;
• near-real-:me enrichment;
• improved affected-product information;
• stronger provenance;
• event-driven updates;
• high-availability APIs;
• federated enrichment;
• improved SBOM interoperability;
• contextual prioritization support;
• remediation evidence;
• support for agentic-system dependencies.
• continued rapid growth in vulnerability disclosures;
• AI-assisted vulnerability discovery;
• AI-assisted exploitation;
• increasingly automated attack chains;
• AI-generated remediation;
• autonomous defensive agents;
• autonomous operational agents;
• agent-to-agent interaction;
• MCP and other agent/tool protocols;
• dynamic delegated machine authority;
• increasing use of behavioral security;
• machine-speed vulnerability decisions;
• increasing competition for human security attention.
• CVE publication-to-NVD availability;
• :me to initial enrichment;
• :me to priority enrichment;
• percentage of records with reliable affected-product information;
• enrichment accuracy;
• correction latency;
• provenance completeness;
• API availability;
• API latency;
• synchronization latency;
• machine-readable completeness;
• unresolved enrichment backlog;
• percentage of high-priority vulnerabilities processed within established service objectives;
• adoption and interoperability among downstream security systems.

disclosures;

NIST should increasingly employ a machine-first, human-governed enrichment process.

AI should perform high-volume correlation and preliminary analysis. Human expertise should be concentrated on uncertainty, conflicting evidence, novel conditions, high-consequence decisions, and quality assurance.

The goal should not be replacing analysts. It should be using automation so scarce expert attention is applied where expert judgment contributes the greatest value.

1(b). Which tasks are appropriate for AI automation, and which should require human review?

AI is well suited to collection, extraction, classification, correlation, normalization, preliminary enrichment, anomaly detection, dependency analysis, and prioritization recommendations.

Human review should remain important when:

Human reviewers should receive a compact evidence package containing the underlying sources, provenance, AI confidence or uncertainty, conflicting evidence, proposed changes, and the reason the case was escalated.

This should support human review by exception rather than requiring humans to repeat work already performed reliably by machines.

1(c). What novel governance and risk-management considerations should be taken into account?

AI introduces a distinction between generated information and authoritative information.

NIST should establish policies addressing:

An AI system should not become authoritative simply because its output is fast or plausible.

AI also creates an emerging governance problem involving human attention. As automated vulnerability systems scale, they may generate more findings, recommendations, exceptions, and alerts than people can meaningfully evaluate.

Human attention should therefore be treated as a constrained security resource. Automation should distinguish between events that can be handled automatically, events that should be logged, events requiring notification, and exceptional events requiring human judgment.

1(d). What other actions should improve vulnerability management?

NIST should establish measurable service objectives for:

NIST should also measure whether vulnerability information leads to better security outcomes rather than relying principally on the number of records processed.

2. Vulnerability Information Dissemination

2(a). What capabilities, products, and processes are needed?

Vulnerability information should increasingly operate as machine-readable infrastructure rather than primarily as documents read by people.

APIs and downloadable feeds should remain fundamental, but important changes in authoritative vulnerability information should also be capable of event-driven dissemination.

Examples include:

Security plafforms should not have to wait for periodic manual review to learn that the risk associated with a vulnerability has materially changed.

The objective should be:

Authoritative change → machine-readable distribution → local correlation → risk reassessment → appropriate response.

2(b). What standards are most useful, and where are the gaps?

CVE, CVSS, CWE, CPE, SSVC, SBOM-related specifications, CSAF, VEX, and related standards provide a substantial foundation.

They should be preserved and made more interoperable.

The largest emerging gap is not another vulnerability identifier. It is the ability to associate vulnerability information with operational context.

Future standards need better mechanisms for connecting vulnerabilities to:

These relationships do not all need to reside in the NVD. NIST should define or support interoperability mechanisms that allow organizations to make these associations locally.

2(c). What other dissemination actions should NIST take?

NIST should encourage a federated vulnerability intelligence ecosystem.

NVD should remain an authoritative standards-based national resource, but it should not be expected to originate every useful piece of vulnerability intelligence.

CNAs, software vendors, open-source projects, CISA, researchers, commercial providers, and other trusted sources should be able to contribute interoperable information with explicit provenance.

NIST’s role should increasingly include establishing the trusted standards and technical

architecture that allow those sources to operate as an interoperable ecosystem.

3. Risk Assessment and Prioritization

3(a). How can AI and automation improve contextual risk prioritization?

This is potentially the most important application of AI to vulnerability management.

Technical severity is not equivalent to operational risk.

A useful prioritization process should combine information such as:

technical severity + exploitability + active exploitation + exposure + affected asset + dependency + privilege/authority + compensating controls + runtime evidence + potential consequence.

AI is particularly useful for correlating these heterogeneous information sources at a scale that would be impractical for human analysts.

For autonomous AI environments, context becomes still more important. A vulnerable tool used by an isolated experimental agent presents a fundamentally different risk from the same vulnerable tool available to an autonomous production agent possessing credentials and authority to modify consequential systems.

The NVD should provide the standardized vulnerability information necessary for these determinations while organizations perform environment-specific calculations locally.

3(b). How can transparency and auditability be enhanced?

AI-assisted prioritization should produce an explainable decision record, not merely a score.

For consequential prioritization decisions, systems should preserve:

Evidence → Source/Provenance → Analytical Method → Confidence/Uncertainty → Recommendation → Human Modification, if any → Final Decision.

An analyst should be able to determine why a vulnerability received its priority and which facts would cause that priority to change.

3(c). What data and system context do organizations need?

Organizations require accurate information concerning:

For autonomous-agent environments, this should extend beyond conventional SBOM information.

The attached Enhanced Agentic Security Architecture proposes an Agent Bill of Materials (ABOM) describing the model, harness, tools, skills, MCP servers, APIs, memory systems, execution environments, and other dependencies associated with an agent.

It also proposes a Capability Graph representing relationships such as:

Agent → Identity → Credential → Tool → API → Data → System → Other Agent.

NIST does not need to maintain these organizational graphs. NIST should ensure its vulnerability information can be reliably correlated with them.

3(d). How can NVD improve interoperability?

NVD should maintain stable, documented, high-availability machine interfaces allowing vulnerability information to integrate directly with:

Identifiers, schemas, :mestamps, provenance, status changes, and affected-product information should be consistently machine interpretable.

3(e). What additional improvements should be made to prioritization?

NIST should support consequence-aware vulnerability prioritization.

Traditional severity scoring largely describes characteristics associated with a vulnerability and its exploitation. Organizations increasingly need to determine what happens aper successful exploitation.

The attached architecture describes a concept called Cascade Horizon: evaluating how the consequences of compromise could propagate through dependencies, credentials, tools, agents, systems, data, and business processes.

The distinction is useful:

Blast radius asks: What can this event directly affect?

Cascade Horizon asks: Where can the consequences propagate next?

NVD need not calculate Cascade Horizon. It should provide information sufficiently structured to enable organizations and security tools to perform that analysis.

4. Remediation Development, Deployment, and Monitoring

4(a). What mechanisms and procedures are necessary for automated remediation, and what role should AI have?

AI can substantially assist with:

Automated remediation should be proportional to consequence and reversibility.

A low-risk, well-understood, reversible remediation may appropriately proceed automatically.

A remediation capable of affecting critical production systems should require stronger validation and potentially human authorization.

4(b). What organizational structures are required for AI-generated remediation?

Organizations need clearly assigned responsibility for:

AI-generated remediation should enter existing secure change-management processes rather than creating an uncontrolled parallel process.

4(c). What safeguards are necessary?

Important safeguards include:

One particularly important principle is:

An AI system should not generate a consequential remediation, authorize its own deployment, execute it, and then serve as the sole authority declaring that it succeeded.

Independent controls should verify consequential outcomes.

4(d). What are the biggest barriers to remediation?

Major barriers include:

Better vulnerability information alone cannot solve all of these problems, but better machine- readable affected-product and dependency information can significantly reduce them.

4(e). What prerequisites are required for automated remediation?

Organizations need:

Agentic environments additionally require discovery of agents, tools, APIs, MCP servers, memory systems, and delegated authority.

4(f). What additional remediation improvements are recommended?

NIST should encourage standardized machine-verifiable remediation evidence.

A mature vulnerability-management system should be able to establish:

Vulnerability identified → affected system confirmed → remediation authorized → remediation executed → outcome verified → residual exposure reassessed.

“Patch deployed” should eventually become a verifiable state rather than merely an administrative assertion.

5. Vulnerability Data and Standards

5(a). What changes are needed to improve vulnerability-data quality?

Improvements should include:

AI can assist substantially, but automated enrichment should remain distinguishable from independently validated authoritative information.

5(b). Are existing identifiers, product naming, and scoring systems sufficient?

They are necessary but not sufficient.

CVE, CPE, CWE, CVSS, SSVC, and related mechanisms should remain foundational.

The missing element is increasingly operational context.

Severity describes the vulnerability.

Risk also depends on where the vulnerable component is located, whether it is exposed or accessible, who or what can access it, what authority is available, whether exploitation is occurring, what compensating controls exist, and what consequences can follow.

NIST should therefore extend contextual interoperability rather than attempt to replace established identifiers.

5(c). What gaps exist?

Important emerging gaps include standardized representation or interoperability for:

NIST should work with existing standards organizations and industry rather than unnecessarily creating competing standards.

5(d). What information is required to manage increasing vulnerability volume?

The increasing number of vulnerabilities makes automated relevance determination essential.

Organizations need sufficient information to rapidly determine:

1. Is the affected product present?

2. Is the affected version present?

3. Is the vulnerable functionality reachable?

4. Is it exposed?

5. Is exploitation known or likely?

6. What assets or capabilities are associated with it?

7. What would successful exploitation make reachable?

8. What action is appropriate?

The scalable model is therefore:

Machine filtering → Contextual correlation → Risk prioritization → Automated action where appropriate → Human judgment by exception.

5(e). What changes are needed to machine-readable vulnerability data?

Machine-readable vulnerability information should increasingly be:

Changes to authoritative records should themselves be machine readable so downstream systems can determine what changed without repeatedly reprocessing complete records.

5(f). What additional actions should NIST take?

NIST should convene vulnerability authorities, standards organizations, vendors, researchers, open-source communities, security-tool providers, AI developers, and enterprise practitioners to identify the minimum interoperable contextual information required for machine-speed vulnerability management.

The objective should be interoperability, not centralization of all operational data within NVD.

6. Development Processes

6(a). How can organizations integrate AI-enabled tools into technology development?

AI-enabled vulnerability management should be integrated throughout the system lifecycle:

Architecture and design → Coding → Dependency selection → Build → Testing → Deployment → Runtime monitoring → Vulnerability discovery → Remediation → Verification.

AI can assist with threat modeling, static and dynamic analysis, dependency analysis, fuzzing, code review, vulnerability discovery, remediation generation, test creation, and verification.

Processes and standards should distinguish between:

AI recommendation and authorized system change.

Development organizations should retain independently enforced controls governing what AI systems are permitted to change, particularly in production environments.

AI should make secure development faster and more comprehensive without eliminating accountability.

7. Vision for the NVD

7(a). What is the value of the NVD?

The NVD’s enduring value is trust combined with standardization.

Organizations, researchers, software developers, government agencies, and security products depend upon a common foundation for identifying and characterizing vulnerabilities.

That role becomes more important—not less important—as automated systems consume vulnerability information.

The future value of NVD therefore extends beyond its human-facing website.

NVD should increasingly function as trusted national machine-readable cybersecurity infrastructure.

7(b). What capabilities should be integrated during the next five years?

Priorities should include:

7(c). What emerging trends should NVD anticipate?

NVD should anticipate:

One of the most important changes will be the transition from vulnerabilities affecting relatively static software environments to vulnerabilities affecting systems capable of autonomously acting upon other systems.

7(d). What capabilities will enhance NVD utility?

NVD will provide its greatest value by becoming easier for other systems to consume, correlate, verify, and act upon.

It should provide the trusted vulnerability foundation while allowing specialized government, commercial, open-source, and enterprise systems to perform environment-specific analysis.

NVD should therefore optimize for:

trust + :meliness + interoperability + machine readability + provenance + accessibility.

7(e). What metrics should measure success?

NIST should consider metrics including:

The ultimate metric should not simply be how many vulnerability records NVD processes.

The more meaningful question is:

How quickly and reliably does NVD information enable affected organizations and security systems to identify, prioritize, and reduce real cybersecurity risk?

Conclusion The NVD should not be replaced. Its role should be expanded and modernized.

The existing vulnerability ecosystem has successfully created standardized mechanisms for identifying and describing vulnerabilities. The next challenge is making that information sufficiently :mely, contextual, interoperable, and machine readable to support cybersecurity in an environment increasingly operating at machine speed.

The progression should be:

Vulnerability identification → Trusted machine-readable information → Affected-component correlation → Operational context → Runtime evidence → Consequence analysis → Appropriate automated response → Human judgment where required.

Three principles should guide modernization.

First, preserve trust. AI can accelerate enrichment and analysis, but authoritative vulnerability information must remain evidence-based, provenance-aware, auditable, and subject to appropriate validation.

Second, enable context without centralizing it. NIST does not need an organization’s internal asset, identity, authorization, behavioral, or business information. NVD should provide standards and machine-readable vulnerability intelligence allowing organizations to combine

authoritative vulnerability information with their own operational context locally.

Third, design for autonomous computing. Increasingly capable AI agents will consume vulnerability information, make security recommendations, initiate remediation, and potentially act upon consequential systems. Vulnerability infrastructure must therefore support machine- to-machine operation while maintaining independent security controls and accountable human authority.

The attached Enhanced Agentic Security Architecture — 2026 Revision provides a technical model showing how authoritative vulnerability information can interact with Agent Bills of Materials, Capability Graphs, runtime behavioral monitoring, independent policy enforcement, Cascade Horizon consequence analysis, evidence-based verification, and an ATention and Escalation Interface.

Those capabilities should not all become functions of the NVD.

Instead, the NVD should become the trusted information foundation that enables them.

That distinction provides a practical path forward: preserve what has made the NVD valuable, modernize the mechanisms through which its information is created and distributed, and make that information capable of supporting the increasingly automated and autonomous cybersecurity environment of the next decade.

Supporting Attachment Enhanced Agentic Security Architecture — 2026 Revision: A Runtime, Behavioral, Evidence- Based, Human-Governed Security Architecture for Autonomous AI Agents.

References FIRST. Common Vulnerability Scoring System (CVSS). The established framework for standardized characterization of vulnerability severity.

Cybersecurity and Infrastructure Security Agency (CISA). Known Exploited Vulnerabilities Catalog. Provides authoritative evidence identifying vulnerabilities known to be exploited in the wild.

MITRE and the CVE Program. Common Vulnerabilities and Exposures. Provides standardized

identifiers forming a fundamental component of the vulnerability-management ecosystem.

Ng, Albus W.; Han, Yi; Zhang, Jusheng; and Wang, Wenhao. Agent Safety Should Be a Runtime Contract. arXiv:2608.11274, August 2026. Provides supporting research concerning preventive and evidential runtime controls, agent trajectories, and evidence-based verification.

McAteer, Dan. The Evolution of the Agent Harness. Latent Space, August 22, 2026. Provides supporting analysis concerning the evolution of agent harnesses and the emerging attention- interface governing the boundary between increasingly autonomous agents and human authority. The Evolution of the Agent Harness Wiz. Model Context Protocol (MCP) Security Best Practices Cheat Sheet. Provides industry guidance concerning security of emerging agent-to-tool interfaces, including authentication, authorization, least privilege, server trust, and tool-related security considerations.

3Q26 Enhanced Agentic Security Architecture August 24, 2026. Submitted as an attachment to this response. Provides the technical basis for the ABOM, Capability Graph, runtime behavioral analysis, independent policy enforcement, Cascade Horizon, Evidence Chain, and ATention and Escalation Interface concepts referenced in this response.

Prepared by: Dennis C. Hayes dennis.hayes@spartansfirst.org 864-982-9681