Does EU AI Act Article 15 Require You to Detect Prompt Injection in AI Agents?

Yes. Under Article 15 of the EU AI Act, high-risk AI systems must be resilient against attempts to exploit their vulnerabilities, and that explicitly includes adversarial attacks like prompt injection and data poisoning. For an AI agent, resilience is not a design intention you can assert in a policy document. It is a control you have to detect, log, and prove. The enforcement date is the end of 2027 (the omnibus package pushed high-risk obligations to December 2027), so there is no 2026 deadline and no near-term panic. There is, however, a concrete artifact you should start building now: audit-ready detection evidence.

This post covers what Article 15 actually says, why prompt injection is the agent-specific version of the problem, what the required evidence looks like, and what PanGuard ships today versus what is still roadmap. Every number below traces to a public benchmark or a published CVE.

What does Article 15 actually require?

Article 15 of the EU AI Act is the accuracy, robustness, and cybersecurity clause. For high-risk systems it requires an appropriate level of resilience against errors, faults, and inconsistencies, and against attempts by third parties to alter use or performance by exploiting system vulnerabilities. The text names the attack classes directly: it calls out measures to prevent, detect, respond to, resolve, and control for attacks trying to manipulate the training dataset (data poisoning), pre-trained components (model poisoning), inputs designed to cause the model to make a mistake (adversarial examples), and confidentiality attacks.

Read that against an AI agent. An agent takes untrusted input from tools, files, web pages, and other agents, then acts on it with real permissions. The adversarial example clause and the input manipulation clause map cleanly onto prompt injection. If a poisoned document in your agent's context can redirect its behavior, that is an Article 15 exposure, and detecting it is part of the legal duty, not an optional hardening step.

When does this actually bite? (Not 2026)

The enforcement timeline matters because the compliance market is full of manufactured urgency. High-risk system obligations under the EU AI Act, including Article 15, are enforced from the end of 2027. The omnibus simplification package delayed the high-risk provisions to December 2027. So if a vendor is selling you an August 2026 deadline, they are wrong. You have runway. What you do not have is a mature answer to the question an auditor will eventually ask: show me the evidence that your agent detected and logged adversarial inputs.

That gap is the reason to start now. Detection evidence is not something you can retroactively generate. Either your runtime was watching when the injection attempt happened, or it was not.

What does the required artifact look like?

The artifact that satisfies an Article 15 audit is not a screenshot or a vendor attestation. It is signed, replayable detection evidence that maps each finding to a specific rule and a specific framework clause. Three properties make it audit-ready:

• ●Deterministic detection: the same input produces the same verdict every time, so an auditor can re-run it. Non-deterministic LLM-judge output alone does not clear this bar.
• ●Rule-ID traceability: every detection cites the exact rule that fired, so the finding is inspectable rather than a black box.
• ●Framework mapping: each rule links to the clause it satisfies, so the evidence answers a compliance question, not just a security one.

This is where an open detection standard does the heavy lifting. ATR (Agent Threat Rules) is an independent, MIT-licensed rule standard, the way Sigma is for logs or CVE is for vulnerabilities. PanGuard is built on ATR and operates it, but the standard is governed independently. The current corpus is 680+ rules across 10 categories (688 as of July 2026, published as agent-threat-rules v3.5.6 on npm). Because detection runs against named rules, every alert already carries the rule ID an auditor needs.

How does rule-based detection map to compliance frameworks?

Article 15 is the legal anchor, but auditors usually work through a framework. ATR carries 866 rule-to-category mappings against the OWASP Agentic Top 10 (2026), covering all ten categories: nine at STRONG coverage and one (ASI10 Rogue Agents) at MODERATE. The prompt-injection-relevant categories, ASI01 Agent Goal Hijack and ASI06 Memory and Context Poisoning, sit in the STRONG band.

For threat-model alignment, ATR maps to 34 of the 101 top-level MITRE ATLAS techniques and 13 of 16 tactics, against the ATLAS v5.6.0 draft. This is what turns a raw alert into an audit line: a detection event that says which rule fired, which OWASP category it belongs to, and which ATLAS technique it corresponds to.

How well does deterministic detection actually work?

Honest answer: it depends on the corpus, and there is no single engine-wide precision number. ATR is a Layer 1 deterministic rule engine, and its measured performance varies by test set. Here is what the public benchmarks show for the Layer 1 rules:

False positives are lane-based, not a single blended figure. Against a 65,000-sample benign gate, the enforce lane runs about 0.24% false positives and the default hunt lane about 9%. Stating that honestly is the point: an auditor trusts evidence that comes with its own error bars more than a marketing number that claims perfection.

Why is prompt injection the agent-specific case?

Because agents act on their inputs, injection is not a chatbot annoyance, it is a live exploitation path. The public CVE record already shows the shape of it. The postmark-mcp package was a trusted MCP server that silently BCC'd between 3,000 and 15,000 emails per day for 15 versions before anyone noticed. MCPJam Inspector (CVE-2026-23744) shipped a default 0.0.0.0 binding that turned a single HTTP request into remote code execution in every version before v1.4.3. Azure MCP Server (CVE-2026-26118) had an SSRF flaw that stole managed-identity tokens. Claude Code itself (CVE-2025-59536 and CVE-2026-21852) had hooks and MCP config abused for arbitrary shell execution and API key theft.

None of those are hypothetical adversarial examples. They are the Article 15 threat model, already realized in shipped software. An agent that cannot detect this class of behavior at runtime cannot claim the resilience the clause requires.

What does PanGuard ship today, and what is roadmap?

Shipped and real: PanGuard is free and MIT-licensed. The Community edition is the complete product, with no paywall. You install it with npm install -g @panguard-ai/panguard && pga up. pga scan <target> audits a skill or MCP server before you install it. Guard provides runtime detection and auto-detects agent runtimes including Claude Code, Cursor, Windsurf, Gemini CLI, Cline, and Codex CLI. Threat crystallization means an AI understands a new attack once, that understanding is written as a deterministic rule, and the rule then executes in milliseconds for everyone, typically within about an hour of a new attack surfacing.

Roadmap and honest limitations: the signed, framework-mapped compliance export described above is the direction of the product, and rule-ID and framework mapping already exist in the standard. Full turnkey Article 15 audit packaging, with cryptographically signed evidence bundles wired end to end, is still maturing. I am one person building this. I would rather tell you what is deterministic and shipping today than sell you an end-to-end compliance guarantee that is not fully wired yet. There are also 64 documented evasion techniques against deterministic rules, which is exactly why the honest FP lane numbers matter.

FAQ

Is there a 2026 EU AI Act deadline for detecting adversarial attacks?

No. High-risk obligations under Article 15 are enforced from the end of 2027, after the omnibus package delayed them to December 2027. Any 2026 deadline you have been shown is incorrect.

Does Article 15 specifically mention prompt injection?

Not by that name. It names adversarial examples, data poisoning, model poisoning, and input manipulation attacks. Prompt injection against an AI agent falls squarely inside the adversarial example and input manipulation clauses.

Is ATR the same thing as PanGuard?

No. ATR is an independent, MIT-licensed detection standard that PanGuard is built on and operates, but ATR is governed independently. The relationship is like Sigma or CVE and a vendor that operates the standard.

Can I get audit-ready evidence for free?

The detection engine, the rules, and the runtime are free and open source today. Every alert already carries a rule ID and framework mapping. Fully packaged, signed compliance-export bundles are still on the roadmap.

Start with the scan. Run npm install -g @panguard-ai/panguard && pga up, then pga scan <your-mcp-server> to see what a deterministic detection pass finds before your Article 15 clock ever starts ticking.