Agentic AI Has a CVE Problem. Here is What Changes Next.

Your Vulnerability Scanner Cannot See Your Agent Risks

On April 29, 2026, the Cloud Security Alliance announced that its CSAI Foundation has been authorized as a CVE Numbering Authority through MITRE, with a scope explicitly aimed at agentic AI components. The same week, the CSA published a research paper that formalized something most security engineers building with AI agents had already noticed in private: agent vulnerabilities are not landing in the CVE database, and the scanners pulling from NVD are blind to a growing class of production risk.

The paper calls it the AI Agent Disclosure Vacuum. It documents what the authors describe as the "silent bounty" pattern, where researchers report a vulnerability to an AI vendor, receive a payout, and then nothing publishes. No CVE, no advisory, no entry that downstream defenders can act on. The vendor reclassifies the issue as a "product limitation" rather than a security defect, which is not a category that triggers any disclosure obligation.

This matters because most enterprise vulnerability programs are still wired to a single source of truth: NVD feeds into your scanner, your scanner produces a Jira ticket, and your SLA clock starts. If the underlying issue is in your LLM agent's tool-use behavior or in a third-party MCP server you mounted last week, none of that machinery fires.

Why CVE Was Not Built for This

The CVE program was designed in 1999 for software flaws with three properties: a clearly identifiable vendor, a reproducible defect, and a patchable version. None of those hold cleanly for agentic systems.

Take attribution. When a Claude-powered agent running on AWS Bedrock invokes an MCP server hosted by a vendor, which then calls a tool exposed by your internal API, and the chain produces an unauthorized action because of prompt injection in a customer email, who owns the CVE? The model provider did not ship a defect in the model weights. The MCP server vendor will say the customer configured it incorrectly. The agent framework will say it followed instructions. The CSA paper captures this directly: "Agentic systems are compositional, non-deterministic, persistent, and delegated."

Take reproducibility. A prompt injection that succeeds against claude-sonnet-4-6 on a Tuesday may not succeed against claude-sonnet-4-7 on a Friday, and may not succeed at all if the agent's system prompt has been reordered by 200 tokens. NVD analysts cannot validate a payload that depends on the runtime composition of context. They send the report back.

Take patchability. There is no version bump for "the agent is now better at refusing." Mitigation is a guardrail, an eval threshold, a tool-scoping policy, or a context filter. None of those map cleanly to "upgrade to 1.4.7."

The result is the gap. Vendors who do treat agent issues as security defects often run private bounty programs and ship silent fixes. Vendors who do not are not breaking any rule.

The Working Taxonomy: OWASP Top 10 for Agentic Applications

Until the formal CVE pipeline catches up, the practical taxonomy that has gained adoption is the OWASP Top 10 for Agentic Applications, released in December 2025 and built from input across more than 100 contributors. The categories use the ASI prefix:

• ASI01 Agent Goal Hijack
• ASI02 Tool Misuse and Exploitation
• ASI03 Identity and Privilege Abuse
• ASI04 Agentic Supply Chain Vulnerabilities
• ASI05 Unexpected Code Execution
• ASI06 Memory and Context Poisoning
• ASI07 Insecure Inter-Agent Communication
• ASI08 Cascading Failures
• ASI09 Human-Agent Trust Exploitation
• ASI10 Rogue Agents

The CSA paper proposes that NVD eventually integrate this taxonomy as a recognized weakness category, similar to how CWE classifies traditional defects. That work has not landed yet. In the meantime, ASI codes are useful as internal labels for triage and for the security review section of an architectural decision record.

The single most important design principle in the OWASP framework is the principle of least agency. Give an agent the minimum autonomy, the minimum tool scope, and the minimum credential reach required for the task. Most of the ASI categories above degrade gracefully if least agency is enforced at the runtime boundary, and degrade catastrophically if it is not.

What CSA as a CNA Changes

The CNA designation gives CSA the authority to assign CVE IDs within an agreed scope. The announcement also covered the acquisition of two specifications, the Autonomous Action Runtime Management spec contributed by Vanta, and the Agentic Trust Framework transferred from a research group. Together, these provide candidate technical hooks that a CVE record can reference, things like "the agent's runtime authorization layer failed to enforce scope boundary X," which gives an analyst something concrete enough to validate.

What this does in practice over the next 12 to 18 months:

1. Agent framework maintainers and MCP server vendors finally have a CNA willing to assign IDs for issues that traditional CNAs decline. Expect the first agentic CVEs to surface within weeks of CSA's CNA scope going live.
2. The CSA STAR for AI assurance program gives auditors something to ask for during diligence. If your vendor cannot articulate where their agent fits in the AICM control set, that is an answer.
3. Organizations that have been tracking agent issues in private spreadsheets get a path to publish, which raises the floor for everyone.

What this does not do: it does not retroactively fix the silent bounty problem, and it does not force any vendor to disclose. If you are deploying agents in production and assuming a CVE will warn you, the assumption is still wrong.

A Practical Tracking Pattern: OSV for Agent Vulnerabilities

Here is the pattern we use with teams that need to track agent vulnerabilities internally before the public ecosystem catches up. The OSV schema is broader than CVE. It is the format Google uses for osv.dev, it supports custom database prefixes, and it allows arbitrary database_specific fields. It fits agent-style vulnerabilities much better than waiting for NVD.

A minimal internal record for an ASI06 style memory poisoning issue against a customer support agent looks like this:

{
  "schema_version": "1.6.0",
  "id": "FRAKINTERNAL-2026-0042",
  "modified": "2026-04-30T14:00:00Z",
  "summary": "Memory poisoning via crafted ticket body in support-agent v0.9.2",
  "details": "An attacker submitting a support ticket with a specifically structured payload can persist instructions into the agent's long-term memory store, causing follow-up sessions for unrelated users to leak ticket metadata into outbound replies.",
  "affected": [
    {
      "package": {
        "ecosystem": "internal",
        "name": "support-agent"
      },
      "ranges": [
        {
          "type": "SEMVER",
          "events": [
            { "introduced": "0.9.0" },
            { "fixed": "0.9.3" }
          ]
        }
      ]
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://internal.security.example/advisories/2026-0042"
    }
  ],
  "database_specific": {
    "owasp_asi": ["ASI06", "ASI09"],
    "agent_framework": "claude-sonnet-4-7",
    "tool_scope_at_time_of_finding": ["zendesk:read", "zendesk:reply"],
    "mitigation_type": "guardrail",
    "eval_added": "support-agent/evals/memory-isolation-2026-04-30.yaml"
  }
}

A few things to notice. The id uses an internal prefix because there is no CVE yet, and OSV explicitly permits this. The database_specific block is where the agentic context lives, the OWASP ASI categories, the model version at finding time, the tool scopes the agent had, and a pointer to the eval that was added to detect regression. The mitigation_type field is the most important one. If it says guardrail or prompt, the fix is non-deterministic and your eval coverage matters more than the version bump. If it says code or scope, the fix is reproducible and you can treat it like a normal patch.

We have teams running this format in a private S3 bucket gated by KMS and pulling it into their SIEM as a custom feed. The point is not the bucket. The point is that you do not need permission from MITRE to start treating agent issues as first-class security findings.

A Pre-Deployment Gate List for Agentic Systems

Before any new agent or any new agent tool reaches production, run through this:

1. The agent's tool list is documented, scoped to the minimum required, and bound to a separate IAM role with no inherited privileges from the calling user.
2. There is at least one eval per ASI category that applies to the agent's surface area, and the eval threshold is wired into the deploy pipeline. Failing evals block the rollout.
3. Memory or context stores are isolated per tenant, encrypted at rest with a customer-managed key, and have a clear retention boundary.
4. Inter-agent calls, including any MCP server calls, traverse a network policy that is deny-by-default. If an agent reaches a new endpoint, an alert fires.
5. The agent framework version and the model version are pinned, and the deployment record captures both. When an issue is reported, you can identify the exact composition.
6. There is an internal advisory channel using a format like the OSV record above, and ASI-tagged issues are reviewed weekly.
7. The runbook for "agent did the wrong thing in production" exists, has been tested, and includes a kill switch that revokes the agent's IAM role without a deploy.

Most of these are not novel. They look like the same controls a security engineer would apply to any privileged service account. That is the point. Treat the agent as a service account with a wide scope and a probabilistic decision layer, because that is what it is.

The Broader Point

The CVE database has been the connective tissue of vulnerability management for a quarter century, and a lot of compliance frameworks quietly assume it works. For traditional software, it mostly does. For agentic systems, the connective tissue does not yet reach. The CSA's CNA designation is a good signal that the gap is being addressed, but the gap is real today, and the right response from any team running AI agents in production is to stop waiting for an external feed to surface agent risks. Build the internal telemetry, write the evals, label findings with a working taxonomy, and treat the agent as the privileged actor it actually is.

For a related read on vendor and supply chain risks specifically, see our piece on the AI gateway supply chain lessons from the LiteLLM incident, and for the deployment side of secured AI infrastructure, the AWS Bedrock HIPAA deployment guide.

Kai is a security engineer at Fraktional. We build secure AI systems for teams in regulated industries, with a bias toward owned infrastructure, evals as gates, and small surface areas. The most useful question we ask in the first week of any engagement is: what does this agent have the credentials to do, and who would notice if it did all of it.