Table of Contents

Reach SOC 2 Compliance in 6 Weeks or Less.

  / Prompt Injection: AI’s Biggest Security Risk

Prompt Injection: AI’s Biggest Security Risk

When researchers found that Microsoft 365 Copilot could be tricked into leaking corporate data from a single email, the flaw got a clean public identifier: CVE-2025-32711, severity 9.3. When a bug hunter coaxed ChatGPT into producing valid Windows product keys by framing the request as a guessing game, it got nothing. 

Both were prompt injections. Only one is trackable. That Vulnerability Tracking Gap in AI Security, and what it costs defenders, is the subject of this article.

What Is a CVE and Why Does It Matter for Software Security?

A CVE (Common Vulnerabilities and Exposures) is a unique public identifier for a specific software flaw. It gives the whole industry one name for one bug, so a researcher in Berlin and an analyst in Bahrain know they mean the same thing.

The Role of MITRE’s CVE Program in Traditional Vulnerability Management

The CVE program is run by the MITRE Corporation, a US nonprofit. Since 1999 it has assigned hundreds of thousands of IDs, each tied to a discrete, reproducible defect in a defined product and version.

A CVE is the connective tissue of coordinated disclosure: a researcher reports the flaw, the vendor patches it, the ID is published, and defenders map it to their own assets. Without that shared label, the same bug ends up with three names and no clear owner.

The National Vulnerability Database (NVD) and CVSS Scoring

The National Vulnerability Database, maintained by NIST, enriches each CVE with a CVSS (Common Vulnerability Scoring System) score from 0 to 10. That lets teams triage: a 9.3 jumps the queue, a 4.0 waits.

Why Prompt Injection Breaks the Traditional CVE Model

The CVE model assumes a bug lives in code, sits in a version, and can be fixed. Prompt injection violates all three.

Prompt Injection as a Class of Attack, Not a Discrete Bug

Prompt injection smuggles instructions into the data an LLM reads, so the model follows the attacker rather than the user. OWASP ranks it as LLM01, the top entry in its 2025 Top 10 for LLM Applications. It is a property of how language models work, not one line of faulty code, so you cannot file a CVE against it.

A SQL injection either works or it does not. A prompt injection might succeed nine times in ten, fail on the eleventh, then stop working after a silent model update, which makes the “reproducible” part of reporting genuinely hard.

Model Versioning vs. Software Versioning

Software has clean version numbers. A weight update to a hosted model can ship silently, with no version a researcher can cite. Two calls to “gpt-4o” a week apart may not behave the same way, and there is no changelog to point at.

Why “Patching” an LLM Differs From Patching Code

Patching code closes a specific hole. A developer rewrites the faulty line, ships the diff, and the exploit path is gone for good. That clean, binary, auditable loop is the entire premise on which the CVE system rests. “Patching” a model offers none of it. There is no single line to fix, because the behavior the attacker abused is the same behavior that makes the model useful: it reads text and follows instructions. A vendor’s only levers, retraining, hardening the system prompt, or wrapping the model in input and output guardrails, all lower the odds of a successful attack rather than removing the possibility.

The fix reduces the success rate from 80 percent to 5 percent and marks it as remediated. The hole is narrower, not closed.

The recent record shows how thin that margin is. EchoLeak got past Microsoft’s dedicated cross-prompt-injection classifier by hiding its exfiltration channel in reference-style Markdown that the filter did not recognize, and the AgentFlayer exploit slipped through OpenAI’s URL safety check by routing stolen data through trusted Azure Blob Storage links. Each guardrail worked against the obvious version of the attack and fell to a rephrasing. There is a tuning tax on top of that: crank the filters too tight and the model starts refusing legitimate work, so vendors settle for a balance point rather than elimination. 

The practical takeaway is to treat “we’ve addressed this” as risk reduction, not closure.

SOC 2, ISO 27001 and HIPAA done for you. Fixed fee, 100% audit pass rate.

Audit-ready in 6 weeks. Not 6 months.

The Current State of AI Vulnerability Tracking

Several frameworks exist. None is a true registry of individual, citable prompt injection vulnerabilities.

OWASP LLM Top 10 and the LLM01 Classification

The OWASP GenAI Security Project’s LLM01:2025 entry is the most cited reference point. It is a category, not a catalog: it does not enumerate specific incidents with IDs.

MITRE ATLAS for Adversarial AI Threats

MITRE ATLAS is an ATT&CK-style knowledge base of adversarial tactics against AI systems, documenting 16 tactics and more than 80 techniques with real-world case studies as of late 2025. It maps how attacks work, but is not a per-vulnerability ledger with scores.

AVID (AI Vulnerability Database) and Its Limitations

AVID, run by a nonprofit, is the closest thing to a dedicated AI vulnerability database, cataloging failure modes with reproducible evidence. But it leans on community submissions, skews toward bias and broader failure modes, and notes that the definition of an “AI vulnerability” is itself still a working one.

Vendor-Specific Disclosures vs. Industry-Wide Registries

Disclosure happens vendor by vendor. OpenAI patched the Windows-key jailbreak server-side; Microsoft fixed EchoLeak and issued a CVE. There is no common venue where these land side by side.

 

The Consequences of No Shared Threat Registry for Prompt Injection

Fragmented Disclosure Across AI Vendors

Each lab discloses on its own terms, on its own blog, if at all. A defender protecting a multi-model stack has to monitor a dozen channels and hope nothing slips by.

Duplicate Discovery and Wasted Research Effort

Researchers rediscover the same attack repeatedly. The guessing-game jailbreak, the “dead grandma” trick, and other framing attacks are variations on one theme nobody numbered.

No Standardized Severity Scoring for LLM Attacks

CVSS was built for deterministic flaws. There is no agreed way to score an attack that is probabilistic and context-dependent, so “how bad is this” has no common answer.

Slower Defender Response Times

Without a feed to subscribe to, teams learn about LLM attacks from news and conference talks rather than a structured alert.

Challenges for Enterprise Risk Assessment and Procurement

Buyers cannot ask a vendor, “which known prompt injection issues affect your product, and are they fixed?” the way they can with CVEs. That makes enterprise risk assessment and procurement an exercise in trust rather than evidence.

Why a CVE-Like System for Prompt Injection Is Hard to Build

Reproducibility Challenges Across Model Updates

A CVE entry promises that anyone can reproduce the flaw. That guarantee is what lets a researcher verify it, a vendor confirm it, and a defender test whether their own systems are exposed. A hosted model breaks the promise on both ends. The same prompt can fail on the eleventh attempt because of normal sampling variance, and the weights themselves can change between Tuesday and Wednesday with no version bump to point to. A proof of concept that worked at disclosure may quietly stop working a week later, not because anyone fixed it, but because the model drifted. An identifier is only as useful as the thing it points to, and here the thing keeps moving.

Closed-Weight Models and Disclosure Asymmetry

With closed-weight models from OpenAI, Anthropic, Google, and others, only the lab sees the internals. Outsiders report behavior; the provider decides what to confirm and disclose. That puts the entity with the most information in sole control of how much reaches the public, and the incentives do not favor openness. Confirming a flaw invites scrutiny, while a silent server-side fix attracts none. A neutral registry depends on independent parties being able to validate and publish, and closed weights leave them able to observe symptoms but never inspect the cause.

The Blurred Line Between Bug, Feature, and Misuse

Is a model following an instruction inside a document a bug, or is the feature working as designed? A registry needs a clear yes or no on “is this a vulnerability,” and prompt injection rarely offers one. The model is doing exactly what it was built to do: read text and act on it. Whether that counts as a defect depends entirely on context the model cannot see, namely, whose instruction it was and whether the user wanted it followed. That ambiguity also gives vendors an easy out, since “working as intended” is a defensible label for behavior nobody can cleanly call broken. A catalog cannot index something the industry will not agree to name.

Shared Responsibility Between Model Providers and Application Developers

A prompt injection usually turns dangerous only when an application wires the model to tools, data, and actions through RAG, connectors, or agents. Responsibility is split between the provider and the developer, and neither side owns the whole failure. The model provider can argue the model behaved normally, and the integration was unsafe; the developer can argue they were relying on the model to resist manipulation. Both have a point, which is precisely the problem. With no clear owner, there is no clear party to file the disclosure, assign the severity, or ship the fix, and the issue falls into the gap between them.

SOC 2, ISO 27001 and HIPAA done for you. Fixed fee, 100% audit pass rate.

Audit-ready in 6 weeks. Not 6 months.

Proposed Frameworks for an AI Threat Registry

Extending CVE to Cover Model-Level Vulnerabilities

One option is to stretch the existing CVE schema to cover model behaviors, accepting probabilistic, version-fuzzy entries. It reuses trusted infrastructure but strains reproducibility norms.

Creating a Dedicated Prompt Injection Disclosure Standard

Another is a purpose-built standard with its own identifiers, severity model, and reproducibility rules, designed for non-determinism from the start.

Lessons From CVE Numbering Authorities (CNAs) Applied to AI Labs

The CVE program already delegates ID assignment to CNAs (CVE Numbering Authorities), often the vendors themselves. AI labs could become CNAs for their own models, issuing identifiers under shared rules, as Microsoft does for Copilot.

Coordinated Vulnerability Disclosure (CVD) for LLMs

Underpinning all of it is Coordinated Vulnerability Disclosure: agreed timelines, safe harbor for researchers, and a standard report format adapted to AI’s quirks.

 

What Enterprises Can Do Until a Registry Exists

Building Internal Prompt Injection Threat Catalogs

Keep a catalog of every injection technique that affects your deployed AI, with prompts, conditions, and mitigations, so you are not rediscovering attacks each quarter.

Subscribing to AI-Specific Threat Intelligence Feeds

Follow AI security research as a dedicated intelligence stream, not incidental news. Outlets like Wired and academic preprints on arXiv tend to surface novel attacks well before any vendor advisory does.

Participating in AI Red Team Communities

Red teaming is the only reliable way to know how your specific stack fails. Testing against your own guardrails, RAG pipelines, and agents finds issues no external list would hold.

Tracking OWASP, MITRE ATLAS, and AVID Updates

Treat OWASP’s LLM Top 10, MITRE ATLAS, and AVID as your standing reference set and check them on a schedule.

Pro Tip: Map your internal catalog to ATLAS technique IDs and OWASP LLM categories as you build it. When a real standard arrives your records translate instead of needing a rebuild, and meanwhile auditors get a recognized vocabulary to assess against.

Pro Tip: Map your internal catalog

Map your internal catalog to ATLAS technique IDs and OWASP LLM categories as you build it. When a real standard arrives your records translate instead of needing a rebuild, and meanwhile auditors get a recognized vocabulary to assess against.

The Path Forward: Standardizing AI Vulnerability Disclosure

Industry Collaboration Between AI Labs, Researchers, and Regulators

No single lab can run a credible cross-vendor registry; rivals will not report into a competitor’s database. It needs a neutral steward, plausibly MITRE or a NIST-backed consortium, with labs participating as authorities.

Regulatory Pressure From the EU AI Act and NIST AI RMF

The EU AI Act imposes obligations on high-risk and general-purpose AI, including incident reporting, while the NIST AI Risk Management Framework and ISO/IEC 42001 push toward documented, auditable AI risk processes. Structured disclosure is the natural next requirement.

A Call for a Public AI Vulnerability Database

The destination is a public, neutral, AI-native vulnerability database: shared IDs, a severity model built for probabilistic attacks, and disclosure rules every major lab signs onto. We are not there yet, so everything above is a stopgap.

 

Conclusion

Prompt injection is the top-ranked risk in AI security and the least trackable. It earns a CVE only when it surfaces inside a discrete product; the model-level root cause and server-side fixes leave no public trace. Until the industry builds an AI-native registry with a severity model fit for non-deterministic attacks, defenders must stitch together OWASP categories, ATLAS techniques, AVID entries, and their own catalogs. Build that internal catalog now. It is the one piece you fully control.

Frequently Asked Questions

Is there a CVE for prompt injection?

Sometimes. When it manifests in a specific product, like EchoLeak in Microsoft 365 Copilot (CVE-2025-32711) or CurXecute in Cursor (CVE-2025-54135), it can receive a CVE. The general attack class against language models has none.

Because it is a class of behavior, not a discrete code defect. It is probabilistic, it can break across silent model updates, and it often has no single fix, all of which clash with the reproducibility a CVE assumes.

AVID is the nearest dedicated database, while OWASP’s LLM Top 10 and MITRE ATLAS are the dominant classification frameworks. None is a complete, citable registry of individual vulnerabilities.

Inconsistently. Some patch silently server-side, some publish blog write-ups, and some issue CVEs when the flaw sits in a versioned product.

No. ATLAS catalogs tactics and techniques, not individual scored vulnerabilities, so it complements a CVE-style registry rather than replacing one.

Possibly. AI labs could act as CVE Numbering Authorities, but the non-deterministic nature of prompt injection makes full coverage unlikely without a purpose-built standard.

Axipro Author

Picture of Pedro Dias

Pedro Dias

Pedro has been writing online for over 10 years. With experience in all things programming, cyber security, and compliance, he is our editor-in-chief at Axipro.

Blog Highlights

Explore More Articles

Only one of these three vendors sells a FedRAMP-authorized identity platform you can buy today as a defense contractor, one sells two of them, and one sells none. Whether that matters for your CMMC Level 2 assessment depends entirely on whether your identity provider stores, processes, or transmits Controlled Unclassified Information (CUI), or provides security protections for the systems that do. That second condition is where most contractors get the analysis wrong. The IdP question is arguably the most argued-about scoping decision in CMMC 2.0 Level 2 preparation, because an identity provider almost never holds CUI directly, yet it controls access to everything that does. This article works through the regulatory requirement, the actual FedRAMP status of JumpCloud, Okta, and Microsoft Entra ID, and how to choose based on your CUI architecture rather than vendor marketing. Understanding the CMMC Level 2 + FedRAMP Requirement What CMMC Level 2 Requires for Cloud Services Handling CUI CMMC 2.0 Level 2 requires contractors to implement the 110 security requirements of NIST SP 800-171 Rev. 2 and, for most contracts, pass a third-party assessment by a Certified Third-Party Assessor Organization (C3PAO). The 48 CFR acquisition rule took effect on November 10, 2025, which means CMMC clauses now appear in new Department of Defense (DoD) solicitations, with third-party assessment requirements expanding through the phased rollout in 2026 and beyond. The cloud piece comes from the CMMC program rule at 32 CFR Part 170. If an Organization Seeking Certification uses a Cloud Service Provider (CSP) to process, store, or transmit CUI, that cloud service offering must be either FedRAMP Authorized at the Moderate baseline or higher or must meet security requirements equivalent to the FedRAMP Moderate baseline. Your C3PAO verifies this during the assessment. If your in-scope CSP fails the test, you fail the assessment. The DFARS 252.204-7012 “FedRAMP Moderate or Equivalent” Clause The requirement predates CMMC. DFARS 252.204-7012 has required since 2016 that any external CSP used to store, process, or transmit covered defense information meet security requirements “equivalent to those established by the Government for the Federal Risk and Authorization Management Program (FedRAMP) Moderate baseline.” For years, “equivalent” was undefined, and contractors interpreted it loosely. The DoD CIO closed that door with its December 2023 equivalency memo. To be FedRAMP Moderate Equivalent, a CSP must now demonstrate 100% compliance with the FedRAMP Moderate baseline, validated by a FedRAMP-recognized Third-Party Assessment Organization (3PAO), and hand over a full Body of Evidence to the contractor. No open Plans of Action and Milestones (POA&Ms) against the baseline are permitted. In some ways, it’s stricter than authorization itself, since authorized CSPs are allowed to carry POA&Ms. Important: A vendor telling you they are “NIST 800-171 compliant” or “aligned to FedRAMP controls” does not satisfy DFARS 7012 or the CMMC rule. Either the offering appears on the FedRAMP Marketplace at Moderate or higher, or the vendor gives you a 3PAO-attested Body of Evidence demonstrating full equivalency. Anything else is a gap your C3PAO will find. When an Identity Provider Falls Under This Requirement An IdP is a cloud service. The question is whether it processes, stores, or transmits CUI. In a typical SSO flow, the IdP handles credentials, authentication tokens, session data, and directory attributes. None of that is CUI in most environments. So a literal reading says the FedRAMP mandate doesn’t apply. The complication is the CMMC scoping guidance, which defines Security Protection Assets (SPAs): assets that provide security functions to the CMMC assessment scope even if they never touch CUI. An IdP enforcing multi-factor authentication (MFA), conditional access, and session policy over your CUI enclave is the textbook SPA. SPAs are in scope for your assessment and get evaluated against the relevant NIST SP 800-171 requirements they help satisfy. Let Axipro help you build a business continuity plan that’s practical, compliant, and audit-ready. Schedule Your Free Assessment Today Schedule A Consultation Does Your Identity Provider Actually Need to Be FedRAMP Authorized? When the IdP Processes, Stores, or Transmits CUI Some architectures do push CUI through the identity layer. If usernames or directory attributes contain CUI (think program names or export-controlled project identifiers), if your IdP proxies application traffic through a gateway that carries CUI payloads, or if CUI-bearing documents get attached to identity workflows, the IdP is now a CSP handling CUI. FedRAMP Moderate or equivalent becomes non-negotiable. When the IdP Provides Security Protections for CUI (SPA Role) This is the common case, and it’s genuinely gray. The FedRAMP requirement in the rule text attaches to CSPs that process, store, or transmit CUI. A pure-play authentication service that does neither is an SPA, not a CUI-handling CSP. Under the final CMMC rule, External Service Providers (ESPs) that handle only Security Protection Data, such as configuration data, logs, and credentials, do not themselves require FedRAMP authorization or a separate CMMC certification. Their services get assessed as part of your assessment. In practice, C3PAOs are not uniform on this. Some accept a well-documented System Security Plan (SSP) showing the IdP never touches CUI. Others take a conservative view that authentication data for CUI systems is sensitive enough that they want FedRAMP-grade assurance behind it, and they will probe hard. DIBCAC’s historical position, given publicly by officials as far back as 2020, is that clouds with management access to CUI systems don’t need FedRAMP unless CUI actually moves into them. That position helps, but you carry the burden of proving CUI never transits the service. Cases Where a Commercial IdP May Be Acceptable A commercial, non-FedRAMP IdP can survive a CMMC Level 2 assessment when all three of the following are true: CUI demonstrably never touches the IdP, the IdP is documented as an SPA with the specific 800-171 requirements it supports, and the data flows in your SSP prove the boundary. This is exactly how many contractors run enclave strategies, keeping a commercial identity stack for the corporate network while the CUI enclave uses its own FedRAMP-authorized identity. The “External Service Provider” (ESP) Classification Under CMMC The final

How Axipro Guided Technovative Solutions & DigiProd Pass to ISO 27001
Secure AI Agent Vendor

An AI agent that can read your inbox, query your CRM, and dig through internal documents has more standing access than most of your employees. It handles sensitive data, acts on its own, and often passes that data through sub-processors you’ll never see. Certifications are the quickest way to tell which vendors have let an outsider check their work, and which ones just put the word “secure” on a landing page. No single certificate proves an AI agent is safe. But the right mix of security attestations, privacy certifications, and AI governance standards tells you the vendor has real controls, that an independent auditor has tested them, and that someone is on the hook when the agent misbehaves. This guide covers which certifications to ask for, how to verify them, and which claims should make you walk away. The Core Certifications Every Secure AI Agent Vendor Should Hold SOC 2 Type II SOC 2 Type II is the baseline for any SaaS or AI vendor that handles customer data. A licensed CPA firm audits the vendor against the AICPA’s Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality, and Privacy) and reports on whether its controls actually worked over a review period, usually 3 to 12 months. A Type I report only confirms the controls existed on one particular day. For an AI agent vendor, insist on Type II. Anything less tells you nothing about how the company runs day-to-day. ISO/IEC 27001 ISO/IEC 27001 certifies that the vendor runs a formal information security management system (ISMS): documented risk assessments, defined controls, internal audits, and management review, all verified by an accredited certification body. It’s the most widely recognized security certification outside the US and often a hard procurement requirement in Europe, the UK, and the Gulf. A vendor with international customers should hold it alongside SOC 2, not instead of it. ISO/IEC 27701 (Privacy Information Management) ISO/IEC 27701 extends ISO 27001 with a privacy information management system (PIMS). It maps closely to GDPR concepts like controller and processor obligations, consent, and data subject rights. Almost every AI agent processes personal data at scale, and ISO 27701 is a decent signal that the vendor has built privacy into how it operates instead of delegating it to a policy PDF. ISO/IEC 42001 (AI Management Systems) ISO/IEC 42001 is the first certifiable international standard for AI governance. According to the International Organization for Standardization, it sets out requirements for building and maintaining an AI management system (AIMS): AI risk management, AI system impact assessments, lifecycle management, and oversight of third-party suppliers. For an AI agent vendor, this is the one that covers what SOC 2 and ISO 27001 don’t: how the vendor governs model behavior, training data, and the wider impact of autonomous systems. Worth Knowing: ISO 42001 certificates only started appearing in volume in 2024, and the accreditation ecosystem is still catching up. Check that the certificate came from a certification body accredited for ISO 42001 specifically (under ANAB or UKAS, for example), not just one accredited for ISO 27001. HIPAA (for Healthcare AI Agents) If the agent touches protected health information (PHI), the vendor has to comply with the HIPAA Privacy and Security Rules and sign a Business Associate Agreement (BAA). There’s no official HIPAA certification, so vendors prove compliance through third-party assessments, a SOC 2 with HIPAA mapping, or HITRUST CSF certification. A vendor that won’t sign a BAA has disqualified itself for healthcare work. PCI DSS (for Payment-Handling AI Agents) AI agents that process, store, or transmit cardholder data (think agents automating billing, refunds, or checkout) fall under PCI DSS. Ask for the vendor’s Attestation of Compliance (AOC) and check whether a Qualified Security Assessor validated it or the vendor assessed itself. The current version is PCI DSS 4.x, so an AOC that still references 3.2.1 is out of date. FedRAMP (for Government-Facing AI Agents) FedRAMP authorization is mandatory for cloud services sold to US federal agencies. Authorizations come at Low, Moderate, and High impact levels, and every authorized service appears on the public FedRAMP Marketplace. If a vendor claims FedRAMP status and isn’t in the Marketplace, either the claim is false or the service is still “in process,” and those are very different things. State and local buyers should look for StateRAMP instead. Worth Knowing: ISO 42001 Certificates ISO 42001 certificates only started appearing in volume in 2024, and the accreditation ecosystem is still catching up. Check that the certificate came from a certification body accredited for ISO 42001 specifically (under ANAB or UKAS, for example), not just one accredited for ISO 27001. HIPAA (for Healthcare AI Agents) If the agent touches protected health information (PHI), the vendor has to comply with the HIPAA Privacy and Security Rules and sign a Business Associate Agreement (BAA). There’s no official HIPAA certification, so vendors prove compliance through third-party assessments, a SOC 2 with HIPAA mapping, or HITRUST CSF certification. A vendor that won’t sign a BAA has disqualified itself for healthcare work. PCI DSS (for Payment-Handling AI Agents) AI agents that process, store, or transmit cardholder data (think agents automating billing, refunds, or checkout) fall under PCI DSS. Ask for the vendor’s Attestation of Compliance (AOC) and check whether a Qualified Security Assessor validated it or the vendor assessed itself. The current version is PCI DSS 4.x, so an AOC that still references 3.2.1 is out of date. FedRAMP (for Government-Facing AI Agents) FedRAMP authorization is mandatory for cloud services sold to US federal agencies. Authorizations come at Low, Moderate, and High impact levels, and every authorized service appears on the public FedRAMP Marketplace. If a vendor claims FedRAMP status and isn’t in the Marketplace, either the claim is false or the service is still “in process,” and those are very different things. State and local buyers should look for StateRAMP instead. Regulatory Frameworks AI Agent Vendors Must Comply With Certifications are voluntary. Regulations aren’t. A credible AI agent vendor should be able to explain, in writing, how it meets