Intent-Based Access Control for AI Agents

Security and IAM leaders have a narrow window with agentic AI that they did not have with human or machine identities. The controls for human IAM arrived late and never fully closed the gap. Machine identity followed the same pattern. Agents do not have to.

At EIC 2026 in Berlin, I walked through why the old control model fails for AI agents and what intent-based access control actually means in practice. The following draws on that session and expands the framing for security leaders evaluating where to place controls in their agentic AI programs.

Why agent identity breaks the controls built for humans and machines

Every IAM program built in the last twenty years rests on a quiet assumption that the identity on the other end of the request is either accountable or predictable. Humans are accountable. Machines are predictable. AI agents are neither, and the gap is wider than most security teams realize.

Human identities follow boundaries the organization can govern. People act on explicit requests, leave audit trails the team can question later, and stay inside the scope of their role most of the time. Machine identities behave differently but still stay controllable. A service account walks from A to B along a path defined when someone wrote the code. The scope is fixed and the behavior is repeatable.

AI agents do not work that way. They are designed to please the requester. If an agent has access to a tool, a dataset, or a downstream service, it will use whatever it can reach to complete the task. The path is not predetermined. The agent decides at runtime, based on the prompt and the resources available, what to do next.

And the agent is not accountable. Asking the agent why it pulled a record or called a tool is not the same conversation as asking an employee. The behavior is dynamic, the reasoning is opaque, and the action has already happened by the time anyone reviews the log.

Scale makes the gap worse. A single agent can spawn a thousand more inside a second, each with its own context and its own access decisions. The IAM controls the industry never fully solved for humans now have to govern an identity population that is orders of magnitude larger and behaves nothing like the population they were built for.

The shift is in behavior, not headcount. Treating agents like a bigger machine identity problem produces controls that look right and fail quietly in production.

Where traditional authorization fails the agentic flow

A fair question came up in the EIC session: isn’t this just read, write, and delete with extra steps? You define what the agent can do at each operation, you log it, you move on.

But the failure mode is not in the action list. It is whether the action is appropriate in context. Traditional authorization answers what can happen. It does not answer whether it should happen, given who is acting, what they are trying to do, and what they actually have the right to see.

Two examples I walked through on stage hopefully make the gap concrete:

1. A CRM agent gets a request from a sales rep: “summarize this quarter’s deal statistics.” The agent has access to the CRM. The agent runs the query. The summary returns deal data from across the company, including accounts the sales rep is not authorized to see. The operation succeeded. The data exposure is the failure. No one wrote a policy that said “an agent can pull deal data on behalf of a user.” But the agent did, because the agent’s access was broader than the user’s, and nothing in the flow bound the two together.

2. Same agent, second example. The agent has tooling access. It can search, list, send emails, and issue refunds. The sales rep asks about a customer complaint. The agent infers the rep wants to “please the customer” and issues a refund. The action happens. Nothing in the flow checked whether this user, in this context, through this agent, was allowed to take that action.

Both failures share the same shape. The agent succeeded at the task. The authorization model never got to evaluate intent. Unauthorized access, data exposure, and lost auditability all stem from one root cause: static authorization cannot read the why behind the request, and the agentic flow is full of moments where the why is the only thing that matters.

What intent-based access control actually means

The term gets used loosely, and at EIC, it got called out directly: the audience is still working out what it means in practice. So it might be worth defining it precisely.

Intent-based access control evaluates the why behind every access decision, continuously, at runtime. Three questions every decision has to answer:

• Who is acting? Not just the human user or just the agent, but the full chain. An agent acting on behalf of a user, possibly calling other agents, each with its own identity and its own scope. Intent considers all actors in the process.
• What are they trying to do? And “access the CRM” isn’t enough. What inside the CRM? US accounts or EU accounts Retrieve a record or issue a refund? Read or modify? The action and its target both matter.
• Why now? You need the context of the request. Time, location, prior steps in the flow, the prompt that started the chain. The same query at 8 a.m. from a known device looks different from the same query at 11 p.m. through a chained agent call.

The catch is that intent cannot be evaluated once, at the door, and then forgotten. The agent does not act in a single step. It chains operations together, picks tools mid-flow, and makes decisions that were not visible when the session opened. Login-time checks miss everything that happens after login.

So intent-based access control only works as runtime authorization. Each operation gets evaluated against policy at the moment it happens, with full context, before the action commits. The agent wants to retrieve that data, the policy engine answers in real time. The agent wants to call that tool, the policy engine answers in real time. The model Gartner describes in the 2026 IAM for AI Agents Reference Architecture Brief, where PlainID is listed as Example Technology, points to exactly this pattern: identity-first enforcement, evaluated at the runtime of each agent operation.

The four control points in the agentic flow

The agentic flow is a chain, not a single operation. Intent has to be evaluated at four distinct points along that chain, because each point exposes a different class of risk.

The response. Even when the data was retrieved legitimately, the response may contain elements the requesting user should not see. Masking sensitive fields at response time is the last control point in the chain.

The prompt. Not every user should be able to ask every question. An engineer asking an internal agent for financial reports is a policy decision, not a prompt-engineering decision. Prompt-level controls evaluate who is allowed to initiate which kinds of requests in the first place.

The data. Once a prompt is approved, the agent reaches for data. The agent’s access should be the intersection of what the agent can reach and what the requesting user is authorized to see. Without that binding, the CRM example becomes the default failure mode: the agent pulls everything it can, the user sees more than they should, and no one notices until audit.

The tools. Tool invocation is where Model Context Protocol gets real. MCP gives agents structured access to APIs, services, and downstream actions. Each tool call is an authorization decision. The same agent that should be allowed to list customer records may not be allowed to issue refunds. Tool-level enforcement, including at the MCP layer, decides which calls go through and which get blocked.

PlainID enforces all four through one PBAC policy language, with a native MCP Gateway, LangChain integration, and Authorizers for each runtime surface. The policy is authored once and applied across the flow. Dileep Moturi, Head of Data and Streaming Platform at Cisco, put the platform credibility plainly: “This is by far the most advanced authorization product on the market. Works well with CI/CD, policies can be exported/imported using modern REGO standard.” Cisco is using the same policy engine for application and data authorization that PlainID extends to the agentic flow.

Why agent platforms fragment the enforcement layer

The same control model has to apply across very different runtimes, and that is where vendor selection gets harder than it looks.

Agents live in many places. The map I walked through at EIC names four surface types security teams have to plan for:

• Frameworks. Code-first agents built by developers using LangChain, LangGraph, AutoGen, and similar libraries. Controls live where the code lives.
• Low-code platforms. Copilot Studio, Foundry’s no-code paths, and similar. The code is no longer where controls attach. Policy has to apply at the platform layer.
• Production runtimes. Azure AI Foundry, Bedrock AgentCore, Vertex AI Agent Builder, Snowflake Cortex, Databricks Mosaic. Each one has its own identity model, its own tool-call interface, and its own enforcement surface.
• AI gateways. Kong, Azure API Management, AWS gateways, and others sit in front of model and agent traffic. They are an enforcement point, but only for the calls that route through them.

For a buyer evaluating authorization platforms in 2026, the test is not whether the vendor handles one of these surfaces well. The test is whether one policy language travels across all of them. An authorization model that only works inside the cloud provider’s own agent runtime collapses the moment a business unit picks a different platform, which they will. The platform-neutral, identity-first, runtime authorization layer is the only architecture that survives the fragmentation.

Put the controls in before the agents do

Human IAM and machine identity both got the controls retrofitted, late, after the deployments were already in production. Agent identity does not have to follow the same path. The security and IAM teams reading this still have time to put the right model in place before the agentic AI estate gets to the scale where retrofit becomes the only option.

The work is sequential and practical:

• Discover where agents already operate inside the business, including the shadow ones inside SaaS platforms.
• Classify what data, tools, and actions those agents can reach.
• Define policies in intent-based terms, binding the human user, the agent, the action, and the context together.
• Enforce at all four control points, across every platform agents run on, with one policy language and one decision engine.

And if you need any help along the way, PlainID is here.