We Moved Fast and Fixed Stuff: Our Revised Agentic AI Taxonomy

As we noted in our previous blog post, we’ve spent some time learning, thinking, and revising our Agentic AI taxonomy, which we’re pleased to announce here. As we did our research, we (of course) learned about dozens of different types of agentic AI security and threat frameworks. However, none of them provided what we felt was needed, which was a simple way to categorize the different types of agents, with a clearly-defined set of answers to the “what do I need to worry about?” and “how do I manage this?” questions that enterprise security practitioners are facing today. So we created our own.

At the highest level, this taxonomy makes one distinction before any other: who built the agent? We split every agent into either vendor-built or enterprise-built categories, and we use a color scheme to keep the two straight. The purple categories are vendor-built, meaning a vendor created the AI system. The salmon categories are enterprise-built, meaning your own people created the agent.

That distinction matters, because it decides who holds which controls. For vendor-built agents, the enterprise or the user configures the agent and determines what it can access, but the agent’s logic belongs to the vendor. For enterprise-built agents, users inside the enterprise author the agent’s purpose and logic, and they own responsibility for controlling it. That stays true even when a vendor hosts the runtime or supplies the builder environment.

Within those two broad groups, we have five agent types.

Provider-hosted, general-purpose agents. These are vendor-built and vendor-operated, with no access to local enterprise resources (though they may reach cloud-based resources you’ve connected). This category has three sub-types. Chat assistants like Claude, ChatGPT, and Gemini, the ones your people already use every day. Sandboxed agents, which take actions through a browser or virtual computer that runs inside the vendor’s sandbox. And workspace-embedded agents such as Claude Tag or Microsoft Teams agents, which run inside multi-user communication platforms and act under their own identity.

SaaS-embedded agents. These are vendor-built and vendor-operated agents living inside a SaaS product you already license. These could either be the Office-suite agents in Microsoft 365 and Google Workspace, along with the many Application-specific agents now showing up inside their own SaaS platforms.

Local-access agents. These are vendor-built agents deployed so that they have local access to the user’s device, potentially reaching all the software, data, and access that the user has. Copilot CLI is one example of the Code / Terminal Agent type, working through the terminal. Claude computer use is an example of the GUI / Computer-Use Agent type,  operating the desktop interface directly. Worth noting: these agents don’t usually run locally themselves; it’s their harnesses that run on the user’s device, which is how the agent reaches local resources indirectly.

Now we shift to the salmon-shaded boxes, the agents your enterprise authored.

Platform-built agents. These are created by users inside your enterprise on a vendor’s no-code or low-code agent-builder. Those users might be non-technical “citizen developers” or seasoned engineers. Copilot Studio, Power Automate, and Zapier are examples, among many others.

Custom-built agents. This type covers a wide range of technologies and architectures, and it will be a source of continued analysis (and some security angst) for us. We’ll examine these enterprise-built, enterprise-operated, and enterprise-deployed agents across three sub-types: single-agent systems running on enterprise infrastructure, single-agent systems deployed to cloud-hosted runtimes such as Amazon Bedrock or Google Vertex AI, and multi-agent systems.

With the categories in place, we need a consistent way to analyze any agent that lands in them. We use six attributes as our lens.

Data. What does the agent ingest, access, and output, and across what trust boundaries?

Identity. What principal does the agent act as? Does it operate on behalf of a user, carry its own distinct identity, or work as some hybrid of the two?

Authority. How much power does it carry, and what is it authorized to do? Does it have read-only access to a defined area, or write access that could be destructive? And a question that turns out to matter a lot: does the agent have more, less, or simply different authority than the person asking it to act?

Autonomy. How freely does the agent act? Is there a human in the loop for each action, or is the agent partially or fully autonomous?

Management. To what degree is the agent under enterprise control? Is its management informal, formal, or fully governed?

Lifecycle. How is that control maintained over time? What happens across the agent’s full span, from creation and provisioning through operation, updates, and eventual decommissioning?

There’s a lot packed into that grid. By our count we’re teed up for at least a dozen articles along this thread. (“This could be a book!” they said. “Maybe.” he replied.)

This article is already running long, so we’ll wrap it up here. Next time, we’ll put the framework to work on the first set of agents, the chat assistants. We covered these under our original taxonomy, and now we’ll revisit them through this new lens to see what the six attributes surface that we missed the first time around.

A couple of questions for you, and we’d genuinely like your answers in the comments. How well does this taxonomy line up with what you’re actually seeing in your environment? And how many of each type do you think you have right now?

Thanks for reading. We’re looking forward to digging in with the next one.

---

Want to learn more? Contact us, and we’ll schedule a free 30-minute briefing on how you can best apply these Agentic AI controls to your enterprise.