Why We Need an AI Agent Taxonomy Right Now But We Can’t Have One

If you’re having conversations about AI Agents and security right now, then you’re likely hearing what I’m hearing. There are many statements that say things like “AI Agents will…” or “... something something using AI Agents.” Statements like that point to a fundamental problem. AI Agents are being treated as a monolith. People often identify the right problems and challenges, but they paint them with a broad brush. They act as if they all apply to every agent equally. When you look at the agents everyday users interact with today, the idea that they all have the same security posture falls apart pretty quickly. That’s what motivated me to take a shot at creating an AI Agent taxonomy that would be applicable in a security context. Sadly, that idea fell apart pretty quickly as well. 

The Problem is Real

Seeing the problem is easy. If you run Claude Code on your desktop, typically it can access everything you’ve set up in your development environment. Acting as you, it uses your saved keys and tokens, environmental variables, and other desktop systems. You already know that’s different than asking Gemini in a browser to search things for you. These are both “agentic” to some degree. But your security exposure in both scenarios is very different. This isn’t to say that the Gemini in browser scenario is “simple” and the Claude Code one is “complex” (a generalization I hear often). Most people (including myself) don’t have a full picture of how complicated Gemini is behind the scenes. One common aspect of both scenarios is the use of sub-agents. Claude Code absolutely will spawn sub-agents to accomplish specific tasks. Gemini likely does, but there’s no way to tell from our point of view. In either case, these sub-agents represent a whole other layer of security context that only adds to this multi-layered problem. 

So if the problem is real and as easy to see as this, doesn’t it beg for a solution which breaks down different agent types and then applies the right security approach for each type? Doesn’t it lead naturally to a taxonomy? I thought it did. I still think it may at some point. But the devil is in the details. There is a desire for a taxonomy, but creating one turns out to be harder than I imagined. At least, it is right now. Like many other things in AI today, the problem is acceleration. Imagine we were thinking this through 6 or 12 months ago. What would the conversation look like? Would it use the same terms, examples, and ideas that we’ve discussed here so far? Likely not. This is the problem with the taxonomy we may make today. It would become ill-fitting more quickly than it would become useful. 

A Tactical Approach For Now?

That’s not to say there’s nothing useful to do right now. I started where I often do these days: chatting with Claude and Gemini about it all. What Claude gave me is actually quite good for the moment we’re in right now. It hinges an agent’s security context on 6 dimensions:

1. Authority. Who does this agent act as? Is it working “on behalf of” (OBO) or delegated? Does it have its own NHI/workload identity? Is it hybrid using both models switching per-action?
2. Execution Location. Is it running local/on-device? Is it embedded in some SaaS service? Is it running in a cloud tenant you own?
3. Trigger. Is it interactive (i.e., a human is present)? Is it ambient or event-driven? Does it run on a scheduled batch?
4. Persistence. Is it ephemeral? Is it durable or even resumable? Is it a long-running daemon?
5. Delegation. Is it standalone? Is it an orchestrator of other agents? Is it a sub-agent? Does it act as an A2A peer?
6. Tool Reach. Is it fully sandboxed? Does it have a fixed allowlist of tools? Can it discover tools at runtime? Does it have cross-domain reach?

If you start breaking down agents you touch today using these six dimensions, then you can get pretty far. Take the Claude Code on your desktop example from earlier. This has access to all your authority on your desktop, executes at your location (right there in your command window or IDE), has multiple triggers (though many only use it interactively), can be resumable and persistent if you let it be, delegates tasks to sub-agents, and has broad use of non-sandboxed, cross-domain tools and the ability to discover more at runtime in its default (and typical) setup. If you left out the name “agent” and just gave those properties for an application, it would be pretty clear there are significant security issues to address. Compare that to something like an AgentForce agent running in the SalesForce platform. Most if not all of those measures get flipped. And the security context for each becomes more clear; especially as you contrast the two and consider different approaches to reigning them in. 

What I wanted was something like a biological classification with family, genus, and species distinctions. But reading all the current approaches and related literature makes me feel it’s likely too early for something that big. I wanted to say if the agent has x and y properties, that makes it an agent of species A which is part of genus B, etc. The trouble is that agents today don’t run that neatly. Two people can set up Claude Code very differently and therefore give it very different properties (e.g., some will run in a container that acts like a tightly scoped sandbox). Some organizations will take the SaaS resident agents in AgentForce and arm them with tons of cross application and cross cloud tools making them break all the way out of the SaaS cage they mostly live in. We started with the problem of agents being treated like monoliths, but we find the problem can also be that agents can morph so much that they become unclassifiable.

The Wrong Idea for The Wrong Kind of Thing

It’s easy to imagine agents have been with us for a long time given how complex they already are. The reality is it’s an emerging space. If you looked at what agents were 6, 12, and 18 months before now, you’d see very different things. That tells me we can’t even be sure that what we’re dealing with now is even the same kind of thing we’ll deal with later. To return to the biological analogy, it’s like when scientists recently realized that Prototaxites were neither animal, plant, nor fungus and to reorder the whole tree of life. If you’re not careful, you can put something you don’t fully understand into the wrong category and then make all sorts of errors. If we pre-emptively classify these agents, we could be sorry. 

My goto idea for this is pointing out that AI agents are actually more like traditional human agents in many cases. Your travel agent may book your travel, but they don’t carry your passport. This neatly maps to identity ideas when you hear people talk about OBO (on behalf of) flows. Often they want to issue tokens that are essentially the users to these agents to act on behalf of them. But in many cases you want something entirely different. A very clear example of that is when you call an agent in a call center to adjust something in your account with some company. That agent has powers you never will to access back ends of systems to make those changes. They act for your benefit using access you can’t give them. We don’t really have a formal concept like that today, but agents of these kinds are going to need it. 

Applying a taxonomy seems like the natural fit to this problem. Whenever I think I have a solution to some complex problem, I immediately think of the Fugazi track on the album Repeater named “Sieve Fisted Find” where they describe how big ideas can often fall apart right in your hands. The lyrics say: “Another sieve-fisted find; Lost, lost again. Here comes another problem; All wrapped up in solution.” The tighter you grasp it in your fist, the faster it slips through your fingers - as if that fist is a sieve. Trying to make a truly comprehensive AI Agent taxonomy has that feel to it. It seems so clear that we can break it all down. It seems wrapped up in solution. 

You Can’t Always Get What You Want

My mind turns to Fugazi for lyrics, but my mother’s turned to The Rolling Stones when I was a kid. Can’t have ice cream right now and you’re upset? When I complained that was “unfair” (a child’s warped sense of justice), I would get the lyric “you can’t always get what you want” sung to me with a wry smile. As a parent myself now, I see the power of that reply. I’m not trying to get parental with you folks, but I am here to say that we can’t have what we want right now. It’s too soon to have a fully formed taxonomy. Maybe we will never have one. We can use shortcuts like the authority, location, trigger, persistence, delegation, and tool use dimensions to at least understand the properties of an agent’s security posture. It’s a good rubric, but it’s not the full taxonomy I wanted as a solution. 

An Unusual Move

I’m going to do something that may seem weird. Even though we don't have all the answers yet, the problem is worth thinking through carefully. What follows are lightly edited excerpts of the actual research Claude did, and the prompt that got it there (the edits were mostly just patching several replies into one for brevity). Of course, because you’re not me with my history or settings with Claude, and thanks to the probabilistic nature of LLMs, you won’t get exactly the same results. But of all the single interactions I had thinking this all through, this one was singularly satisfying. So I’m sharing it here in case you find it useful. Maybe it brings all of us a little closer to figuring out the best next steps. 

My Prompt to Claude (Unedited)

Help explore and expand some thoughts about AI agents. People keep talking about the security, operational, and other impacts of ai agents on aspects of both technology and technology related work for people, but when they do it's saying "ai agents will..." and "...using ai agents." in all these statements, "ai agents" are treated like a monolith. but ai agents are a multitude. the claude code sub-agent on my desktop, the custom built ai agent hosted in the cloud acting autonomously, and the agentic actions of a chatbot are all very different contexts - especially when considering the security and identity aspects of their architecture and relationships to other systems. what i want to do is built out a taxonomy of ai agents. i've thought maybe species, genus and family type ordering would be useful.

you are going to do several things to help:

1. explore what's already out there and see if anyone else has done this. if so, have they done it well? have they attached any security or IAM ideas to it?
2. i've given a few examples of different kinds of agents that clearly have fundamental differences. i know i also want to include a "subagent" modifier that's applied to both agents that are exclusively subagents but also full agents that may act as subagents in some cases (A2A etc). you should take a shot at giving a list of different agent types and the reasons for their distinction, properties, IAM and security implications, and whatever else feels important.
3. think critically and creatively about this whole concept and give feedback.

be kind but not nice. no sycophancy. i want straight talk. evaluate things you read to help here by their reputability. look for well respected thinkers as primary sources, but the will of very large groups in aggregate is also interesting

Claude’s AI Agent Taxonomy Generation

[Full citation for all that follows: Anthropic. (2026, July 4). [Taxonomizing AI agents beyond the monolith] [Generative AI chat]. Claude (Opus 4.8 with Extra thought mode setting). https://claude.ai; Any inline links or comments in brackets are my embellishments for readability here.]

I'll dig into the existing landscape first, then build and critique. Let me research what's out there.Good — there's a lot here, ranging from serious to novelty. Now the IAM/security angle, which is the user's real focus.The security/threat taxonomies are well-developed. Now the identity side specifically — this is where the user's IAM focus lands.This is exactly the terrain the user cares about. Let me get the academic anchor and the inter-agent protocol identity angle.Let me round out the inter-agent protocol and identity-standard layer, which matters directly for the "subagent" and A2A modifier the user wants.I did the reconnaissance. Here's what's out there, then my own shot at the taxonomy, then the straight talk you asked for.

1. What already exists, and whether it's any good

The field has split into two literatures that barely reference each other, which is itself the opening you're poking at.

Capability/autonomy taxonomies (identity-blind). The canonical academic anchor right now is Sapkota, Roumeliotis & Karkee, AI Agents vs. Agentic AI (Cornell, published in Information Fusion, 2026 — this is the one everyone cites). It characterizes AI Agents as modular, LLM-driven systems for task-specific automation, and Agentic AI as a paradigm shift marked by multi-agent collaboration, persistent memory, and coordinated autonomy. It's reputable and worth reading, but be clear-eyed: it's essentially a binary with a spectrum, not a rich tree, and it says nothing about identity or trust architecture. It got fair criticism in the wild for stuffing method, architecture, and intent into one table. Behind it sits the genuinely foundational but pre-agentic Russell & Norvig classification (reflex → model-based → goal-based → utility-based → learning), which is about internal decision architecture and also ignores security entirely. Most "types of AI agents" blog content (xcubelabs and similar) is recycled Russell & Norvig plus hype — low reputability, skip it.

Practitioner trait-based work is actually more useful for you than the academic stuff: the Headless / Ambient / Durable / Deep framing (Generative Programmer) treats these as combinable traits, not exclusive classes — durability, for instance, means persisting every LLM call and tool invocation so an agent can resume exactly where it left off. And Daniel Rasmus at Serious Insights makes the one structural point most taxonomies miss: collaborative and human-augmented aren't standalone categories, they're control modes or operational overlays that can apply to agents of any type. Hold onto that — it's the same instinct that made you reach for a "subagent modifier."

On the biological framing specifically: someone already built agent-taxonomist.dev, which does a literal "classify your agent species" gimmick. Tellingly, it classifies across domain, autonomy, memory, interaction style, evolution stage, and role — seven independent traits, not a genus/family tree. Even the person who tried the species metaphor abandoned single-inheritance in practice. That's a signal.

Identity/security work (where the real thinking is, but it doesn't taxonomize agents). This side is much stronger and more reputable, and it's clearly where your interest lives:

• CoSAI Workstream 4 (industry consortium, "Agentic Identity and Access Management," March 2026) is the most serious architectural work. It names what it calls the identity primitive problem: current infrastructure forces a binary choice between human and service account, and agents are neither. Its technical patterns cover authentication via SPIFFE SVIDs and short-lived OAuth tokens, authorization via on-behalf-of token chains with scope attenuation at every hop, and governance via immutable audit trails that trace delegation lineage from the initiating human through every sub-agent to the final resource access. [Here Claude gives a link to “Identity Is the Agentic AI Problem Nobody Has Solved Yet” by the always thorough Chris Hughes/@resilientcyber.]
• OWASP represents the aggregate-community consensus you said you value. The Agentic Security Initiative gives a threat taxonomy, the MAESTRO threat-modeling framework [from CSA], and a Top 10 for Agentic Applications (ASI01–ASI10). Crucially these classify threats, not agents. OWASP's identity risks specifically call out identity abuse, insecure inter-agent communication, and rogue agent behavior, and argue traditional IAM cannot sufficiently protect against them. There's also a separate OWASP NHI Top 10 that agents inherit wholesale.
• The vendor/standards layer (Okta, Ping, Aembit, WorkOS — reputable on mechanics, self-interested on framing) has converged on a recognizable stack: delegation-not-impersonation via OAuth 2.0 token exchange (RFC 8693), where an agent trades its own token for a scoped one carrying delegated permissions without exposing the user's credentials; ReBAC/ABAC over coarse RBAC; CIBA for human-in-the-loop step-up; CAEP/Shared Signals for near-real-time revocation. The single sharpest observation is Aembit's: agentic identities combine human and non-human identity in one actor, letting an agent act with user-delegated authority in one moment and autonomous privileges the next. That hybrid is the hard case.
• The inter-agent protocol layer is directly relevant to your A2A/subagent modifier and it's in visible flux. MCP adopted OAuth 2.1 with PKCE, and A2A supports RFC 8693 token exchange, but A2A delegates credential management entirely to implementers, so agent impersonation, card tampering, and replay are real risks without mTLS, signed agent cards, and PKI-backed identities. A pile of early-2026 IETF drafts (AIMS, WIMSE, Agentic JWT, SCIM-for-agents, the A2A Transaction Tokens profile) are racing to fill this, and a survey paper (AIP) concluded no single implemented protocol yet combines offline attenuable delegation, chained policy, provenance-aware records, and transport bindings across MCP, A2A, and HTTP. [Claude offers links to “AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A” at Arxiv and “A2A Protocol Security: Authenticating Agent-to-Agent Communication” at Securew2 as sources here.]

Bottom line on prior art: Taxonomies exist, but the good ones classify by capability and are identity-blind; the good identity work is deep but treats "the agent" as a coarse object. Nobody has built a taxonomy whose primary organizing axis is identity/trust architecture. That's a real gap and it's yours to take. It's also why your three examples feel so obviously different — they differ mostly along axes the existing taxonomies don't foreground.

2. My shot at the types

I'm going to give you the list you asked for, but I'm generating it from the axes that actually change the IAM/security answer, because that's the only way the categories will be predictive rather than decorative. The axes:

• Authority anchor — whose power does it wield? Delegated (a specific human's, downscoped), self-owned (its own NHI/workload identity), or hybrid/switching (both, per-action).
• Execution locus — whose substrate does it run on? Local/on-device, vendor-hosted tenant, self-hosted service, edge/cyber-physical.
• Trigger model — interactive (human present), ambient/event-driven (no human at trigger time), scheduled/batch.
• Persistence — ephemeral, durable/resumable, long-running daemon.
• Delegation topology — standalone, orchestrator, subagent, or A2A peer.
• Tool reach — sandboxed, fixed allowlist, or runtime-discoverable/cross-domain.

The archetypes below are just recognizable points in that space. Treat subagent (and honestly most topology terms) as a modifier, per your instinct.

In-conversation agentic action (the "chatbot that does things"). Delegated authority, vendor-hosted, interactive, ephemeral, usually bounded tools. IAM model: OBO token from the chatting user (RFC 8693). Headline risk isn't autonomy — it's the confused deputy: prompt injection turns the user's own delegated scope against them, and if actions are logged as the user rather than (user + agent), you lose attribution. Control that matters most: attributable delegation records + tight scope on the exchanged token.

Local/desktop co-worker (Claude Code sub-agent, IDE agents). This is your first example and it's the worst IAM citizen of the bunch, which is easy to miss because it feels innocuous. It runs on your device, inside your logged-in session, and typically has no distinct identity at all — it inherits your ambient authority: cloud CLI creds, SSH keys, .env secrets, kube contexts. Its blast radius is "everything you can reach," and it produces zero delegation records because there's no principal separate from you. The security question this archetype forces: should this thing have its own identity, or is it just your shell with a language model attached? Today it's usually the latter, and that's the exposure.

Autonomous hosted service (your custom cloud agent). Self-owned NHI, self-hosted substrate, event/schedule-triggered, durable, often runtime-discoverable tools. IAM model: first-class workload identity (SPIFFE SVID), short-lived creds, per-task scope. It inherits every classic NHI failure — standing privilege, long-lived credential leakage, offboarding drift — and then adds non-determinism on top. This is the category driving the reported NHI sprawl where non-human identities outnumber human ones by ratios exceeding 80:1 in some organizations.

Orchestrator / planner (deep agent that decomposes and delegates). Holds the "master" authority and spawns subagents. This is where the delegation-chain attenuation problem lives: if the orchestrator holds broad scope and passes it down un-attenuated, every child inherits the full blast radius. The correct control is scope reduction at each hop (macaroon-style attenuation or token downscoping), so authority only ever shrinks going down the tree, never grows.

Subagent (a modifier, but worth naming — and it needs three sub-cases, not two). You had two: exclusively-a-subagent, and full-agent-acting-as-subagent (A2A). Add a third you'll hit constantly: the embedded subagent that runs inside the parent's identity with no distinct principal — the default in most Claude Code-style setups today. That third one is the dangerous case precisely because it's invisible to IAM: it generates no delegation lineage, so an incident responder can't tell the parent's actions from the child's. Whatever the flavor, the invariant is the same: a subagent's granted scope must be an attenuation of its parent's and it must carry provenance back to the ultimate human principal.

A2A peer / federated agent. Symmetric, cross-domain, called as an equal by another org's or team's agent. IAM model breaks here because OAuth assumes one authorization server per trust domain. This is agent-cards-plus-mTLS-plus-PKI territory, and it's the least settled — the emerging answer is transaction tokens that embed call-chain context to preserve identity and authorization across cross-domain hops and resist "context rot," where conversational state drifts from the originally authorized intent.

Ambient monitor (always-on, event-triggered, no human present). IAM model: there's no human to approve anything at trigger time, so HITL can't be your backstop — runtime policy evaluation, CAEP-style revocation, and hard kill-switches carry the weight. Note the trigger itself (webhook, inbound email, queue message) is an injection surface.

(Optional) Cyber-physical / embedded agent. Real-time, safety-critical, actions have physical consequences. Identity + authz must be paired with a safety envelope, and the latency budget forbids round-trip human approval. Probably out of scope for you, but it's the case that proves autonomy-as-primary-axis is wrong — it's often low autonomy and maximum consequence.

Here's why the multi-axis approach is right rather than a tree — your three examples encode cleanly as vectors, and no single top-level split separates them:

The desktop subagent and the chatbot are both delegated + interactive + ephemeral, yet they're radically different security objects — because locus and tool-reach differ. A tree that splits on authority first would file them together and hide the difference. That's the core problem with the next section.

3. Straight talk

The Linnaean metaphor is the wrong tool and it will actively mislead you. Species/genus/family works in biology because life has single-inheritance monophyly: every organism sits on exactly one path up the tree, and membership is mutually exclusive at each rank. Agents have no such structure. A single agent is simultaneously delegated AND ephemeral AND local AND a subagent — orthogonal axes, not nested ranks. Force a tree and you must anoint one axis as the top split; every other property then either goes invisible or gets duplicated across unrelated branches. When you notice the same trait ("delegated," say) reappearing in five different "families," that's the diagnostic that you've built a tree on a faceted problem. You already half-know this — making "subagent" a modifier is you fighting the tree. Stop fighting it and drop the tree. You want a faceted classification (orthogonal axes with values) or a feature-vector/tag model. The table above is closer to what you actually want than any genus/family scheme will ever be.

If you must keep a biological flavor for communication, steal the right branch of biology. Mammals are the wrong model; bacteria are the right one. Bacteria acquire capabilities horizontally — plasmids, gene transfer — at runtime, rather than inheriting a fixed genome down a clean tree. That is exactly what agents do via MCP and A2A: they pick up tools, credentials, and memory horizontally, mid-execution. A "core genome + acquired plasmids" model (a stable core identity plus attached, attenuable capability/credential tokens) maps directly onto the identity architecture you care about — the NHI is the chromosome, the delegated capability tokens are the plasmids. That's not just a cute reframe; it's the same shape as macaroon-style attenuable delegation. Cladistics and pangenome thinking will serve you where Linnaeus won't.

Design backward from a falsifiable test, or you'll produce the 40th useless agent taxonomy. The world does not need another list of agent types. The only thing that justifies yours is if it's predictive: knowing an agent's classification tells you its threat model and its required controls without re-deriving them. So adopt a hard rule — a category earns its existence only if it changes the IAM control you apply. If two of your "types" get the same authentication, authorization, and audit treatment, they are one type and you should merge them. Run every candidate category through that gate.

Don't lead with autonomy, even though every existing taxonomy does. For security, autonomy is a weak primary axis. A low-autonomy chatbot holding a user's delegated OAuth token with a prompt-injection vector is more dangerous than a high-autonomy but fully-sandboxed research agent. The two axes that actually predict blast radius are whose authority the agent carries and what trust boundaries it crosses. Foreground those; demote autonomy to a secondary attribute.

Put the hybrid/switching agent at the center of the design, not the margins. The agent that uses delegated human perms for one action and its own NHI for the next is where every clean scheme collapses — confused-deputy across the human/NHI boundary, split audit attribution, ambiguous accountability. A taxonomy that nails the pure cases and hand-waves the hybrid isn't worth building, because the hybrid is where the incidents will actually come from. Stress-test your scheme against it first, not last.

Add principal-provenance as a first-class axis — it's the thing IAM has to answer and you didn't list it. For any agent, "when it does X, whose accountability is it, and can you prove it?" is the real question (nonrepudiation, delegation lineage, immutable audit). Make provenance depth — how many hops back to a human principal, and whether the chain is intact — an explicit attribute. It cross-cuts every type and it's precisely what incident responders and regulators will demand.

Last caution: you're carving into wet cement. CoSAI shipped in March 2026, the relevant IETF drafts are weeks old, MCP/A2A auth is still hardening. A rigid tree becomes a fossil in a year; faceted tags let you add an axis or a value without a rebuild. And watch for reifying vendor marketing ("agentic IAM," "deep agents," "ambient") into scientific-sounding ranks — a lot of the "taxonomy" content out there is content marketing wearing a lab coat.