How runtime authorization helps turn EU AI Act requirements into enforceable controls

The EU AI Act is here. It entered into force in August 2024 and became generally applicable on 2 August 2026. For any organization deploying AI in a regulated market, it now sits inside the operating environment, or at least it should.

So what does it mean for you? The Act asks for more than documented governance intent. It expects demonstrable control over what your AI systems and agents can access, do, and expose, at the moment they act. The 2026 Digital Omnibus deferred the high-risk deadlines to December 2027 and August 2028, but the prohibited-practice, general-purpose AI, and transparency rules already apply, and the inventory and access-control work behind the later dates does not compress.

Below, we show how PlainID approaches the Act. A runtime authorization control plane turns these requirements into controls you can enforce and evidence, article by article, across the full agentic flow of prompt, data, tools, and output.

What the EU AI Act means for AI agents

The Act sorts AI into risk tiers and puts the heaviest obligations on high-risk systems. Two questions decide how much of it lands on you: when the rules apply, and whether your agents count.

The EU AI Act timeline after the 2026 Omnibus delay

The staged timeline now looks like this:

• February 2025: prohibited practices and AI-literacy duties apply.
• August 2025: general-purpose AI obligations apply.
• August 2026: general applicability, including Article 50 transparency duties.
• December 2027: high-risk obligations for standalone Annex III systems.
• August 2028: high-risk obligations for AI embedded in regulated Annex I products.

The delay buys calendar time, not less work. Finding every AI system, deciding which risk category it falls into, and wiring access controls around it takes lead time, so the practical move is to build the control architecture now.

Why the EU AI Act already covers your AI agents

The Act never uses the word “agent,” which leads some teams to assume agentic systems fall outside it. They do not. The European Commission treats the AI system and general-purpose AI definitions as broad enough to cover AI agents, and obligations attached by risk tier and by your role as provider or deployer, not by whether a system is labeled an agent.

So if an agent retrieves regulated data, calls tools, or acts on a person’s behalf in a high-risk context, the Act’s expectations follow it. That is the gap runtime authorization is built to close.

Why your existing IAM and RBAC can’t close the gap the EU AI Act creates

Most enterprises already have SSO, RBAC, an API gateway, DLP, and an AI governance program. It is reasonable to ask why those don’t already cover this. The answer is that they answer a different question.

Traditional access control asks: who are you? Agentic AI needs more: who are you acting for, which agent is acting, what are you trying to do, which data are you touching, which tool are you invoking, with which parameters, at what risk level, and does this action need human approval? Three distinctions matter here:

• Authentication is not authorization. Proving identity is not the same as deciding what that identity may do right now.
• Authorization at login is not authorization at runtime. Permissions granted once do not account for the purpose, resource, and risk of each individual action.
• Agent permission is not user permission. An agent often runs under a broad service identity that is wider than the person it is acting for.

Which leads to the core idea: the agent is not the authorization boundary. The transaction is. “Is this agent authorized?” is the wrong question. The right one is “is this agent authorized to perform this specific action, against this specific resource, for this specific user, for this specific purpose, under these conditions?” Traditional controls cannot answer that at the moment of action. This is where the gap becomes concrete:

AI workflow	Traditional control	The AI Act operational question	What runtime authorization adds
Employee asks an AI agent for HR data	User authenticated via SSO	Is this user authorized to see this data, for this purpose?	Allow or deny based on user, agent, and context
Agent retrieves documents	RAG has access to the repository	Which records may the agent retrieve for this user and purpose?	Filter retrieval before data reaches the model
Agent calls an MCP tool	Tool or API authenticates the agent	Is this agent allowed to perform this action?	Authorize the tool, action, and parameters
Agent generates a response	DLP scans output afterwards	Can this particular user receive this information?	Mask or filter the response at runtime
Agent attempts a high-risk action	A workflow approval may exist	Must a human intervene before execution?	Step-up, human approval, or deny

Where the EU AI Act meets the runtime control gap

Read across the Act’s high-risk requirements and a pattern appears. In almost every case, governance can define the rule, but something still has to enforce it while the AI runs, and something has to prove it was enforced.

AI Act expectation	Governance can define	Execution requires	PlainID role
Risk management	The risk policy	Enforcement of the restrictions	Runtime policy enforcement
Data governance	Approved data-use rules	Preventing unauthorized retrieval	Fine-grained data authorization
Record keeping	Logging requirements	Evidence of the actual decisions	Authorization decision evidence
Human oversight	Intervention criteria	Stopping or approving an action	Step-up and approval policies
Cybersecurity	Security requirements	Limiting agent blast radius	Least privilege and context-aware authorization
Deployer obligations	Approved operating conditions	Continuous enforcement	Runtime policy
FRIA migrations	Identified rights risks	Access, data, and action controls	Policy enforcement
Transparency	Disclosure rules	Controlling what can be exposed	Output controls where applicable

Four control points across the AI agent lifecycle

Take a real request. A finance employee asks an internal AI agent to prepare a customer account analysis. The agent takes the prompt, searches the RAG environment, retrieves customer records, calls an MCP tool to query a financial system, and returns an answer. But this employee is cleared to see customer A, but not customer B. Without runtime authorization, the agent’s broader service identity may pull both. Here is where authorization intervenes.

1. Input. Who is asking, which agent is acting, what is the purpose, and is the request permitted at all? The request is established against user, agent, and context before anything runs.

2. Data. Which sources, which records, which rows and columns, and at what sensitivity? Retrieval is filtered to customer A only, before data reaches the model.

3. Tools and actions. Which tool, which operation, which parameters, and does this action need a human? Oversight becomes an enforceable condition rather than a policy statement:

• Low-risk action: authorize automatically.
• Sensitive data: authorize only if the context permits.
• High-impact action: require step-up.
• Financial action above a threshold: require human approval.
• Policy violation: deny.

4. Output. What can this user actually receive, does anything need masking, and is the response within policy? Anything about customer B is filtered before delivery.

The agent answers about customer A, and customer B never enters the flow. That is the difference between a governance policy that says “least privilege” and a control that enforces it while the agent works.

What the EU AI Act expects you to control at runtime

Across those articles, the Act keeps returning to the same handful of controls. In plain terms, here is what you need to be able to do, and what PlainID enforces at execution time.

• Know which AI agents exist. Discovery and classification reduce blind spots and give you a governed inventory of agents, connected tools, and data sources.
• Enforce least privilege continuously. Replace broad standing access with context-aware, task- and purpose-scoped authorization at execution time.
• Constrain autonomous actions. Restrict tool and API invocation, MCP server and tool access, and the relevant parameters before an action runs.
• Protect sensitive data. Apply row, column, and cell filtering, document-level controls, and output masking, so AI receives and exposes only authorized information.
• Preserve human control. Require approval or step-up for high-risk activities, and deny execution when the required oversight condition is not met.
• Create auditable evidence. Central policies and runtime decisions build a repeata

PlainID capabilities behind the EU AI Act mapping

These are the building blocks the mappings draw on, each governed centrally and enforced close to the runtime.

Capability	Customer value
AI and agent discovery / inventory	Visibility into AI agents, MCP tools, RAG and data sources, and their relationships. Supports classification and governance onboarding.
Centralized policy management	Policy-based authorization with reusable, centrally governed policies across applications, APIs, data platforms, and AI or agentic flows.
Composite identity and context	Runtime evaluation of human identity, agent or non-human identity, purpose or intent, resource sensitivity, and environmental and risk signals.
Input guardrails	Restrict prompts or requested actions based on identity, agent, purpose, and context, before downstream execution.
Data retrieval guardrails	Apply least-privilege restrictions, row, column, and cell filters, and contextual data controls before data is retrieved or exposed.
MCP, tool, and API guardrails	Control which services, MCP servers and tools, and APIs can be invoked, and constrain actions and parameters based on runtime context.
Output controls	Mask or redact sensitive information, and validate output against policy before delivery.
Auditability and policy lifecycle	Central policy administration, approval and promotion patterns, observable decisions, and traceable enforcement evidence.

How to implement EU AI Act controls

You do not have to fix everything at once. A phased path gets you to a defensible control story without stalling AI delivery.

1. Scope and classify. Identify AI systems, agents, use cases, affected business processes, and likely AI Act roles or risk categories.
2. Discover access paths. Inventory agent frameworks, MCP servers and tools, APIs, RAG sources, databases, and downstream systems.
3. Define control policy. Translate legal and risk requirements into explicit rules covering who or what can access which resource, for what purpose, under which conditions.
4. Enforce at runtime. Insert authorization at prompt or input, retrieval, tool and API invocation, and output points. Remove unnecessary standing privileges.
5. Add oversight tiers. Define actions that require deny, step-up, human approval, masking, filtering, or restricted parameter sets.
6. Validate evidence. Test policies, verify logs, and review authorization outcomes as part of control assurance and post-deployment monitoring.

A reference architecture for EU AI Act runtime controls

A common pattern keeps governance intent centralized while enforcing it at the points where AI systems actually act.

Layer	Components	What happens
1. Signals	SSO, directory, IGA, risk, agent metadata	Identity, entitlement, assurance, device, agent, task, and environmental context.
2. Policy	PlainID centralized authorization policy	Business rules translate governance intent into executable access decisions.
3. Runtime	Input, data, MCP and tools, APIs, output	Decisions occur at the moment an AI or agent workflow requests access or action.
4. Enforcement	Authorizers, gateways, frameworks, data platforms	Allow, deny, filter, mask, constrain parameters, or require step-up or human approval.
5. Evidence	Decision logs, policy lifecycle, observability	Traceability for monitoring, audit, review, incident investigation, and control testing.

From documented AI governance to enforceable controls

The EU AI Act raises the bar from documented AI governance to demonstrable operational control. PlainID helps close that gap by making access, action, and data-exposure policy enforceable at runtime, across the full agentic flow.

If your audit committee is asking what governs your agents, the fastest way to replace “evaluating vendors” with a real control story is to map your own flow to the Act.

In one working session, we walk your prompt, data, tool, and output points against the relevant articles, and show where authorization enforces each one, for human and non-human identities alike. Book a session with PlainID.