TL;DR: Agentic AI breaks the assumptions behind human and machine IAM because agents decide at runtime, chain tools, and act at scale, according to PlainID’s EIC 2026 session. Static login-time authorization leaves unauthorized data exposure and unintended actions undiscovered until after the fact, making runtime intent evaluation the new control boundary.
At a glance
What this is: This is an independent analysis of intent-based access control for AI agents and the key finding that static IAM controls do not transfer cleanly to agentic flows.
Why it matters: It matters because IAM, PAM, and governance teams now need to bind user, agent, data, tool, and context at runtime rather than assume login-time checks are enough.
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
👉 Read PlainID's analysis of intent-based access control for AI agents
Context
Agentic AI changes access control because the actor making decisions is not a person or a fixed service account. The primary problem is AI agent identity governance: agents can choose actions, tools, and timing at runtime, which makes login-time approval and static role assignment incomplete.
That gap matters across IAM, PAM, and NHI programmes because the same policy has to follow the user, the agent, the data set, the tool call, and the response. For background on the non-human side of that model, see the Ultimate Guide to NHIs and the OWASP NHI Top 10.
PlainID’s session frames the issue as one of runtime authorisation rather than prompt engineering alone. The central claim is that the policy boundary has to move from access granted at the door to intent checked at every step of the agentic flow.
Key questions
Q: How should security teams implement runtime authorization for AI agents?
A: They should enforce policy at each meaningful agent action, not just at login. That means checking the prompt, data access, tool invocation, and final response against the user's entitlement and the task context. The goal is to stop excess access from travelling through the agentic flow unnoticed.
Q: Why do AI agents complicate existing IAM and PAM controls?
A: AI agents complicate IAM and PAM because they do not behave like fixed service accounts or predictable human users. They decide at runtime which tools to use and which path to take, so a role assigned in advance cannot reliably describe the access needed for every step of execution.
Q: What breaks when access is approved only at login for agentic workflows?
A: What breaks is the link between the approved request and the later actions the agent takes. A prompt can look harmless, then lead to broader data retrieval, tool use, or response disclosure after approval. Login-only checks miss the context shifts that happen during execution.
Q: Who is accountable when an AI agent exposes data or takes an unintended action?
A: Accountability rests with the organisation that designed the policy, assigned the agent's scope, and failed to enforce context-aware controls. An AI agent cannot be treated as the accountable subject in the human sense, so governance has to trace responsibility through the user, platform, and policy owner.
Technical breakdown
Why login-time authorization fails for AI agent identity
Traditional IAM assumes the requestor is stable enough to assess once and then trust for the session. AI agents break that assumption because they chain operations, select tools mid-flow, and can expand the action path after the initial prompt is approved. That means the first authorization decision is not the only one that matters. In practice, the risk is not just excess permission at login. It is that the agent can legitimately enter with one purpose and then pivot into a different data set, tool, or response path before any human sees the outcome. That is why static checks underfit agentic behaviour.
Practical implication: move policy enforcement from login events to each runtime action the agent attempts.
Intent-based access control and the prompt, data, tool, response chain
Intent-based access control evaluates who is acting, what they are trying to do, and why now. In agentic systems, that has to be applied across four enforcement points: the prompt that starts the request, the data the agent can reach, the tools it can invoke, and the response it returns. Each point exposes a different failure mode. A user may be allowed to ask a question but not to trigger a refund. An agent may be allowed to read records but not to reveal every field back to the user. The model works only if the policy follows the whole flow, not one checkpoint.
Practical implication: define policies for each control point instead of relying on a single broad agent permission.
MCP, runtime authorization, and the agentic enforcement surface
Model Context Protocol gives agents structured access to external tools and services, which makes each tool call an authorization decision. That is useful only if the enforcement layer can decide in real time whether the specific call is allowed in context. The same issue appears across LangChain-style code agents, low-code platforms, and cloud agent runtimes. If policy lives only inside one stack, the control collapses when the agent moves to another runtime. The operational question is therefore not whether the agent can call tools, but whether one policy language can govern those calls wherever the agent runs.
Practical implication: validate that runtime authorization works consistently across frameworks, gateways, and cloud agent platforms.
NHI Mgmt Group analysis
Static authorization is the wrong control model for agentic identity. PlainID’s framing is directionally correct because AI agents are neither accountable like humans nor predictable like service accounts. A control model that assumes stable intent at login cannot contain a runtime actor that chooses tools and actions as it executes. The implication is that agent identity governance must be treated as a distinct programme surface, not an extension of human IAM.
Intent-based access control is a named concept practitioners will need to operationalise. The useful shift is not just continuous evaluation, but binding the user, agent, action, and context into one decision path. That creates a sharper governance model than role-only or operation-only authorization, especially when the same agent can read, summarise, modify, or act. Practitioners should treat this as a control architecture problem, not a policy wording exercise.
Agentic AI exposes a runtime governance gap that existing access reviews cannot close after the fact. Reviews assume a stable entitlement set that can be inspected later. Agent flows can chain decisions faster than review cycles can observe them, so the control failure happens before audit catches up. The implication is that identity governance for agents has to move upstream into the execution path itself.
OWASP NHI controls still matter, but they are no longer sufficient on their own for AI agents. Agentic systems inherit workload identity and secret exposure risks from NHI, yet add runtime selection, tool chaining, and response shaping on top. That makes the governance problem cross-domain rather than purely machine identity. The implication is that security leaders must align NHI controls with agentic-specific authorization patterns.
The market is converging on identity-first enforcement for agentic AI, and that will reshape buyer expectations. Vendors are increasingly forced to prove that policy can travel across code-first agents, low-code platforms, cloud runtimes, and gateways. Practitioners should therefore evaluate portability, policy consistency, and runtime visibility before they standardise on any agent platform.
From our research:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
- For the broader agent risk model, see OWASP Agentic AI Top 10 for the control categories practitioners are now expected to govern.
What this signals
Intent-based controls will become a baseline expectation for any serious agentic AI programme. The current pattern is not just tool sprawl, it is decision sprawl. Teams that treat agent access as a one-time provisioning issue will keep missing the runtime moments where privilege changes shape.
Identity teams should expect the policy architecture to move closer to the execution layer. The practical shift is toward runtime decisions that are consistent across frameworks, cloud runtimes, and gateways, with human approval reserved for exceptions rather than the normal path. For the surrounding control model, the OWASP Agentic AI Top 10 gives a useful external checkpoint.
With 98% of companies planning to deploy more AI agents in the next 12 months, according to our AI Agents: The New Attack Surface report, the governance window is already narrowing. That makes the policy design choice visible now, before agent count turns a control gap into an operating model.
For practitioners
- Map every agentic decision point Identify where prompts, tool calls, data retrieval, and responses are being authorized today. Document where a single login-time decision is still carrying the burden for later actions.
- Bind user and agent scopes together Define policies so the agent can never exceed the requesting user's entitlement just because it has broader technical access. Use the narrowest effective intersection for each task.
- Test policy portability across runtimes Verify that the same authorization intent survives movement across frameworks, low-code surfaces, cloud agent builders, and gateways. If policy changes by platform, the control model is fragmented.
- Add response-time controls for sensitive outputs Mask or redact high-risk fields when the final answer leaves the agent, especially when the upstream retrieval step was broader than the recipient should see.
- Treat shadow agents as part of governance scope Discover agent use inside SaaS tools and business workflows before the control gap widens. Unmanaged agents can create policy bypasses even when the main platform is covered.
Key takeaways
- AI agents break the assumption that access can be judged once at login and safely trusted thereafter.
- Current survey data shows the problem is already operational, not theoretical, with most organisations seeing agents exceed intended scope.
- Teams should shift to runtime intent evaluation across prompts, data, tools, and responses before agent sprawl makes retrofit control impractical.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | NHI-01 | Agent tool and decision misuse map directly to agentic identity controls. |
| NIST AI RMF | Runtime governance and accountability are central to AI risk management. | |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Continuous verification is needed when agent behaviour changes after login. |
Assign governance ownership for agentic access decisions and document operating boundaries.
Key terms
- Agentic Identity: An agentic identity is a non-human identity that can choose actions at runtime, select tools, and execute a sequence without a fixed script. In governance terms, it behaves less like a static account and more like a decision-making actor that needs continuous policy enforcement.
- Intent-based Access Control: Intent-based access control is a runtime authorization model that evaluates who is acting, what they are trying to do, and why in context. For agentic systems, it binds the user, agent, action, and data target together so policy can follow the full execution chain.
- Runtime Authorization: Runtime authorization is the practice of checking access when the action is about to happen, not only when the session starts. For AI agents, it is the control pattern that can see tool calls, chained operations, and changing context before they commit.
- Shadow AI: Shadow AI is the use of AI agents or AI-enabled workflows that operate outside official visibility or governance. In this context, the risk is not just unknown software, but unmanaged decision-making identities that can access data or tools without policy oversight.
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 responsible for identity security strategy or governance in your organisation, it is worth exploring.
This post draws on content published by PlainID: ALL NEW Agentic Identity Platform Intent-Based Access Control for AI Agents. Read the original.
Published by the NHIMG editorial team on 2026-06-26.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org