Runtime authorization for EU AI Act controls in agentic AI

At a glance

What this is: This is an analysis of how runtime authorization can turn EU AI Act obligations into enforceable controls for AI agents, with the key finding that conventional IAM is too static for action-time decisions.

Why it matters: It matters because IAM, IGA, and PAM teams now need to govern not only users and workloads, but also AI agents that act on behalf of people and systems under regulated conditions.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read PlainID's analysis of runtime authorization for EU AI Act controls

Context

The governance gap is not whether AI systems have policies on paper. The gap is whether access, data use, tool invocation, and output exposure are controlled at the exact moment an AI agent acts, which is where static IAM and broad RBAC usually stop.

For identity programmes, the EU AI Act turns AI agents into an operating concern for access governance. If an agent retrieves data, calls tools, or acts on behalf of a person in a regulated workflow, teams need runtime authorization that can enforce context, purpose, and risk at execution time.

Key questions

Q: How should security teams enforce the EU AI Act for AI agents at runtime?

A: Security teams should enforce the EU AI Act by moving control to the moment of action. That means deciding at input, retrieval, tool use, and output whether the request is allowed, constrained, masked, or denied. Static entitlements are not enough because agentic workflows can change scope after login.

Q: Why do IAM and RBAC fall short for agentic AI governance?

A: IAM and RBAC assign access before execution, but agentic AI needs decisions during execution. The risk is not just who authenticated, but what the agent is doing, on whose behalf, against which resource, and under what sensitivity or approval condition. Runtime authorization closes that gap.

Q: What should teams do first when AI agents can access regulated data?

A: Start by inventorying the agent, its tools, its data sources, and its outputs. Then define the exact conditions under which the workflow is allowed to retrieve data, invoke tools, and expose results. Without that map, you cannot enforce least privilege in practice.

Q: How do teams know whether AI governance is actually working?

A: Look for evidence that every AI interaction can be traced end to end, from identity and intent to output and enforcement. If auditors can ask for a transaction and receive a complete record in hours, not weeks, the programme is producing usable control evidence rather than just documentation.

Technical breakdown

Why static IAM and RBAC stop short of runtime authorization

Traditional IAM establishes identity and baseline entitlements, but it does not answer whether a specific agent action is allowed at the moment it occurs. Runtime authorization evaluates the user, the agent, the resource, the purpose, the sensitivity, and the environmental context together before letting the action proceed. That distinction matters in agentic AI because the same agent may touch multiple data sets, call multiple tools, and expose multiple outputs in a single session. The control boundary moves from login-time access to transaction-time decisioning.

Practical implication: treat login authorization as only the starting point and enforce policy again at retrieval, tool use, and output.

How AI Act obligations map to input, data, tool, and output controls

The article breaks the control problem into four runtime points: input, data, tools and actions, and output. Input controls decide whether the request is even allowed. Data controls filter records, rows, or columns before retrieval. Tool controls constrain which MCP tools, APIs, and parameters the agent may use. Output controls mask or block content before delivery. This is the mechanism that converts legal requirements like transparency, oversight, and risk control into enforceable policy decisions instead of after-the-fact review.

Practical implication: build policy enforcement at each decision point rather than relying on a single gateway or post-processing scan.

Why agent identity and user identity cannot be treated as the same boundary

An AI agent may operate under a service identity that is broader than the human requester. That means the user may be entitled to one slice of data while the agent’s technical identity can reach much more. Runtime authorization resolves that mismatch by binding the action to the user, the agent, the purpose, and the resource, rather than trusting the service account alone. In governance terms, the transaction is the boundary, not the agent or the human in isolation.

Practical implication: model agent access as composite identity plus context, not as a proxy for the human who triggered it.

NHI Mgmt Group analysis

Runtime authorization is becoming the control layer that separates AI governance intent from enforceable identity policy. The article is right to frame the problem as action-time enforcement rather than policy documentation. For identity teams, that shifts AI governance from advisory review into the same control discipline used for privileged access and sensitive data handling. The practical conclusion is that AI Act readiness is an access-control programme, not just a policy exercise.

The existing IAM model assumes authorisation can be settled before execution, but agentic flows make that assumption too coarse. The article shows why user login, service identity, and gateway control do not answer the runtime question of purpose, context, and output exposure. That is a material change for NHI governance because AI agents behave like non-human identities with broader, more dynamic reach than the person who initiated them. Practitioners should treat the agent workflow itself as the object of control.

Agent permission should be governed as a transaction boundary, not as a reusable standing entitlement. That framing matters because the same agent may retrieve data, invoke tools, and generate outputs in one flow, each with different policy conditions. In practice, this means access reviews and entitlement catalogues are no longer sufficient on their own. Security and IAM teams need decision evidence at the point of action, not only a record that access existed.

Action-time least privilege is the right named concept for this problem space. Least privilege is no longer just about what an identity is granted at provisioning time. In agentic AI, privilege must be evaluated continuously against the current request, resource, and purpose. That is why the AI Act pressure is pushing identity teams toward runtime policy enforcement, not broader static role design.

The AI Act exposes a governance gap that many organisations have already created for themselves through broad service identities. The same access pattern that makes automation easy also makes oversight weak when an agent can retrieve, transform, and disclose information faster than human review cycles can intervene. That is especially relevant for regulated sectors where accountability must be demonstrable, not assumed. Identity leaders should expect auditors to ask where control is enforced, not just where policy is written.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• That visibility gap makes runtime policy control more urgent, which is why the NHI Lifecycle Management Guide is the right next step for teams building inventory, rotation, and offboarding discipline.

What this signals

Action-time least privilege: this is the control pattern teams will need when AI agents can retrieve, transform, and disclose data faster than human review cycles can intervene. The governance model shifts from static entitlement review to decisioning at the exact point of access, which also aligns with NIST SP 800-207 Zero Trust Architecture.

For identity programmes, the immediate planning question is not whether AI exists in the stack, but where runtime decisions will be enforced for prompt intake, retrieval, tool invocation, and output. That control architecture will increasingly determine auditability, so teams should connect their AI governance work to the EU AI Act regulatory framework and their internal access policies.

As agent inventories grow, the practical challenge becomes the same one seen across NHI estates: visibility, lifecycle, and evidence. Organisations that cannot show which agent acted, what it touched, and why it was permitted will struggle to defend their controls in regulated environments.

For practitioners

• Map AI agent workflows to runtime decision points Identify where prompt intake, retrieval, tool invocation, and output generation occur, then require a policy decision at each point instead of trusting one pre-session grant.
• Separate user clearance from agent capability Document where the human requester is allowed less than the agent can technically reach, then constrain the agent to the user’s purpose and approved resource scope.
• Require step-up for high-risk agent actions Define which actions need human approval, such as sensitive retrieval, financial thresholds, or regulated disclosures, and block execution until the approval condition is met.
• Preserve decision evidence at the point of action Log the user, agent, purpose, resource, policy result, and output decision so the organisation can show what was allowed, filtered, masked, or denied.

Key takeaways

• The core issue is not AI policy volume, but whether AI actions are governed at the point of execution.
• Runtime authorization closes the gap left by SSO, RBAC, and API gateways when agents need context-aware access to data and tools.
• Identity teams should treat AI Act readiness as an enforceable control problem, with evidence captured at every runtime decision point.

Key terms

• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• Composite Identity: An identity made up of more than one control relationship, typically a human owner, an AI agent, and the credentials or services the agent uses. It matters because accountability, access scope, and runtime behaviour all have to be governed together, not as separate problems.
• Action-Time Least Privilege: Action-time least privilege means privileges are evaluated and constrained when the request occurs, not only when access is granted. For autonomous or semi-autonomous systems, this prevents broad standing access from turning into uncontrolled data use or tool invocation.
• Runtime Policy Enforcement: Runtime policy enforcement evaluates a request at the moment it is executed instead of relying only on preconfigured permissions. For AI agents, this allows decisions to reflect current context, target sensitivity, and behavioural signals rather than static assumptions.

What's in the full article

PlainID's full analysis covers the operational detail this post intentionally leaves for the source:

• Step-by-step runtime control mapping across prompt, retrieval, tool use, and output paths
• Capability descriptions for AI and agent discovery, central policy management, and composite identity context
• Implementation guidance for input guardrails, data retrieval guardrails, MCP and API guardrails, and output controls
• Auditability and policy lifecycle patterns for demonstrating enforcement evidence

👉 PlainID's full post covers the runtime control architecture, enforcement points, and evidence model in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.