The EU AI Act for AI Agents: Risk Tiers, Obligations, and Compliance Timeline (2026)

The EU AI Act - formally Regulation (EU) 2024/1689 - is the world's first comprehensive, horizontal law governing artificial intelligence. It was adopted on 13 June 2024, published in the Official Journal on 12 July 2024, entered into force on 1 August 2024, and applies in phases through 2027. Rather than regulate a specific technology, it classifies AI systems by the *risk they pose* and assigns obligations by the *role* an organisation plays - provider, deployer, importer, distributor, or authorised representative.

For security and governance teams, the Act matters most where it intersects with autonomy. An AI agent that takes consequential actions - screening job applicants, scoring credit, pricing insurance, touching critical infrastructure - can land squarely in the high-risk tier. That classification drags the agent, and every MCP server it orchestrates, into the heaviest obligation set in the regulation: mandatory event logging, human oversight, risk management, and a durable audit trail. Those are precisely the records that ungoverned agent and MCP fleets do not produce by default. This guide maps the framework's actual structure to the agentic layer and shows how a security team operationalises it.

What the EU AI Act is

The Act was proposed by the European Commission and co-adopted by the European Parliament and the Council. At EU level it is overseen by the European AI Office within the Commission - focused on general-purpose AI - alongside an AI Board, a scientific panel, an advisory forum, and national competent and market-surveillance authorities in each member state. It is a *regulation*, not a directive, meaning it applies directly across the EU without national transposition.

Its scope is extraterritorial in effect: it reaches providers and deployers outside the EU when their AI systems' outputs are used in the Union. A US-based enterprise running agents that affect EU employees, customers, or applicants is therefore in scope. Enforcement is backed by tiered fines reaching EUR 35 million or 7% of global annual turnover, whichever is higher.

The risk-based taxonomy

The core of the Act is a four-tier risk pyramid, with a separate regime layered on top for general-purpose AI (GPAI) models.

Tier 1 - Unacceptable risk (prohibited, Article 5)

These practices are banned outright and have been since 2 February 2025. They include harmful subliminal, manipulative, or deceptive techniques; exploitation of vulnerabilities tied to age, disability, or socio-economic situation; social scoring; criminal-offence risk prediction based solely on profiling; untargeted scraping of facial images to build recognition databases; emotion inference in workplaces and education (with narrow exceptions); biometric categorisation inferring sensitive attributes; and real-time remote biometric identification in publicly accessible spaces for law enforcement (with narrow exceptions).

Tier 2 - High risk (Annex III and Annex I)

Permitted but heavily regulated. Annex III lists use-case domains: non-prohibited biometrics; critical infrastructure; education and vocational training; employment and worker management; access to essential public and private services (including creditworthiness and life/health insurance pricing); law enforcement; migration, asylum, and border control; and administration of justice and democratic processes. Annex I covers AI acting as a safety component of products already regulated under EU harmonisation law. High-risk status triggers the full Article 9-15 requirements plus conformity assessment and CE marking.

Tier 3 - Limited risk (transparency, Article 50)

Transparency duties only. Users must be informed when they are interacting with an AI system, such as a chatbot. AI-generated or manipulated content - deepfakes and synthetic media - must be disclosed and marked in a machine-readable format. Emotion-recognition and biometric-categorisation use must also be disclosed to affected persons.

Tier 4 - Minimal or no risk

Everything else - spam filters, AI in video games, and the like. No mandatory obligations; voluntary codes of conduct are encouraged.

The GPAI overlay

On top of the four tiers sits a separate regime for general-purpose AI models (Chapter V), in force since 2 August 2025. All GPAI providers must maintain technical documentation, supply information to downstream integrators, adopt a copyright-compliance policy, and publish a sufficiently detailed summary of training content (Article 53). Models trained above a presumed-systemic-risk threshold of 10^25 FLOPs of cumulative training compute face additional Article 55 duties: model evaluation including adversarial testing, systemic-risk assessment and mitigation, serious-incident reporting to the AI Office, and adequate cybersecurity. Providers that reach or foresee crossing the threshold must notify the Commission within two weeks. A voluntary GPAI Code of Practice, finalised in 2025, offers a route to demonstrate compliance on transparency, copyright, and safety/security until harmonised standards are published.

Compliance timeline

High-risk obligations by role

Obligations attach to whoever plays each role. For agentic deployments, the provider and deployer roles matter most.

Provider obligations (Articles 8-17, with 9-15 the substantive core) include: a risk management system, data governance, technical documentation, automatic event logging (record-keeping), transparency and instructions for deployers, human oversight by design, accuracy, robustness and cybersecurity, and a quality management system - plus conformity assessment and CE marking before market placement.

Deployer obligations (Article 26) include using the system in line with its instructions, assigning competent human oversight, monitoring operation, and keeping the logs the system generates. This is the role most enterprises occupy when they run third-party agents and MCP servers - and it carries independent compliance duties that do not transfer to the vendor.

How the Act applies to AI agents and MCP servers

The Act never says "agent," but its requirements bite hard at the agentic layer. The translation is direct once you map articles to the realities of autonomous tool use.

The throughline is unavoidable: Article 12 logging assumes you can enumerate the systems generating events. Article 14 oversight assumes you know which agents need a human in the loop. Article 9 risk management assumes you have discovered the attack surface - including which MCP servers an agent actually connects to. The Act repeatedly presumes the organisation already holds an inventory, logs, oversight, and a risk assessment for every AI system in scope.

That presumption is exactly where autonomous agents spread as shadow IT. Developers install coding agents and CLIs; teams wire up MCP servers without review. The result is a population of consequential, tool-wielding systems with no owner, no inventory, and no log - non-compliant by default. The agent-specific attack surface the Act asks you to manage is real: MCP server security and MCP tool poisoning are the precise foreseeable risks an Annex III deployer is expected to identify and mitigate.

How a security team operationalises it

Compliance for the agentic layer is less about reciting article numbers and more about closing the visibility gap the Act assumes is already closed. A practical sequence:

1. Discover and inventory every AI agent and MCP server across the fleet - including unsanctioned ones. Without this, you cannot classify use cases, assign owners, or produce logs. This is the precondition for almost every obligation.
2. Classify by risk tier. Map each agent to its use case: does it touch an Annex III domain? Is it merely a limited-risk chatbot needing disclosure? Triage effort toward the high-risk population.
3. Establish role and accountability. For each system, record whether you are provider or deployer, who owns it, and what data and tools it can reach.
4. Wire up logging (Article 12). Capture an attributable, durable record of agent actions and MCP tool calls - the audit trail the regulation demands.
5. Enforce human oversight (Article 14). Add intervention checkpoints and stop controls for high-risk agents; flag any agent with broad autonomous access and no stop control.
6. Run risk management (Articles 9, 15). Assess prompt-injection, tool-poisoning, and unvetted-MCP exposure; monitor behaviour and alert on anomalies as your serious-incident signal.
7. Deliver AI literacy (Article 4). Use the inventory to target training at the people actually supervising agents.

For organisations standardising on coding assistants and CLIs, the same discipline supports securing AI coding agents and CLIs and governing AI coding assistants across your fleet. The work is continuous, not a one-time audit - agents and MCP servers appear and change constantly.

Where continuous agent and MCP visibility fits

Every high-risk obligation in the Act runs through a single dependency: you must be able to see the AI systems in scope. The regulation presumes an inventory, logs, oversight, and risk assessment already exist. For the agentic layer, they usually do not - agents and MCP servers proliferate faster than governance can map them.

This is the category Anomity operates in: continuous discovery and inventory of every agent and MCP server on the endpoint and across the fleet, monitoring of their permissions and behaviour, anomaly alerting, and a durable audit trail. None of that *is* compliance on its own - conformity assessment, documentation, and legal classification remain the organisation's work. But discovery, monitoring, alerting, and logging are the practical enablers that make Article 12, Article 14, and Article 9 achievable for autonomous agents rather than aspirational. You can't produce the logs, oversight, or risk assessment for agents you can't see.

The EU AI Act is the first of a wave of risk-based AI laws, and its agentic implications generalise: the more autonomy an AI system has and the more consequential its actions, the heavier the obligation - and the more it depends on visibility you have to build deliberately. Treat the agent and MCP layer as in-scope shadow IT today, and the 2026 high-risk deadline becomes a milestone you have already prepared for rather than a scramble.