Most "types of AI agents" guides are written for the people building them. This one is written for the people who have to answer for what those agents do once they're running.
That distinction matters more than it sounds like it should. An engineering team classifies agents by what they're capable of - reasoning, planning, tool use, autonomy level. A security team has to classify the same agents by a completely different question: what can go wrong, and how would we know?
Same seven architectures. Two entirely different lenses. This guide uses the second one.
Why is " AI agent " too broad a term to govern
Ask five people in your organization to define "AI agent," and you'll get five different answers - a Slack bot, a Copilot extension, an internal RAG chatbot, a fully autonomous workflow that touches Salesforce, ServiceNow, and your data warehouse without asking permission first. All five get called an "agent." None of them carries the same risk.
That ambiguity is exactly why most enterprise AI risk programs stall. You can't write one policy for "AI agents" any more than you could write one access policy for "employees" that covers an intern and a database administrator. The fix isn't a better definition of "agent" - it's a classification system built around what actually determines risk: autonomy, system reach, and permission inheritance.
AI agents vs. chatbots vs. NHIs: the governance gap
Before the seven types, it's worth being precise about three terms that get flattened into one in most boardroom conversations.
Chatbots are reactive. A user asks, the system answers, and the interaction ends. The blast radius of a chatbot mistake is usually a bad answer - embarrassing, sometimes costly, rarely catastrophic.
Non-human identities (NHIs) are the service accounts, API keys, and machine credentials that have quietly run enterprise infrastructure for two decades. NHI governance is mature: rotate the keys, scope the permissions, monitor the calls.
Enterprise AI agents are neither. They inherit a human's permissions, such as an NHI, but they reason, plan, and act like a person - at machine speed, across systems, without a human confirming each step. This is the identity your existing stack was never built to see: IAM governs humans. NHI governs machines. Nothing governs the hybrid identity in between.
That gap is why agent governance needs its own category, not a bolt-on to identity tooling that was designed for a different problem.
The 7 types of AI agents - and the risk profile of each
The architectural categories below are well-established in the AI engineering literature. What's missing from most breakdowns is the second column: what each type actually exposes you to, and what control closes the gap.
1. Rule-Based Agents
What they do: Execute predefined if-then logic against trigger conditions. The oldest and simplest agent architecture, still the backbone of a huge share of enterprise automation.
Risk profile: Rule-based agents feel safe because their logic is legible. The actual risk is permission scope, not decision-making: these agents are frequently provisioned once, granted broad access "to be safe," and never revisited. Predictable logic does not mean predictable access.
What closes the gap: Least-privilege scoping applied at provisioning, re-validated on a schedule, not a one-time review.
2. Conversational Agents
What they do: Process natural language, interpret intent, and generate contextual responses, customer service, internal knowledge assistants, technical support.
Risk profile: This is the most exposed surface for prompt injection, data leakage through generated responses, and jailbreak attempts. Conversational agents are also the most likely on-ramp for shadow AI agents - deployed by a business team without security's knowledge.
What closes the gap: Prompt and output inspection at runtime, plus discovery tooling that finds agents deployed outside IT's visibility in the first place.
3. Predictive Agents
What they do: Analyze patterns and forecast outcomes - demand planning, churn prediction, maintenance scheduling.
Risk profile: Predictive agents require broad, often sensitive, historical data access to function well. The risk isn't usually the prediction itself; it's the width of the data pipeline feeding it, and whether that pipeline is scoped to what the task needs or to what was easiest to connect.
What closes the gap: Data minimization - the agent receives only task-required data, with sensitive fields masked before they ever reach the model.
4. Collaborative Agents
What they do: Work alongside human employees, surfacing information and recommendations inside an existing workflow rather than replacing it.
Risk profile: Collaborative agents almost always inherit the full permission set of the human they're assisting - not the narrower set the specific task requires. This is the most common source of over-permissioned credentials in agent deployments today.
What closes the gap: A scoped role per task, applied automatically, independent of what the human owner happens to have access to.
5. Adaptive (Learning) Agents
What they do: Improve their own performance over time by learning from outcomes and feedback, without explicit reprogramming.
Risk profile: This is the category classic security controls handle the worst. An adaptive agent's behavior today is not a reliable predictor of its behavior in three months — it drifts, sometimes toward genuinely better performance, sometimes away from the intent it was originally built to serve. A one-time approval doesn't hold for a system designed to keep changing.
What closes the gap: Continuous behavioral baselining, session-level, trend-level, and chain-level drift detection that flags divergence from original intent as it happens, not at the next audit cycle.
6. RPA Agents with AI
What they do: Combine traditional robotic process automation with AI-driven perception and decision-making, orchestrating multi-step actions across enterprise systems.
Risk profile: Reach. These agents are built specifically to touch many systems in a single workflow - which means a single compromised or malfunctioning RPA agent has the widest blast radius of any category on this list. Cross-system authorization is the entire risk surface.
What closes the gap: Cross-chain authorization integrity, scope can only decrease across each delegation hop, and every downstream action stays traceable to the original human authorization that kicked off the chain.
7. Cognitive (Autonomous) Agents
What they do: The most sophisticated tier - reasoning, multimodal understanding, and independent judgment across complex, unstructured scenarios.
Risk profile: Maximum autonomy, minimum predictability. Cognitive agents are explicitly designed to determine their own next step rather than follow a fixed path, which is precisely why a fixed, point-in-time policy is insufficient to govern them.
What closes the gap: Runtime intent governance - not "did we approve this agent," but "is this agent, right now, still doing what it was approved to do."
Mapping agent type to governance control
The seven types above aren't equally likely to appear in a given part of the business, and they don't all require the same controls or the same urgency. The table below maps each type to where it tends to surface and which control matters most.
If that Discovery → Identity → Least Privilege → Guardrails → Detect → Respond → Audit sequence looks familiar, it should - it's the same order these controls need to go in regardless of which agent type you're governing. The type tells you where to look first. The sequence tells you what to build.
Three principles for governing a mixed agent estate
Most enterprises aren't running one type of agent. They're running all seven, deployed by different teams, at different maturity levels, often without a central inventory of which is which.
Three things matter more than the taxonomy itself:
- Classify before you write policy. A single "AI agent policy" applied uniformly across all seven types either over-restricts the low-risk ones or under-controls the high-risk ones. Classification has to come first.
- Govern the runtime, not just the provisioning. Every type above can pass a point-in-time review and still drift, get exploited, or exceed its intended scope in production. Approval at deployment tells you what was intended. Only runtime observation tells you what's actually happening.
- Assume the inventory is incomplete. If discovery isn't continuous, the riskiest agents in your environment are very likely the ones nobody signed off on in the first place.
FAQ
What is agent sprawl? Agent sprawl is the uncontrolled proliferation of AI agents across an organization - built by individual employees or teams, often without security or IT approval - to the point where no single team has a complete inventory of what's running, what it can access, or who owns it.
What's the difference between an NHI and an AI agent identity? An NHI (non-human identity) is a static machine credential - a service account or API key with a fixed, narrow function. An AI agent identity is dynamic: it reasons, plans, and acts across systems, often inheriting a human's permissions rather than holding its own narrowly scoped credentials. NHI governance tools weren't built to observe behavior or intent; they were built to rotate keys and monitor calls.
Do chatbots need the same governance as autonomous agents? No, but they need governance, not none. A chatbot's risk is largely contained to what it says and the data it exposes in its responses. An autonomous agent's risk extends to every system it can act on. Both need discovery and identity controls; autonomous agents additionally need guardrails, drift detection, and containment capability because they can act, not just answer.
What's the biggest governance gap for enterprise AI agents specifically? Runtime visibility. Most organizations can describe what an agent was approved to do. Very few can answer whether it's still doing that today. Provisioning-time approval is a snapshot; agent behavior is a stream, and a snapshot can't govern a stream.
Is BYOA (Bring Your Own Agents) really worse than BYOD? In most enterprise environments, yes. BYOD introduced an unmanaged device. BYOA introduces an unmanaged identity with access to tools, credentials, and the ability to take action across connected systems, a materially larger surface area than a single unmanaged laptop.
Enterprise AI agents don't fit neatly into IAM or NHI governance because they were never designed to. aizome is where discovery, identity, least privilege, guardrails, detection, response, and audit come together for every agent type running in your environment - including the ones nobody's approved yet.
Come see it in action at aizome.ai.
