AI agent taxonomy is also an identity-surface taxonomy

At a glance

What this is: This is a framework for choosing among seven AI agent types, with the central finding that agent selection is also an identity and authorization decision.

Why it matters: It matters because IAM, PAM, and NHI teams must govern agents as machine actors with different delegation, audit, and privilege patterns, not as generic automation.

👉 Read Ory's guide to choosing the right AI agent architecture

Context

AI agent architecture is not just a product choice, it is an identity governance choice. Once an agent can perceive state, select actions, and execute against real systems, the control question shifts from whether it works to what identity it uses, what it can reach, and how much authority it holds.

The article is useful because it connects agent taxonomy to the access model behind it. For IAM and NHI programmes, that means the same design decision that affects planning, memory, and coordination also shapes authentication, authorization, auditability, and delegation tracking across machine identities and agentic workflows.

Key questions

Q: How should security teams govern AI agents that can choose tools at runtime?

A: Security teams should govern runtime agent choice as an access event, not as a simple application action. That means scoping permissions to the task, limiting token lifetime, logging every tool decision, and blocking the agent from reaching systems outside its approved context. Static roles alone are not enough when the execution path changes on each run.

Q: Why do AI agents complicate least-privilege design?

A: AI agents complicate least-privilege design because their tool use can change dynamically while the underlying permissions remain persistent. The system may need broad enough access to complete a task, but that same access can overshoot if scope is not tightly controlled. The fix is task-scoped authorisation with clear boundaries, not wider standing access.

Q: What do teams get wrong about LLM-based agents and identity?

A: They often secure the model and ignore the runtime. The model is only one component. The real risk sits in the orchestration layer that decides what tools can be called, what data can be reached, and whether actions are approved, recorded, and attributable.

Q: How is multi-agent identity different from single-agent identity?

A: Multi-agent systems introduce delegation chains, shared state, and multiple points of failure. Security teams need to know which agent initiated an action, which sub-agent executed it, and which service identity crossed the boundary into production systems. Without that chain, accountability collapses quickly.

Technical breakdown

How agent architecture changes the identity surface

The taxonomy runs from simple reflex agents through multi-agent systems, but the security boundary changes with each step. A reflex agent maps input to action with little state, while goal-based and utility-based agents introduce planning and choice among multiple outcomes. Learning and hierarchical agents add feedback loops and delegated sub-functions, which means more tokens, more service boundaries, and more places where identity context can drift. Multi-agent systems add explicit communication paths between actors, so identity is no longer attached to one process but to a delegation chain.

Practical implication: Model identity separately for each agent role, sub-agent, and service boundary before the system reaches production.

Why LLM-based agents blur classical categories

LLM-based agentic systems do not map cleanly to one classical type because the model, the tool layer, and the orchestration layer each contribute different behaviour. The LLM provides reasoning, but the surrounding system decides whether it can call tools, retain memory, or act without approval. That is why an LLM is not itself the security subject. The identity subject is the runtime system that combines model output with authenticated tool access and execution authority.

Practical implication: Treat the agent runtime, not the model alone, as the unit for authentication, authorization, and audit design.

Why every agent type becomes an identity problem in production

The article is right to frame agent taxonomy as an identity-surface taxonomy. As soon as an agent touches APIs, databases, or downstream workflows, it needs machine credentials and traceable authorization. The risk is not merely compromise. It is privilege mismatch, where the architecture chosen in design does not match the delegation pattern that appears in production. That mismatch is what creates brittle rewrites, hidden access paths, and audit gaps.

Practical implication: Align credentials, delegation, and logging to the actual runtime pattern rather than the intended diagram.

Threat narrative

Attacker objective: The objective is to use legitimate agent authority to reach systems, data, or actions beyond the intended task boundary.

1. Entry occurs when a legitimate agent runtime receives access to tools, APIs, or downstream services needed to perform its task. Escalation begins when the chosen architecture adds planning, memory, or delegation layers that widen the number of identities and authorizations in play.
2. Impact follows when the agent's runtime authority is broader than the task requires, allowing one agent or sub-agent to affect systems at machine speed with weak human review. In multi-agent systems, compounded impact can arise from chained actions across several identities.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agent taxonomy is also an identity-surface taxonomy: the security problem is not the label on the agent, but the delegation pattern it creates. Simple reflex, hierarchical, and multi-agent systems each expand the number of identities, trust relationships, and audit points that IAM must govern. The practitioner conclusion is that architecture selection and identity design cannot be separated.

Least privilege becomes harder to define as the agent becomes more capable: a task-scoped credential is easy to describe for a single action, but much less stable when the agent plans, learns, or delegates. That does not mean privilege disappears; it means the privilege boundary moves into runtime behaviour, which is harder for traditional provisioning models to express. Practitioners should treat this as a design constraint, not a policy footnote.

LLM-based agents need runtime governance, not model-level trust: the article correctly distinguishes the model from the system that gives it memory, tools, and execution authority. That distinction matters because many governance failures happen above the model layer, where orchestration determines whether an action is approved, logged, or chained. The implication is that identity controls must sit on the tool boundary and the delegation boundary, not just around model access.

Multi-agent systems multiply accountability gaps unless delegation is explicit: once one agent writes code, another reviews it, and a third executes it, the security issue is not only what each agent can do. It is whether the chain preserves traceability from initiating intent to final action. In NHI terms, this is delegated access without clear lifecycle ownership, and it becomes the dominant governance problem in agentic environments.

Identity governance for autonomous systems must account for action speed, not just permission scope: the article's strongest implication is that agent systems can execute decisions faster than conventional review cycles can observe them. Existing IAM assumptions about stable, reviewable access states do not hold when authority is instantiated, used, and retired inside the same operational window. Practitioners should therefore redesign governance around runtime evidence, not periodic certification.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including unauthorised system access, sensitive data sharing, and credential exposure.
• That trajectory makes OWASP Agentic AI Top 10 the natural next reference point for runtime tool access and delegation risk.

What this signals

Identity programmes will need a new control plane for agent runtime authority: as agent systems spread, the question is no longer whether they can authenticate but whether each action remains attributable and bounded. Teams that still treat agent access as a subset of application access will miss the delegation and timing differences that create the real risk.

The practical signal is that governance will move from periodic review to continuous evidence. That shift aligns with the broader identity direction in the Ultimate Guide to NHIs, especially where machine identities, offboarding, and lifecycle ownership intersect with dynamically created agents.

Agent taxonomy now shapes identity architecture decisions: a planning agent, a learning agent, and a multi-agent system do not merely have different features, they produce different trust graphs. Security teams should expect their identity model to become more granular as soon as tool use and delegation enter production.

For practitioners

• Define the agent identity boundary Map each agent, sub-agent, and tool-calling service to a distinct identity so authentication and authorization are not flattened into one shared runtime credential. This is especially important when planning, memory, and delegation are split across components.
• Separate model access from execution authority Allow the model layer to reason, but gate tool use, data access, and side effects through a controlled runtime boundary with explicit policy enforcement and logs.
• Track delegated actions end to end Preserve traceability from initiating request to final system change, including parent agent, sub-agent, and downstream service account relationships.
• Rework reviews around runtime evidence Use logs, policy decisions, and delegation records to validate agent behaviour instead of relying only on periodic access recertification, which may miss short-lived or chained actions.

Key takeaways

• The article shows that AI agent type is an identity design decision, not just an architecture preference.
• Machine-speed planning, delegation, and tool use make runtime authorization the central control problem for agentic systems.
• Security teams should model each agent boundary explicitly or risk brittle access paths, weak accountability, and overbroad privilege.

Key terms

• AI Agent Taxonomy: A structured way to group agents by how they perceive, decide, and act. In identity terms, the taxonomy matters because each step up in autonomy usually adds more credentials, more delegation paths, and more audit complexity, even when the underlying model is the same.
• Delegation Chain: A delegation chain is the sequence of identities, credentials, and tool calls an agent uses to complete a task across systems. It matters because each step may appear acceptable on its own while the combined path produces an outcome no reviewer would have approved directly.
• 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.
• Machine Identity: The digital identity of a machine, device, or workload — such as a server, container, or VM — used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.

What's in the full article

Ory's full post covers the architectural detail this analysis intentionally leaves for the source:

• The seven-agent taxonomy with concrete examples for each agent type and their decision patterns.
• The decision framework for selecting an agent architecture based on observability, goal complexity, learning, and coordination needs.
• The identity and authorization implications of LLM-based agents, including tool use, memory, and autonomous action capabilities.
• The product-specific Ory identity stack discussion for teams that want the implementation context behind the architecture.

👉 Ory's full post covers the seven agent types, decision logic, and identity implications in more implementation 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 identity controls across human and non-human systems, it is worth exploring.