Agentic security is really an IAM problem for AI agents

At a glance

What this is: This is an analysis of why agentic security maps back to identity and access management, with the key finding that AI agents should be treated as non-human identities with scoped credentials and revocable access.

Why it matters: It matters because IAM, PAM, and lifecycle teams now have to govern agent behaviour, not just authenticate users or workloads, or the blast radius of a compromised agent will expand faster than existing controls can respond.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.

👉 Read Ory's analysis of agentic security as an IAM problem

Context

Agentic security is the problem of governing software that can decide, act, and call tools on its own. In this article, that problem is framed as an IAM issue because AI agents need identities, scoped permissions, visibility, and revocation just like other non-human identities.

The key governance gap is that many teams still treat agents as if they were ordinary application components or chat interfaces. Once an agent can read untrusted content, access private data, and communicate externally, existing control assumptions about user intent, permission stability, and review cycles start to break down.

That starting point is typical for teams building agentic systems quickly. The article argues that the right response is to put identity and authorization at the control plane, rather than relying on prompts, guardrails, or ad hoc isolation to contain behaviour after the fact.

Key questions

Q: How should organizations approach the governance of AI agents?

A: Organizations should adopt a governance framework that incorporates continuous visibility, adaptive IAM practices, and stringent policy-based controls. This ensures that all agent actions are tracked, authorized appropriately, and assessed for compliance.

Q: Why do AI agents complicate least privilege in IAM programmes?

A: AI agents complicate least privilege because their useful scope is often broader than a traditional service account, but their actual authority should still be narrower at each action. The control has to move from static entitlement management to request-time decisioning, especially for tool use and downstream side effects.

Q: What breaks when retrieval permissions are not separated from execution permissions?

A: A compromised agent can use the same access path to discover content and then act on it, which expands blast radius fast. If the retrieval layer and the action layer are not distinct, one injected document can lead to tool misuse, data exposure, or outbound abuse without a second authorization check.

Q: How do organisations keep accountability when agents act on behalf of users?

A: They need a provenance model that links the user, the agent, the tool call, and the runtime decision together. Without that chain, audit records show that something happened but not who effectively authorised it or why. Accountability depends on preserving context through the full delegated workflow.

Technical breakdown

Why agentic apps turn bad input into bad actions

Traditional web applications usually turn malformed or malicious input into incorrect data. Agentic applications are different because the model can convert untrusted input into tool calls, API requests, file access, or outbound messages. That means prompt injection and content injection are not just text-quality problems. They are execution problems. If an agent can retrieve content, interpret it, and then act on it without a separate authorization boundary, the attacker is no longer shaping output. They are steering behaviour through the agent's own privileges.

Practical implication: place authorization outside the model so malicious content cannot expand the agent's effective permissions.

How retrieval-layer authorization limits blast radius

Retrieval-augmented generation creates a new control point because the agent only sees what it is allowed to retrieve. Authorization at this layer determines which documents, data sources, or tools an agent may reach, which is different from preventing the injection itself. The article makes the important distinction that this limits blast radius after compromise rather than stopping the malicious payload from entering the context window. That is why retrieval controls, egress filtering, and human checkpoints solve different parts of the same problem.

Practical implication: govern retrieval permissions separately from content trust, because one controls exposure and the other controls abuse.

Why agent identities need scoped credentials and revocation

Agents become governable when they are treated as non-human identities with explicit authentication, scoped credentials, and revocation paths. Shared or inherited access makes compromise contagious because the agent can pivot across tools and data sources. Short-lived tokens, federation, and infrastructure-level permission boundaries reduce that risk by making access task-scoped rather than ambient. The article also points to hierarchical agent structures, where humans remain accountable at the top and permissions flow downward through orchestrators and executors.

Practical implication: issue agent credentials the same way you would govern any other high-risk non-human identity, with minimum scope and a clear owner.

Threat narrative

Attacker objective: The attacker wants to hijack the agent's existing privileges so injected instructions become real actions, data exposure, or unauthorized external communication.

1. Entry occurs when the agent ingests malicious content from a document, web page, email, or MCP tool response that contains embedded instructions.
2. Escalation happens when the agent uses its existing permissions to call tools, access private data, or send external messages in ways the user never intended.
3. Impact follows when the agent's access is broad enough to spread the damage across APIs, files, or downstream systems before the abuse is detected.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

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 security is an IAM problem because the control surface is identity, not the prompt. The article correctly frames the shift from text safety to action safety. Once an AI system can fetch content, call tools, and communicate externally, the governance question becomes who or what is allowed to do those things. That is an IAM question with execution consequences, and practitioners should treat agent authorization as part of the identity control plane.

Identity does not select or combine tools dynamically mid-session in the way agentic systems do. That assumption was designed for actors whose intent can be modelled before execution begins. It fails when the actor is autonomous enough to decide which data source, API, or tool to call at runtime. The implication is not simply more policy. It is a rethink of whether static privilege definitions can describe agent behaviour at all.

Retrieval-layer permissioning is a blast-radius control, not an injection control. The article is right to separate where malicious content enters from how far it can travel after entry. That distinction matters because many teams overstate the value of content filtering while underinvesting in authorization boundaries around data sources, outbound channels, and tool execution. Practitioners should stop treating these as interchangeable defenses.

Shared or inherited credentials are the fastest route to agent privilege sprawl. Agents that borrow ambient access inherit the worst part of legacy service-account design without any of the operational discipline. Scoped, revocable, task-bound credentials are the minimum viable model for making agent behaviour auditable. The field should expect agent identity governance to converge with the same lifecycle discipline used for other high-risk NHIs.

Hierarchical agent orchestration only works if accountability stays human at the top. The article's model of strategic agents delegating to executor agents is useful, but it does not remove the need for a named human owner for each permission boundary. That is the governance line that keeps agent chains from becoming accountability-free systems. Security teams should define ownership before they scale delegation.

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 the 2026 Infrastructure Identity Survey.
• 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.
• That visibility gap is why OWASP NHI Top 10 and 52 NHI Breaches Analysis are useful next reads for teams building agent governance.

What this signals

Agent identity governance is now a control-plane issue, not a model-safety side topic. With 80% of organisations already reporting agent behaviour beyond intended scope, the programme risk is no longer theoretical. Teams that have not separated retrieval, execution, and revocation will find that their IAM model absorbs the failure later, after the blast radius has already expanded.

Scoped credential design will matter more than prompt policy as agent adoption scales. The strongest operational pattern here is to combine unique identities, short-lived tokens, and named ownership with infrastructure-level enforcement. That is the only way to keep agent chains auditable when orchestration grows across tools, data sources, and downstream executors.

The practical signal to watch is whether your identity programme can answer three questions for every agent: what it may read, what it may do, and who is responsible when it misbehaves. If any of those answers live only in documentation, the control is not yet real.

For practitioners

• Treat agents as governed non-human identities Assign each agent a unique identity, explicit owner, minimum permissions, and a revocation path. Avoid inherited application credentials and make every agent action traceable back to a human accountable for that permission boundary.
• Separate retrieval trust from execution trust Apply access controls to the documents, APIs, and tools an agent can retrieve, then enforce a second boundary on what it can call, send, or write. That separation reduces blast radius when malicious content enters the context window.
• Use short-lived credentials for agent-to-agent and tool access Replace static shared secrets with short-lived tokens or federated credentials so a compromised agent cannot reuse the same access across sessions or systems. Build revocation into the control path, not as an afterthought.
• Define human ownership for every agent permission chain Map orchestrators, planners, and executors back to a named human owner. If a permission cannot be assigned to an accountable person, it is not ready for production use.

Key takeaways

• Agentic security fails where IAM assumptions fail, because AI agents can turn untrusted content into real actions.
• Visibility and control are already lagging, with most organisations reporting out-of-scope agent behaviour and many unable to audit access.
• The safest operating model is scoped agent identity, separate retrieval and execution boundaries, and explicit human ownership for every permission chain.

Key terms

• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Retrieval-layer Authorization: Retrieval-layer authorization is the control that decides which data sources, documents, or records an agent may access before the model uses them. It limits blast radius, but it does not stop injection itself, so it must be paired with execution controls.
• Scoped Credential: A scoped credential is a secret, token, or certificate that can only perform a narrow set of actions for a limited time or workflow. For NHI governance, scoped credentials reduce blast radius by preventing an agent from reusing broad access across unrelated systems or tasks.
• Permission Boundary: A permission boundary is the enforceable limit on what an identity can do, regardless of how it behaves. For AI agents, this boundary matters more than session logs because it determines whether an action is possible in the first place.

What's in the full article

Ory's full blog post covers the operational detail this post intentionally leaves for the source:

• Token issuance and revocation patterns for agent identities across tools and APIs
• The hierarchical agent permission model with orchestrators, planners, and executors
• How Ory Hydra supports OAuth-based access control for agent workflows
• Where ReBAC-style permissioning fits when agents need delegated access across systems

👉 The full Ory post covers token issuance, scoped credentials, and delegated agent permissioning in more operational detail.

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, PAM, or identity governance programme, it is worth exploring.