Notifications
Clear all
Topic starter
27/06/2026 1:03 pm
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.
NHIMG editorial — based on content published by PlainID: ALL NEW Agentic Identity Platform Intent-Based Access Control for AI Agents
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%).
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Map every agentic decision point Identify where prompts, tool calls, data retrieval, and responses are being authorized today.
- 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.
- Test policy portability across runtimes Verify that the same authorization intent survives movement across frameworks, low-code surfaces, cloud agent builders, and gateways.
What's in the full article
PlainID's full article covers the operational detail this post intentionally leaves for the source:
- Policy examples for binding the requesting user, the agent, and the action in one runtime decision
- The four control points in the agentic flow and how each one changes the authorization decision
- Platform-specific enforcement surfaces across code-first agents, low-code tools, cloud runtimes, and gateways
- The session framing and architecture discussion that show how PlainID positions intent-based access control in practice
👉 Read PlainID's analysis of intent-based access control for AI agents →
AI agent access control is the governance gap teams are missing?
Explore further
27/06/2026 2:13 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Intent-based access control is redefining AI agent governance
