EU AI Act Compliance Requirements for Enterprise Agent Deployments

EU AI Act compliance for enterprise agent deployments requires control over how agents authenticate, act, and are audited. To detect and remediate shadow MCP usage, security teams need an inventory of unmanaged agents and connections, identity tied to each action, and a governed path for approved integrations. Those controls belong in the deployment infrastructure.

Why enterprises deploying AI agents are the ones the EU AI Act is aimed at

An enterprise using an agent built on a third-party model is a deployer, with binding obligations separate from the provider’s. Buying the model does not transfer responsibility for how employees use it. Deployers must conduct vendor due diligence, collect Article 9, 12, and 13 documentation from providers, and enforce controls on uses the provider cannot govern for them.

The Act regulates what a system does. The April 2026 paper AI Agents Under EU Law A Compliance Architecture for AI Providers explains that “AI agent” has no legal definition in the Act, but that absence does not create an exemption. Systems that autonomously plan, invoke external tools, and execute multi-step action chains fall within its functional approach. What the enterprise puts the agent in charge of is therefore decisive.

The compliance calendar as it stands after the Digital Omnibus

The calendar starts with obligations that are already enforceable. Article 5 prohibited practices, including social scoring, subliminal manipulation, and real-time biometric surveillance, have been enforceable since February 2025. No enterprise grace period applies. The Digital Omnibus did not suspend those prohibitions, so its later deadlines cannot be treated as permission to postpone all compliance work.

The Digital Omnibus entered into force on 27 July 2026 and moved the high-risk Annex III deadline from August 2, 2026, to December 2, 2027. It also moved the Annex I deadline to August 2, 2028. Article 50 transparency obligations, which require disclosure of AI interactions, still came into force August 2, 2026. The only exception is a four-month grace period to December 2, 2026 for providers to meet the Article 50(2) machine-readable marking obligation for generative AI systems already placed on the market before August 2, 2026.

The 16-month reprieve applies only to high-risk obligations. Conformity assessments, risk management systems, and technical documentation must be in place and in use before December 2, 2027. These depend on evidence from the deployment, rather than a policy document written shortly before the deadline. Enterprises that wait until mid-2027 will not have enough time to retrofit governance into existing agents.

How the Act's high-risk category applies to the use cases where agents are most commonly deployed

Hiring and HR automation, credit decisioning, and critical infrastructure management are among the Annex III use cases that apply to enterprise agents. Essential services access, law enforcement support, migration and border control, and the administration of justice and democratic processes are also in scope. These are decisions about people and essential systems. An HR department that uses a custom-prompted model to filter candidates can create a high-risk deployment while thinking it has just added a productivity tool.

Document summarization can be minimal-risk in one context, while using the agent to score or rank job applicants brings it into a high-risk use case. For work such as fraud detection or regulatory reporting, the name of the workflow does not tell the whole story of what the agent does. Classification needs a record of the agent’s external actions, data flows, connected systems, and the people it affects. The April 2026 paper identifies that exhaustive inventory as the provider’s foundational compliance task, with classification following from it.

Security teams need to see every agent, MCP connection, and data flow in every department. Runlayer provides real-time inventory and governance of agent deployments and external integrations, making it one option for surfacing these hidden compliance triggers. Once a deployment falls into a high-risk category, the relevant requirements extend across risk management, data governance, technical documentation, logging, human oversight, and cybersecurity resilience.

What each high-risk article actually demands at the agent architecture level

Article 9 turns risk management into a continuing operational task. At the agent architecture level, that means a live inventory of agents, MCP server connections, and APIs, with new connections and configuration drift flagged in real time. A deployment assessment cannot account for a tool added afterward unless the system detects the change. Article 11 adds the documentation requirement, with a complete inventory of components, interfaces, and capabilities before market placement that stays current as the agent evolves. Together, these requirements make the deployed system, rather than its original design document, the object of governance.

Under Article 12, high-risk systems must be built to allow automatic event recording. The architectural consequence is logging that captures inputs, reasoning steps, outputs, and whether actions were user-initiated or AI-initiated. Articles 19 and 26(6) mandate retention for a minimum of six months, with longer periods where sector law applies, including for financial institutions. A record of the final answer alone cannot account for the external actions that produced it. Governance platforms built for this work, including Runlayer, enforce policy at tool-call depth and keep tamper-proof audit logs tied to agent sessions.

Article 14 requires human oversight, but putting every action in an approval queue is not enough to meet that need. The Bank of England flagged in June 2026 that literal human-in-the-loop approaches are increasingly unworkable at agentic scale. The expectation is shifting toward “human-on-the-loop”, meaning continuous monitoring, anomaly detection, and rapid intervention. An agent architecture therefore needs clear points where people can step in and paths for escalation.

Article 15(4) brings cybersecurity resilience down to the API action layer. Its architectural implications include least-privilege enforcement, per-action authorization, restrictions based on input trust level, and logs attributing each tool call to the identity that authorized it. Authentication at the start of a session is not the same as authorization for everything the agent later decides to do. The control must operate where the action occurs, because that is where permissions meet consequences.

Runtime behavioral drift as a compliance problem unique to agents

An agent can become non-compliant after deployment without a deliberate change by its operator. That makes runtime behavioral drift more than a performance concern. An initial conformity assessment describes a baseline, but it cannot establish that later behavior remains within that baseline unless the enterprise can trace the difference. The April 2026 paper concludes that high-risk agentic systems with untraceable behavioral drift cannot currently satisfy the Act’s essential requirements.

A compliant drift-detection program therefore needs versioned snapshots of operational state at defined intervals. Continuous monitoring must compare behavioral metrics with the conformity assessment baseline, and automated detection must flag changes that go beyond the defined thresholds so they can be reassessed. A documented internal procedure must then assess the change against the Article 3(23) substantial modification threshold. Crossing that threshold requires a new conformity assessment. Without drift monitoring, an enterprise cannot know when that obligation has been triggered.

This is where a checklist stops being enough. A checklist can establish that monitoring existed at deployment, but compliance depends on what the agent is doing now. That comparison needs clear human ownership, audit logging, and set boundaries on what the agent can do. Without them, drift is difficult to investigate after an incident and untraceable during ordinary operation, so governance must be continuous.

How to find unauthorized MCP servers and govern the attack surface Article 15 covers

Finding unauthorized MCP servers starts with discovery of unmanaged agents, MCPs, skills, plugins, and client configurations, connected to visibility into agent sessions. Remediation then requires an approved path for integrations, with identity and policy controls applied when tools are invoked. Employees’ connections to servers outside the sanctioned list leave a gap in the audit evidence high-risk deployments need.

MCP is a central attack surface because it connects agent decisions to external tools. OWASP’s MCP Top 10 catalogs threats including tool poisoning, schema poisoning, tool shadowing, command injection, shadow MCP servers, and context over-sharing across shared agent sessions. Tool poisoning hides malicious instructions in tool metadata, while command injection takes advantage of unsanitized agent input. The MCP authorization specification defines an OAuth 2.1 framework but explicitly makes authorization optional. That leaves authentication as a separate requirement to establish.

In 2026, Check Point Research reported that poisoned repository configuration files allowed remote code execution in Claude Code. Cisco documented a case in which a malicious GitHub issue sent hidden instructions through an MCP server, hijacking an agent and triggering data exfiltration from private repositories. The agent’s surrounding inputs and tools were part of the execution path.

Traditional WAFs, DLP, SIEMs, and API gateways do not, by themselves, reveal MCP-specific intent hidden inside legitimate HTTPS traffic and valid tool invocations. Security teams therefore need visibility into tool calls, outputs, intent, and sensitive data. That is the practical connection between Article 15’s resilience requirement and purpose-built MCP controls.

Non-human identity and credential management as the unresolved gap in existing IAM frameworks

An agent identity is not just a human account with a different name. An agent may hold delegated credentials, decide what to authorize in real time, spawn sub-agents with their own permissions, and act for several users at the same time. Existing IAM frameworks built around human users do not natively represent that combination of delegated, multi-level authority. A successful login establishes access to a session, but does not explain who authorized each autonomous action within it.

The distinction becomes concrete when an agent moves from one tool to another. Article 15(4), operationalized at the API level, calls for authorization scoped to each action and restrictions that reflect the trust level of the input. Just-in-time credential provisioning and rotation policies must account for the agent’s autonomous operation cycle. Static, long-lived credentials issued to a service account give the agent standing access where governance requires bounded authority.

SSO and SCIM, as currently deployed, cover human identity federation. Extending them to agents requires identity-to-action binding at tool-call depth. In multi-agent systems, the trust boundary and scope of delegated authority must also be enforced at every hop from an orchestrating agent to its sub-agents. Closing this gap requires infrastructure that can govern the delegation itself, while preserving the link between the action and its authorizing identity.

Why retrofitting governance onto deployed agents fails and what building it into the foundation requires

A later audit log cannot reconstruct every earlier tool invocation, credential use, and authorization decision. A written intervention policy cannot create an interruption point in an agent that lacks one. Continuous risk management, drift detection, and real-time access control must therefore be part of how the agent operates from its first deployment.

Built-in governance starts with a single view of MCP servers, skills, and agents. It connects identity to every action, enforces policy at tool-call depth, detects MCP-specific threats in real time, and preserves tamper-proof audit records. It must also give employees a way to use approved tools that works for them. If the compliant route is harder than an unapproved integration, employees have a reason to bypass it, and shadow MCP usage remains an ongoing operating problem.

For organizations evaluating that foundation, Runlayer combines a governed deployment path with built-in OAuth and credential handling, centralized control over agents and integrations, and runtime threat detection backed by tamper-proof logs and OTEL tracing.

The moment to establish centralized control is now, before existing deployments make that work harder. Enterprises that build governance into the foundation will be positioned to keep high-risk agents legal to run when the December 2027 deadline arrives. Their security teams will have an operational record to demonstrate compliance in an audit, rather than a history they must try to reconstruct afterward.