EU AI Act Compliance for AI Agent Deployments: The Article-by-Article Obligations

The deadline

On August 2, 2026, the EU AI Act (Regulation (EU) 2024/1689) reaches its next enforcement milestone. The remainder of the Act applies — including the obligations for high-risk AI systems, transparency requirements for AI-generated content, and the penalty provisions. The maximum fine is €35 million or 7% of global annual turnover, whichever is higher.

The Act entered into force on August 1, 2024. Prohibitions on unacceptable-risk practices (social scoring, subliminal manipulation, real-time biometric surveillance in public spaces) have applied since February 2, 2025. General-purpose AI model obligations and governance rules have applied since August 2, 2025. The implementation timeline confirms that August 2, 2026 is the date the high-risk system mandates, transparency obligations, and penalty framework take full effect — with limited exceptions for Article 6(1) systems, which follow in August 2027.

For organizations deploying AI agents that make or support decisions about credit, employment, access to essential services, or critical infrastructure, August 2 is the compliance date. Not a planning date. Not a review date. The date the obligations are enforceable.

The compliance boundary extends to the action layer

Most organizations focus their AI compliance efforts on the model — training data governance, bias testing, output monitoring. The Salt Security compliance analysis makes clear that this is insufficient. The Act's scope extends to what the model does, not just what it produces.

Article 15 (Cybersecurity) requires protection against adversarial attacks, data poisoning, confidentiality attacks, and model evasion. The Salt Security analysis confirms that this protection "must extend to the interfaces through which AI systems interact with the world (APIs and MCP servers)." An AI agent that calls NetSuite through a Model Context Protocol module, or reads customer data from HubSpot through an MCP connector, brings those interfaces into the compliance boundary.

Recitals 99 and 100 address multi-agent architectures explicitly. In a chain of AI agents, the compliance boundary extends to every agent that performs a high-risk function. If an orchestrator agent delegates a pricing decision to a sub-agent that calls an RFQ engine, both agents inherit the obligations. The compliance scope is the full call chain, not the entry point.

What counts as high-risk

The Act defines high-risk AI systems in Article 6 and Annex III. The categories most relevant to B2B agent deployments:

• Employment and worker management — CV screening, promotion decisions, task allocation, performance monitoring
• Access to essential services — credit scoring, insurance pricing, eligibility determinations
• Safety components of critical infrastructure — transport, energy, water
• Law enforcement and justice — though most B2B deployments do not fall here

A procurement agent that evaluates supplier quotes and recommends award decisions touches access-to-essential-services territory if the procurement involves regulated goods or public-sector contracts. A quoting agent that prices differently by customer tier touches credit and insurance territory if the pricing affects access to financial products. The classification depends on the function the AI performs, not the industry the deploying company operates in.

For systems that do not meet the high-risk threshold, transparency obligations still apply. Article 50 requires that deployers inform individuals when they interact with AI systems (chatbots, content generation). Generative AI content must be identifiable. These obligations take effect on August 2, 2026.

The article-by-article obligations

For high-risk systems, the Act imposes specific, auditable obligations. The Salt Security analysis provides the article-level breakdown. Here is what each requires and how it maps to agent infrastructure.

Article 9 — Risk Management

A continuous, iterative risk management system throughout the AI lifecycle. Not a one-time assessment before deployment. The system must identify, analyze, and mitigate known and foreseeable risks, including risks emerging after the system is placed on the market.

What this means for agents: The risk register is a living document. Every new MCP module, every new connector, every new tool registration is a risk surface that must be assessed. A governance layer that logs every tool call and its outcome provides the evidence base for iterative risk review — without it, the risk management system has no data.

Article 10 — Data Governance

High-quality datasets to minimize discriminatory outcomes. Protections against unauthorized access and data poisoning must extend to inference time — when AI agents actively call APIs and access external data.

What this means for agents: The data the agent reads at runtime (from NetSuite, BigCommerce, supplier catalogs) is in scope. If a supplier catalog is poisoned with incorrect pricing data and the agent quotes from it, the data governance obligation applies. Input validation on MCP tool responses is not a quality detail — it is a compliance control.

Article 11 — Technical Documentation

A complete inventory of all components, interfaces, and capabilities before market placement. For an agent system, this means documenting every MCP module, every tool it registers, every upstream system it connects to, and every error path it handles.

What this means for agents: The module registry is the documentation. A system that dynamically registers MCP modules with schemas, rate limits, and audit logs produces the technical documentation as a byproduct of its architecture. A system of ad-hoc scripts and unregistered API calls does not.

Article 12 — Record Keeping (Logging)

Automatic logging of all events. Logs must be tamper-evident and retained for a minimum of 6 months (24 months for biometric and law enforcement systems). Every tool call, every agent decision, every human intervention must be reconstructable from the logs.

What this means for agents: Every MCP tool call must be logged with timestamp, agent ID, tool name, input hash (not raw input — PII boundary), output status, and duration. The log must be append-only or tamper-evident. The 6-month retention is a minimum, not a target. This is the most directly mapable obligation: a governed MCP architecture that logs every function call to DynamoDB with structured fields satisfies Article 12 by construction.

Article 14 — Human Oversight

The system must allow human operators to oversee, intervene, and halt the system in real time when anomalous behavior is detected. This is not a monitoring dashboard that shows metrics after the fact. It is the ability to stop a running agent mid-task.

What this means for agents: Prompt-level instructions ("stop", "cancel") are not oversight under the Act. They are part of the AI's conversational context and can be ignored under memory loss or prompt injection. The Act requires a deterministic halt mechanism that operates outside the AI's reasoning process. A kill-switch that revokes an agent's authentication token, disables a specific MCP module by configuration change, or triggers a circuit breaker on anomalous behavior patterns satisfies Article 14. A "stop" command does not.

The miniOrange kill-switch architecture analysis defines four layers that map to this obligation:

1. Identity-based access revocation — short-lived session tokens tied to specific tasks; instant credential revocation
2. Circuit breakers and anomaly detection — triggers on excessive API requests, unusual token consumption, repeated loops
3. Scoped capability revocation — disable only the dangerous capability (e.g., remove email-sending permission but keep ticket-reading)
4. In-flight task handling — roll back incomplete changes, preserve execution logs, verify system stability post-shutdown

The OpenClaw incident documented in the same analysis illustrates why prompt-level halting fails: an AI agent organizing an email inbox exceeded its memory limit, lost context, and reverted to its last remembered objective — deleting emails. The user's "stop" and "cancel" commands were ignored. The agent continued until manually terminated at the OS level. The failure was architectural: no deterministic shutdown mechanism existed outside the AI's reasoning process.

Article 15 — Cybersecurity

Technical robustness against adversarial attacks, data poisoning, confidentiality attacks, and model evasion. Protection must extend to the interfaces through which the AI interacts with the world.

What this means for agents: Every MCP server, every API endpoint, every connector is in scope. The MCP security landscape documented in 2026 — the systemic STDIO design flaw affecting 150 million downloads, CVE-2026-33032 ("MCPwn", CVSS 9.8), CVE-2026-0755 (Gemini MCP, CVSS 9.8), 30 to 82 percent of public MCP servers carrying exploitable flaws — is the cybersecurity risk the Act targets. Only 8.5 percent of MCP servers use OAuth. The Act does not mandate OAuth specifically, but it does mandate a level of cybersecurity that the current MCP ecosystem does not meet by default.

Articles 72 and 73 — Post-Market Monitoring and Incident Reporting

A documented monitoring system from day one of deployment. Incident reporting windows:

• 24 hours for risks to life or safety
• 72 hours for other serious incidents
• 15 days for malfunctions

What this means for agents: The audit log is the incident report source. When an agent exceeds permissions, makes an unauthorized call, or produces an incorrect output that affects a decision, the log reconstructs what happened. The 24-hour and 72-hour windows mean the monitoring system must alert in real time, not in a weekly review.

The governance gap

Deloitte's 2026 State of AI in the Enterprise found that only 1 in 5 companies has a mature model for governance of autonomous AI agents. Forty-seven to fifty-three percent of organizations have had AI agents exceed permissions or suffer an incident, per the practical-devsecops 2026 report. Only 23 percent have a formal AI-agent identity strategy.

The Act does not prescribe a specific architecture. It prescribes outcomes: risk management that is continuous, logging that is automatic and tamper-evident, oversight that can halt the system deterministically, cybersecurity that extends to every interface. The architecture that satisfies these outcomes is the governed MCP module pattern — the same pattern that addresses the security vulnerabilities documented across the 2026 MCP breach timeline.

How a governed MCP architecture satisfies the obligations

The governance layer that makes MCP modules safe to operate in production is the same layer that satisfies the Act's requirements. The mapping is direct:

EU AI Act article	Obligation	Governance control
Article 9 (Risk Management)	Continuous, iterative risk assessment	Every tool call logged with outcome; risk register updated from audit data
Article 10 (Data Governance)	Protection at inference time	Input validation on MCP tool responses; typed errors distinguish data quality failures from transient errors
Article 11 (Technical Documentation)	Complete component and interface inventory	Module registry: every MCP module, tool schema, upstream connection, error code documented at registration
Article 12 (Record Keeping)	Automatic, tamper-evident logging, 6-month retention	Structured JSON logs to DynamoDB: timestamp, agent ID, tool name, input hash, output status, duration; append-only with partition-key tenant isolation
Article 14 (Human Oversight)	Real-time halt capability	Kill-switch: identity revocation (short-lived JWT tokens), circuit breakers (rate limits per tool per window), scoped capability revocation (disable module by config change), in-flight rollback
Article 15 (Cybersecurity)	Protection extends to APIs and MCP servers	OAuth/Cognito authentication, rate limiting, PII boundary handling (SHA-256 field hashing before logging), typed error contracts
Articles 72–73 (Incident Reporting)	24/72-hour reporting windows	Real-time anomaly detection from audit log; alerting on permission excess, unexpected tool calls, rate-limit violations

The key insight is that these controls are not bolted on after the fact. They are the structure of the MCP module registration, execution, and logging pipeline. A module that registers its tools with schemas, declares its rate limits, logs every call to an append-only store, and can be disabled by a configuration change produces the compliance evidence as a byproduct of its operation. An ad-hoc agent that calls APIs directly does not — and retrofitting compliance controls onto an ungoverned agent is more expensive than building them in from the start.

The multi-agent compliance boundary

Recitals 99 and 100 extend the compliance boundary to every agent in a chain that performs a high-risk function. This has an architectural implication that most organizations have not yet internalized.

Consider a procurement workflow: an orchestrator agent receives an RFQ, delegates product resolution to a catalog agent, delegates pricing to a quote engine agent, and delegates order writing to an ERP integration agent. Under the Act, if any of these agents performs a high-risk function (pricing that affects credit access, supplier selection that affects employment, procurement of regulated goods), every agent in the chain inherits the obligation.

This means the governance layer must be at the orchestration level, not the individual agent level. Logging must trace the full call chain — which agent called which module with which arguments and what the outcome was. The module registry must cover every module across every agent. The kill-switch must be able to halt a specific agent's capability without disabling the shared infrastructure.

The partition_key tenant isolation pattern — where every MCP function call record carries a partition key that scopes it to a specific tenant and endpoint — provides the audit trail structure that multi-agent compliance requires. A query against the function call log can reconstruct the full workflow state: which agent triggered which tool, in what order, with what arguments, and what the result was. This is the evidence base for Article 12 record-keeping and Articles 72–73 incident reporting across a multi-agent chain.

What to do before August 2

For organizations with AI agents already in production or in the deployment pipeline, the August 2 deadline creates a concrete to-do list:

1. Classify your agents. Determine which fall under the high-risk categories (employment, essential services, critical infrastructure). Agents that do not touch these categories still have transparency obligations under Article 50.

2. Audit the logging layer. Can you reconstruct any agent decision from the logs? Are logs tamper-evident and retained for 6 months minimum? If the answer is no, this is the first gap to close — Article 12 is the most directly verifiable obligation.

3. Verify the halt mechanism. Can an operator stop a running agent deterministically, without relying on the agent's own reasoning? If the halt depends on a prompt command, it does not satisfy Article 14. A kill-switch that revokes credentials or disables modules by configuration change is required.

4. Document the interface inventory. Every API, every MCP server, every connector the agent calls must be documented (Article 11). The module registry is the documentation — if you do not have one, this is the second gap to close.

5. Define the incident response procedure. Who is notified when an agent exceeds permissions? What is the 24-hour and 72-hour reporting chain? The procedure must be documented before deployment, not after an incident.

6. Assess multi-agent scope. If your architecture involves agent chains, map every agent that could perform a high-risk function. The compliance boundary is the full chain.

The cost of non-compliance vs. the cost of governance

The maximum fine is €35 million or 7 percent of global turnover. For a mid-market company with €100 million in revenue, that is €7 million. The governance layer that satisfies the Act — audit logging, rate limiting, typed errors, kill-switch, module registry, tenant isolation — is the same governance layer that makes production agents safe to operate regardless of regulatory pressure. The 47 to 53 percent of organizations that have already experienced an agent incident are paying the cost of ungoverned agents in operational risk. The Act simply makes that cost explicit and enforceable.

The organizations that built governance into their agent architecture from the start — module registration with schemas, function call logging to a durable store, authentication with short-lived tokens, rate limits enforced at the module boundary — are the ones for whom August 2 is a documentation exercise rather than an emergency retrofit. The organizations that deployed agents as ad-hoc scripts calling APIs directly are the ones facing the emergency.

---

A distributor running NetSuite, BigCommerce, and three supplier catalogs has an agent that receives RFQs, resolves products against a catalog graph, prices per customer tier, and writes quotes back to NetSuite. If that agent prices credit terms or selects suppliers for regulated procurement, it falls under the high-risk category. The governed MCP architecture — every tool call logged to DynamoDB with timestamp and outcome, every module disableable by configuration change, every agent authenticated with short-lived JWT tokens, every error typed and classified — is what makes that agent compliant on August 2. The same architecture that makes it safe to operate makes it compliant to operate.

Request a scoped build. One-week discovery. You get a system inventory, workflow map, and fixed scope — whether or not you build with us.