TL;DR: PlainID outlines a five-layer Agentic IAM blueprint for governing AI agents through agent identity, discovery, policy management, authorization enforcement and observability, plus a maturity assessment and runtime access triad for enterprise integration. The underlying challenge is that agent access must be governed at runtime, not assumed safe because it sits inside existing IAM workflows.
Editorial analysis by NHI Mgmt Group, based on content published by PlainID: “Agentic IAM: A 5-Layer Architecture for Governing AI Agents”.
At a glance
What this is: This white paper presents a five-layer Agentic IAM architecture for controlling AI agents across identity, policy, enforcement and observability.
Why it matters: It matters because IAM teams need a governance model that can keep pace with autonomous execution, dynamic tool use and continuous access decisions.
👉 Read PlainID's white paper on agentic IAM architecture for governing AI agents
Context
Agentic IAM is the governance problem that appears when AI agents can decide, select tools and act against enterprise systems in real time. Traditional IAM was built around static identities and predictable access requests, but agentic workflows force security teams to control what an agent can discover, request, invoke and expose while it is operating.
This white paper frames that shift as an architecture question rather than a point-product problem. For IAM, IGA and PAM teams, the practical issue is how to extend identity controls into runtime decision-making without breaking existing enterprise identity systems or losing visibility into what the agent is doing.
The article is focused on governance design for agentic workloads, not on generic AI risk. That makes it most relevant to practitioners who are already dealing with identity policy, enforcement boundaries and observability for non-human actors.
Key questions
Q: How should security teams govern AI agents that can access enterprise systems?
A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.
Q: Why do human-centric IAM models break down for agentic AI?
A: Human-centric models assume relatively stable users, predictable workflows, and bounded access patterns. AI agents can change behaviour at runtime, chain tool use, and act without direct supervision, so one-time onboarding controls are not enough. Security teams need continuous authorization and lifecycle governance for the access they grant.
Q: What are the signs that AI agent governance is too weak for production use?
A: Weak governance usually shows up as poor visibility into what agents can access, incomplete audit trails, and inconsistent oversight across security, legal, compliance, and operations teams. Another warning sign is when organizations cannot explain which datasets an agent used or why it took a specific action. Those gaps make investigation, containment, and compliance far harder.
Q: What should teams do when an agent can request, use and expose data in one workflow?
A: Separate those decisions into distinct controls and do not assume one approval covers all three. Access, action and exposure are different risk surfaces, and collapsing them into one policy creates blind spots. Teams should bind each session to a narrow task scope and verify outcomes as the agent runs.
Technical breakdown
Five-layer control plane for AI agents
The proposed architecture separates agent governance into five functions: agent identity, discovery, policy management, authorization enforcement and observability. That matters because agentic systems fail differently from traditional applications. Identity alone does not tell you what an agent can do in-session, and policy alone does not prove what it actually accessed. The control plane must therefore bind who the agent is, what it can find, what rules govern it, how those rules are enforced and what it did after the fact. This is the minimum structure for moving from static permissioning to runtime governance.
Practical implication: Model agent governance as layered control points, not a single IAM control.
Runtime access triad for agent authorisation
The runtime access triad described in the paper covers what agents are allowed to access, do and expose. That is a useful way to think about agent authorisation because agentic behaviour spans data retrieval, tool invocation and output generation in one flow. In practice, these are different control decisions. Access determines what the agent may reach, action determines what it may execute, and exposure determines what it may reveal downstream. Without separating those three decisions, organisations often over-grant one dimension while under-seeing another, especially when agents chain tools across multiple systems.
Practical implication: Define separate policy decisions for access, action and exposure.
Enterprise IAM integration and zero trust for agents
The article also treats agentic IAM as an integration challenge with legacy identity systems. That means the goal is not to replace enterprise IAM, but to extend it into dynamic, context-aware decisioning for non-human actors. Zero Trust for agents depends on continuous evaluation of identity, task context and runtime behaviour rather than one-time approval at onboarding. For teams, the technical challenge is to make agent sessions observable and revocable without relying on the assumption that the agent will behave like a stable human user or a conventional service account.
Practical implication: Extend existing IAM policy into continuous, context-aware runtime checks for agents.
Threat narrative
Attacker objective: The objective is to obtain and use enterprise access in ways that exceed the intended agent governance boundary.
- Legitimate access is granted to an AI agent that can operate across enterprise tools and data sources.
- During the session, the agent expands its scope by selecting additional tools or data paths needed to complete its task.
- If policy boundaries are weak, the agent can expose data or execute actions beyond the intended governance boundary.
- The impact is uncontrolled non-human activity across systems that were assumed to be governed by static identity rules.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Agentic IAM is no longer an extension of workload identity, it is a separate runtime governance problem. The five-layer blueprint is useful because it acknowledges that identity, discovery, enforcement and observability are distinct control functions for AI agents. Organisations that treat agents as just another service account will miss the behavioural layer entirely. The practitioner conclusion is that agent governance needs its own operating model, not a label applied to existing IAM.
The decisive control question is not whether an agent has access, but whether its access can be bounded at runtime. Static authorisation models assume a stable subject with predictable intent, but agentic systems can change tool use, sequencing and exposure decisions mid-task. That collapses the assumption behind provisioning-time least privilege. The implication is that access governance for agents must be evaluated at execution time, not only at enrolment.
Agent identity discovery becomes a prerequisite for any credible control plane. If organisations cannot inventory which agents exist, which tools they can reach and which policies govern them, enforcement becomes partial by design. That creates a blind spot for both security and audit teams. The practitioner conclusion is that agent discovery is not a reporting exercise, it is the starting point for control.
Runtime access triad: access, action and exposure must be governed as separate decisions because agentic behaviour crosses all three in one session. This is the clearest named concept in the paper because it captures the difference between traditional application authorisation and agentic authorisation. Teams that collapse those decisions into one policy layer will over-trust the agent or under-constrain it. The practitioner conclusion is to design policy around task-scoped runtime outcomes, not only identity attributes.
Agentic IAM validates Zero Trust for non-human actors, but it also raises the bar for observability. Continuous verification only works when the control plane can see what the agent requested, what was allowed and what was actually done. That makes logging, correlation and post-action review central rather than secondary. The practitioner conclusion is that observability is not an afterthought in agent governance, it is part of the control itself.
From our research library:
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
- Read next: Agentic AI Identity Maturity Model
What this signals
Agentic IAM shifts the control point from provisioning to execution. Security programmes that still treat AI agents like long-lived service accounts will miss the moment when a task expands beyond its approved scope. The practical response is to redesign governance around runtime decisions, because that is where the risk now lives.
Access review cadences are not enough for agentic systems. If a subject can obtain, use and release privilege inside one task, there may be nothing meaningful left to certify after the fact. That is why agent discovery, policy boundaries and observability need to move upstream into the execution path.
Runtime access triad: access, action and exposure are the three decisions practitioners need to govern separately for AI agents. That distinction helps identity teams avoid the common mistake of treating agent authorisation as a single yes-or-no permission model.
For practitioners
- Define a separate agent identity inventory Track every AI agent, the systems it can reach, and the policies that govern each session so discovery is not left to ad hoc logging.
- Split policy into access, action and exposure rules Write distinct controls for what an agent may access, what it may do, and what it may disclose to downstream systems or users.
- Add runtime enforcement to existing IAM workflows Require context-aware checks at execution time so approval at onboarding does not become the only control point for agent behaviour.
- Instrument agent observability for audit and response Capture requested tools, granted permissions, outputs and denied actions so security teams can reconstruct agent behaviour after the fact.
Key takeaways
- AI agents need a runtime governance model that separates identity, discovery, enforcement and observability.
- The paper's core contribution is the runtime access triad, which splits agent control into access, action and exposure.
- IAM teams should stop treating agents like static workloads and start governing them as execution-time identity subjects.
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 addresses the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 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 | ASI03 — Identity & Privilege Abuse | The article centres on controlling agent identity and privilege at runtime. |
| ASI02 — Tool Misuse | The control plane is built around what tools an agent can discover and invoke. | |
| Recommendation — Apply ASI03 to bound agent privileges during execution and detect privilege abuse as tasks unfold. Map agent tool access to ASI02 and restrict tool invocation to task-scoped policies. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The paper is fundamentally about governance structure and accountability for AI agents. |
| Recommendation — Use GOVERN to define ownership, approval paths and accountability for agentic IAM controls. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Agent access permissions and runtime entitlements are the core control problem here. |
| Recommendation — Apply PR.AA-05 to continuously verify and constrain agent entitlements during runtime. | ||
| NIST Zero Trust (SP 800-207) | Continuous verification — Continuous verification | The article advocates context-aware, continuous checks for non-human actors. |
| Recommendation — Adopt continuous verification for agent sessions so authorisation is re-evaluated as context changes. | ||
Key terms
- Agentic IAM: Agentic IAM is identity and access management designed for environments where AI agents make independent decisions and take actions. It combines authentication, authorization, delegation, monitoring, and revocation so agent autonomy is constrained by policy, context, and accountability rather than open-ended system trust.
- Runtime Access Triad: The runtime access triad is a governance model that separates what an AI agent may access, what it may do and what it may expose. It is useful because agentic systems often cross those boundaries in one task, which makes single-step authorisation too coarse.
- Agent Discovery: Agent discovery is the process of finding every AI agent across cloud platforms, low-code tools, repositories, and deployment pipelines. It matters because governance cannot start until the organisation can see where the agent exists, who owns it, and what it can reach.
- Authorization Enforcement: Authorization enforcement is the control that decides whether a tool call is allowed to run. In an MCP environment, it should evaluate the agent, the acting user, the tool, and the arguments before execution. This keeps access decisions external to the server and supports fail-closed operation.
What's in the full article
PlainID's full white paper covers the operational detail this post intentionally leaves for the source:
- Layer-by-layer architecture guidance for agent identity, discovery, policy management, enforcement and observability
- Step-by-step maturity assessment structure for evaluating current agentic IAM posture
- Practical integration patterns for connecting dynamic agent workflows to legacy enterprise identity systems
- Runtime access triad examples showing how to govern access, action and exposure separately
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 5, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org