What Is an AI Agent? Definition, Types, and Governance Requirements
An AI agent is a software system that uses a large language model to plan multi-step actions, invoke external tools or APIs, and pursue a goal with a defined degree of autonomy, distinguishing it from a single-turn chatbot that only generates text in response to a prompt. Governance requirements scale with the agent's autonomy level, tool access, and ability to affect production systems, and should be defined before deployment rather than added afterward.
Core Distinctions in Agentic Systems
Three properties separate an agent from a conventional chatbot, and each one is also where governance controls need to attach.
Multi-step planning
Agents reason across sequential steps toward a goal rather than producing a single response.
Tool invocation
Agents call external APIs, execute code, or access data sources, expanding the attack surface beyond text output.
Variable autonomy
Agents operate under human-in-the-loop, human-on-the-loop, or fully autonomous models, each requiring different oversight.
Where Governance Attaches
-
1
Where Tool Access Introduces Risk
Tool invocation is the primary mechanism by which agents move from generating text to taking action, and it is the layer where governance controls must be enforced.
Governance Requirements by Agent Type
Controls should scale with an agent's architecture and autonomy level rather than apply uniformly across every deployment.
- Single-agent, narrow tool scope: distinct identity, scoped least-privilege permissions, audit logging of tool calls.
- Orchestrator-based multi-agent: explicit boundaries on which sub-agent can invoke which tools, plus all single-agent controls.
- Peer-to-peer multi-agent (A2A or similar): inter-agent authentication, trust boundaries between agents, and security review of the interoperability protocol before adoption.
- High-autonomy agents (limited human review): human-in-the-loop checkpoints for high-impact or irreversible actions, per NIST autonomy-based control guidance.
- Any agent with persistent memory: controls against memory poisoning and periodic review of stored context influencing future decisions.
Governance Controls Mapped to Autonomy Level
Aligning controls with how much authority an agent holds
NIST's AI Risk Management Framework and its Generative AI Profile (NIST AI 600-1) both recommend mapping controls to a system's degree of autonomy rather than applying uniform requirements across all AI systems. This principle applies directly to agent governance: an agent operating under human-in-the-loop review for every action requires a different control set than one operating with standing authority to execute changes in production systems. In practice, this means governance leaders need to establish, per agent, what actions require human approval before execution, what actions can proceed autonomously within defined bounds, and what logging is required to reconstruct the agent's decision path after the fact. OWASP's LLM Top 10 identifies excessive agency, an agent granted broader permissions or autonomy than its task requires, as a specific and recurring risk pattern. Addressing it requires explicit organizational policy, not a general assumption that the underlying model will behave conservatively. Identity is a related and necessary control. Both AWS and Microsoft documentation describe scoping distinct machine identities per agent so that permissions and audit trails can be tied to a specific agent rather than a shared credential. Without distinct identity, least-privilege enforcement and incident investigation become difficult, since actions cannot be reliably attributed to the agent or sub-agent that took them.
Defining an AI Agent by Architecture, Not Marketing
An AI agent is defined by what it does with a model's output, not by how a vendor markets it. Where a chatbot produces text in response to a prompt, an agent uses that output to plan a sequence of actions, call tools or APIs, and work toward a goal across multiple steps. This architectural distinction, rather than any labeling convention, is what should determine which governance controls apply.
Categories of AI Agents and Their Risk Profiles
Agent architectures generally fall into a small number of categories, each carrying a different risk profile. Single-agent systems with a narrow tool scope present the most contained risk and require distinct identity, least-privilege permissions, and audit logging of tool calls. Orchestrator-based multi-agent systems add a coordination layer, so boundaries on which sub-agent may invoke which tools become necessary in addition to single-agent controls. Peer-to-peer multi-agent systems, including those built on protocols such as A2A, introduce inter-agent trust assumptions: a compromised or manipulated agent can influence every agent connected to it, a risk OWASP treats as distinct from ordinary tool misuse. High-autonomy agents operating with limited human review require human-in-the-loop checkpoints for high-impact or irreversible actions. Any agent with persistent memory introduces a further consideration, since stored context can be poisoned and can silently influence future decisions if not periodically reviewed.
Emerging Protocols and Their Current Limitations
Interoperability protocols such as MCP (for connecting agents to tools) and A2A (for connecting agents to other agents) are often discussed as though they were security standards. They are not. Neither has an established independent security audit history, which means adopting either requires its own authentication and data exposure review rather than an assumption of built-in safety. Excessive agency, OWASP's term for an agent granted broader permissions or autonomy than its task requires, is addressed through explicit policy on what actions an agent may take without human approval, not through reliance on model behavior alone.
Frequently Asked Questions
How is an AI agent different from a chatbot?
A chatbot generates a single text response to a prompt. An agent plans multiple steps, maintains memory across those steps, and invokes external tools or APIs to take action, meaning its outputs can directly affect systems and data rather than only producing text.
Why do multi-agent systems carry more risk than single-agent systems?
Multi-agent systems introduce inter-agent trust assumptions. If one agent is compromised or manipulated, it can influence the outputs or actions of every agent connected to it, a risk OWASP identifies as distinct from single-agent tool misuse.
Are MCP and A2A security standards?
No. They are interoperability protocols for connecting agents to tools (MCP) and to other agents (A2A). Neither has an established independent security audit history, so adopting either requires its own authentication and data exposure review.
What is excessive agency in the context of AI agents?
Excessive agency, as defined by OWASP, occurs when an agent is granted broader permissions or autonomy than its task requires. It is addressed through explicit policy on what actions an agent may take without human approval, not through model behavior alone.
Govern AI Agents at Runtime, Not Just at Design Time
Defining agent types and mapping them to governance requirements is the starting point. Enforcing identity, least-privilege permissions, and audit logging at runtime is what determines whether those controls hold once agents are operating in production.
Explore Runtime Governance