TL;DR: PlainID argues that agentic AI turns access control into a design-time test because agents can retrieve data, call APIs, and take actions autonomously, while Gartner says more than 50% of successful attacks against AI agents through 2029 will exploit access control weaknesses. Security by design now depends on runtime authorization, traceability, and least privilege embedded across agent workflows, not added after deployment.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on PlainID's blog post: Agentic AI makes access control a security-by-design requirement because autonomous agents can retrieve data, use tools, call APIs, and act without waiting for human approval.
Why it matters: It matters because IAM and governance teams now have to define and enforce least privilege, traceability, and runtime authorization for AI agents, not just for human users and static workloads.
By the numbers:
- More than 50% of successful cyberattacks against AI agents through 2029 will exploit access control weaknesses, according to Gartner research cited by PlainID.
- The average cost of a UK data breach reached £4.53 million, according to Gartner research cited by PlainID.
- 28% of breaches were linked to human error, according to Gartner research cited by PlainID.
- 15% of breaches were linked to third-party technologies, according to Gartner research cited by PlainID.
👉 Read PlainID's analysis of agentic identity security by design and access control
Context
Agentic identity security is the problem of controlling what an AI agent can access, decide, retrieve, and expose while it is operating at runtime. The article’s central claim is that these controls cannot be an afterthought once the agent already has tool access and execution paths.
That matters because agentic AI changes the access model itself. The security question is no longer only whether the system is authenticated, but whether every autonomous action is authorized in context, logged, and constrained before the agent can act.
The article frames security by design as the governance answer: build authorization, traceability, least privilege, and defense in depth into the workflow from the start. In agentic systems, that is an identity control problem as much as an application security problem.
Key questions
Q: When should organisations use runtime authorization for AI agents?
A: Use runtime authorization when agent behavior can change based on context, tools, or delegated workflows. Static approvals are too coarse when an agent can act across multiple systems in minutes. Runtime checks help keep privilege proportional to the current task and reduce the chance that a one-time approval becomes persistent excess access.
Q: Why do AI agents increase access risk compared with fixed workloads?
A: Because an agent can assemble its access path at runtime, the true blast radius is not always known at provisioning time. That makes standing credentials more dangerous, since a single reusable secret can unlock a chain of tool calls, APIs, and data sources that was never intended as a static workflow.
Q: What breaks when access control is bolted onto AI applications only at the code level?
A: Brittle, scattered enforcement creates inconsistent policy decisions and makes it easy for gaps to appear between ingestion, retrieval, and execution. Teams then lose traceability, struggle to maintain permissions changes, and increase the chance that unauthorized content reaches users or agents. A centralized authorization layer reduces drift and makes controls easier to audit.
Q: What is the difference between least privilege for humans and least privilege for AI agents?
A: Human least privilege usually maps to a job role, while AI-agent least privilege must map to a task, a time window, and a specific allowed action. Agents often combine planning and execution in one workflow, so broad roles are too loose. The practical standard is short-lived, operation-specific access with a clear stop condition.
Technical breakdown
Why runtime authorization becomes mandatory for AI agents
Agentic AI systems do not just request access once and then stop. They can decide when to retrieve data, which tools to call, and which API actions to execute inside a single task, which means the authorization decision has to happen at the moment of use. Static policy at onboarding is not enough because the relevant context can change after the plan begins. That is why the article treats authorization as part of the operating logic of the agent, not a wrapper around it. In identity terms, the control point shifts from initial access grant to continuous runtime enforcement.
Practical implication: enforce authorization at action time, not only at provisioning time.
How least privilege changes when the actor is an AI agent
Least privilege for an AI agent is not just a smaller permission set. It is a context-aware limit on what the agent can access, use, and disclose based on the task, the identity of the agent, and the surrounding data and tool scope. The article’s emphasis on prompts, MCP tools, APIs, data sources, and responses shows that the privilege boundary spans multiple layers, not a single service account. That makes overreach easier to miss because the agent can stay within a nominal role while still combining capabilities in risky ways.
Practical implication: define privilege boundaries across tools, data, and outputs, not only at account level.
Why visibility and traceability become identity controls
In an agentic environment, auditability is not just a logging requirement. It is the only way to reconstruct autonomous decisions, understand which data was retrieved, and determine whether a given action was appropriate. The article’s security-by-design model links visibility, traceability, and accountability because without those controls, policy enforcement becomes unverifiable. That is especially important when the same agent can touch multiple systems through APIs and MCP-connected tools. The identity question becomes not only who the agent is, but what it did, when it did it, and on what authority.
Practical implication: log each autonomous action and decision with enough context to prove authorization.
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.
- AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Security by design becomes the governing model once agents can act independently. Traditional IAM assumes an access request can be reviewed before a human or workload proceeds. Agentic systems collapse that assumption because decision and execution can happen inside the same runtime loop, so governance has to move from periodic review to enforced authorization at action time.
Visibility, traceability, and accountability are now identity controls, not just monitoring features. When an agent can retrieve data, use tools, and call APIs across multiple systems, the question is no longer only whether access existed. The more important question is whether the enterprise can explain why the access was used, what was touched, and whether the action stayed inside policy.
Least privilege for agentic AI is a scoped operating model, not a permission list. The article correctly points to prompts, MCP tools, APIs, data sources, and responses as the relevant control surface. That is the kind of multi-layer scope definition that current IAM programmes often fail to express cleanly, so practitioners need to treat agent privileges as a workflow problem rather than a single account problem.
Runtime authorization is the named concept that should anchor agentic identity governance. It describes the shift from granting broad standing access to verifying each autonomous action against current context. That shift is what turns agentic AI from an access-control exception into a design discipline for human, NHI, and autonomous identity programmes alike.
The market signal is clear: AI identity governance is moving into the access-control mainstream. As agent capabilities expand, the differentiator is no longer whether a platform can connect to tools, but whether the organisation can keep those connections governable. Practitioners should expect procurement, architecture, and risk teams to demand explicit runtime authorization and traceability requirements.
From our research library:
- The agentic AI market is already worth $5 billion and is projected to reach $50 billion by 2030.
- Read next: Agentic AI Identity Guide
What this signals
Runtime authorization is becoming the practical boundary for agentic identity programmes. Access review cadences were designed for identities whose privileges persist long enough to be reviewed. AI agents can consume and release access inside a single task, so the programme has to verify action authority at the point of use rather than waiting for periodic certification. This is where agentic AI identity becomes a governance discipline, not a model choice.
Agentic identity security will increasingly converge with zero trust and policy orchestration. Once agents can call APIs and tools independently, security teams need continuous verification across identity, context, and permitted action. Treating every agent-to-service interaction as untrusted until verified is the only way to keep autonomy inside enforceable boundaries, especially as more workflows move into production.
For practitioners
- Embed authorization into agent workflows Make runtime authorization part of the agent’s execution path so each data retrieval, tool call, and API action is checked before it can proceed.
- Scope privileges across the full agent surface Define what the agent may access, do, retrieve, and expose across prompts, tools, APIs, data sources, and responses, not just at account creation.
- Instrument autonomous actions for auditability Log each autonomous decision and execution step with enough context to reconstruct why the agent acted and whether the action stayed within policy.
- Apply zero trust to agent-to-service interactions Treat every agent interaction with downstream services as untrusted until the policy engine has verified identity, context, and permitted action.
Key takeaways
- Agentic AI turns authorization into a runtime governance problem because agents can make independent access decisions during execution, not just at login or provisioning time.
- The article ties this shift to breach economics, with Gartner cited on both a £4.53 million average UK data breach cost and more than 50% of successful attacks against AI agents exploiting access control weaknesses through 2029.
- For IAM and security teams, the practical response is to define privilege, logging, and verification around agent actions across prompts, tools, APIs, and outputs, not around a single account object.
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 and OWASP Non-Human Identity Top 10 address 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 agent access scope and authorization failures in autonomous workflows. |
| Recommendation — Apply ASI03 to constrain agent privileges and verify each action against current context. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Agentic workflows depend on identity-bound access that must be verified continuously at runtime. |
| NHI-05 — Overprivileged NHI | The article warns against broad agent access across prompts, tools, APIs, and data sources. | |
| NHI-10 — Human Use of NHI | Human oversight and agent governance overlap because humans still design and operate these identities. | |
| Recommendation — Treat agent authentication as continuous verification, not a one-time login event. Reduce standing permissions and scope agent access to the narrowest task-specific boundary. Separate human operator access from agent permissions and document who can override policy. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is fundamentally about governance structures for trustworthy agentic AI. |
| Recommendation — Establish governance for agent authorisation, logging, and accountability before scaling deployments. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core issue is whether AI agents are only given the permissions their task requires. |
| Recommendation — Use PR.AA-05 to review and enforce task-scoped permissions for each agent workflow. | ||
| NIST Zero Trust (SP 800-207) | Continuous verification — Continuous verification | Agent-to-service actions need ongoing verification because trust cannot be assumed after initial access. |
| Recommendation — Verify each agent interaction continuously instead of trusting inherited session state. | ||
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.
- Agentic Identity: An agentic identity is a non-human identity used by an autonomous system that can act, call tools, and access data with execution authority. It needs the same governance discipline as other privileged identities, plus runtime context, ownership mapping, and revocation paths.
- Secure-by-Design: Secure-by-design means security requirements are built into the development process rather than added after release. The practical aim is to define minimum acceptable controls early, then enforce them consistently so products cannot ship without passing baseline security checks.
- Identity Traceability: Identity traceability is the ability to link each action back to a specific identity, authorisation path, and time window. It is essential when humans, service accounts, and AI agents all operate in the same environment and auditors need a defensible record.
What's in the full article
PlainID's full article covers the operational detail this post intentionally leaves for the source:
- How the platform frames identity-aware authorization across prompts, MCP tools, APIs, and response handling
- The vendor's implementation-oriented explanation of security by design for agentic AI workflows
- The stated runtime authorization and traceability model for enterprises managing human and AI identities at scale
- The article's discussion of 35M+ managed identities and 99.99% uptime as part of its platform context
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 IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org