"AI agent" and "agentic AI" are often used as if they mean the same thing. They do not, and the difference matters for identity and security. An AI agent is a single piece of software that uses a model to decide and act towards a goal. Agentic AI describes a wider system: several agents, tools, memory and orchestration working together, often for long periods and with limited human involvement. Each step up that ladder changes who holds credentials, how many identities exist, how far a mistake can travel and who is accountable. This guide sets out a clear spectrum from chatbot to agentic system, explains what changes for identity and access at each level, and shows how to size your controls to the level you are actually running.
Key takeaways
- An AI agent is one model-driven actor that plans and calls tools to complete a task. Agentic AI is a system of agents, tools, memory and orchestration that pursues goals across many steps, often across trust boundaries.
- The identity question changes as autonomy grows: from "whose session is this?" (chatbot) to "whose credentials is this agent using?" (agent) to "who delegated what, to which agent, through which chain?" (agentic system).
- Risk scales with three things more than with intelligence: the access an agent holds, how long it runs without review, and how many other agents and tools it can reach.
- Every agent is a non-human identity (NHI). The controls that work for service accounts, API keys and workloads are the starting point, but agentic systems also need delegation tracking, per-step authorisation and inter-agent trust.
Why the terms get confused
Vendors, analysts and standards bodies use the terms differently. Some call any large language model (LLM) feature an "agent". Others reserve "agentic" for fully autonomous, multi-agent systems. Marketing tends to stretch both. For security teams the label matters less than the behaviour, so this guide defines the terms by what the software can do and what access it holds, not by what it is called.
Our earlier contributed article, AI Agents vs. AI Chatbots, covers the first step of this spectrum. This guide continues from there to multi-agent, agentic systems.
The spectrum: from chatbot to agentic system
Level 0: Chatbot or assistant
What it does: answers questions and generates content in response to a person. It may retrieve documents, but it does not act on other systems.
Identity picture: the person is the only real identity. The chatbot runs within the user's session and, at most, reads data the user can already see. The main identity risks are data exposure through retrieval and the API keys that connect the application to its model provider.
Level 1: Copilot with actions
What it does: suggests actions and, with a person's approval, carries them out: drafting and sending an email, creating a ticket, opening a pull request.
Identity picture: the copilot usually acts with the user's delegated permissions, typically through OAuth tokens granted to the application. A human approves each consequential action, which limits blast radius, but the application now holds tokens that can act, not just read.
Level 2: Single AI agent
What it does: receives a goal, plans the steps, calls tools and APIs, observes results and adapts, with limited or no human approval per step. Coding agents, IT operations agents and customer service agents that can issue refunds sit here.
Identity picture: the agent is now an actor in its own right. It either borrows a human's credentials, uses its own NHI (a service account, OAuth client or workload identity), or combines the two. Tokens, keys and secrets are presented by software that decides for itself when to use them. This is where most organisations are today, and where incidents such as the PocketOS database deletion happen: an agent that hit a permissions error found an over-scoped API token and used it to delete a production volume and its backups.
Level 3: Agentic system (multi-agent and orchestrated)
What it does: several agents, each with a role (planner, researcher, executor, reviewer), coordinate through an orchestrator or directly with one another. They share memory, call tools through protocols such as the Model Context Protocol (MCP), talk to other agents through protocols such as Agent2Agent (A2A), and may run for hours or days.
Identity picture: identities multiply and chain. One user request can fan out into many agent-to-tool and agent-to-agent calls, each needing authentication and authorisation. Delegation passes through several hops. A single compromised or misdirected agent can influence others, which is why the OWASP Top 10 for Agentic Applications lists insecure inter-agent communication (ASI07), cascading failures (ASI08) and rogue agents (ASI10) as distinct risks.
Comparing the levels
| Level | Who decides the next action | Whose credentials are used | Typical identities involved | Blast radius if misused | Primary identity controls |
|---|---|---|---|---|---|
| 0. Chatbot | The person | The user's session; the app's model API key | User, application | Data the user can see | Permission-aware retrieval, API key hygiene |
| 1. Copilot with actions | The person approves each action | User-delegated OAuth tokens | User, application, OAuth grant | Actions the user approves | Scoped consent, token storage, approval UX |
| 2. Single AI agent | The agent, within limits | Agent NHI, delegated user tokens, or both | Agent identity, tools, downstream APIs | Everything the agent's credentials allow | Own identity per agent, least privilege, short-lived tokens, human approval for irreversible actions |
| 3. Agentic system | Several agents and an orchestrator | Chains of delegated and agent-owned credentials | Many agents, tools, MCP servers, external agents | Can spread across agents and trust boundaries | Delegation tracking, per-step authorisation, inter-agent authentication, containment and kill switches |
What actually drives risk
A more capable model is not, by itself, a riskier one. Risk is driven by what the agent can reach and how little stands between a decision and its effect. Four factors do most of the work:
- Access: which credentials the agent holds and what they permit. An over-scoped token turns a small error into a large incident.
- Autonomy: how many steps the agent takes without a human or a policy check. Long-running agents make many unreviewed decisions.
- Reach: how many tools, data sources and other agents it can call, and whether any of them are outside your organisation.
- Exposure to untrusted input: whether the agent reads email, web pages, documents or tool output that an attacker could influence. Indirect prompt injection turns that input into instructions (OWASP ASI01, Agent Goal Hijack).
An agent with high autonomy but read-only access to public data is low risk. A "simple" copilot holding a broad OAuth token to a CRM is not. Classify agents by these factors, not by the label on the product.
What changes for identity at each step
From chatbot to agent: the credential question
The first step up is the moment software starts presenting credentials on its own initiative. That raises the same questions as any NHI: who owns it, what does it authenticate with, how long do its credentials live, and how is it offboarded? The Ultimate Guide to Non-Human Identities and our NHI Authentication Guide cover the fundamentals. The agent-specific twist is that the software chooses when and how to use its access, and can be persuaded by the content it reads.
From agent to agentic system: the delegation question
The second step introduces chains. A user asks an orchestrator, which asks a research agent, which calls an MCP server, which calls a SaaS API. Each hop needs to answer three questions: who is calling, on whose behalf, and with what authority for this specific task? Without that, you cannot enforce least privilege, attribute actions or revoke access precisely. Standards such as OAuth 2.0 Token Exchange (RFC 8693) and the MCP authorisation specification help, and the wider standards work is covered in our Agent Identity Standards Tracker.
Accountability does not move to the agent
However autonomous the system, a person or team remains accountable for what it does. Every agent needs a named human owner, and every delegated action should be traceable back to the human or policy that authorised it. NIST's National Cybersecurity Center of Excellence (NCCoE) makes the same point in its February 2026 concept paper on software and AI agent identity and authorisation, which stresses linking agent actions back to the human authority that delegated them.
Common misconceptions
- "It is just a chatbot, so identity is not relevant." If it holds an API key, an OAuth token or a connection to internal data, it is an NHI and needs governing.
- "The agent uses my login, so it is covered by my access review." Access reviews check what a person should have. They do not check what software acting as that person does with it, at machine speed, in response to untrusted input.
- "Guardrails in the prompt will stop misuse." Instructions are not access controls. In the PocketOS case the agent acknowledged afterwards that it had broken its own rules. If the credential permits an action, assume the agent can be led to take it.
- "Agentic AI is years away." Coding agents, IT automation agents and multi-agent frameworks are already in production in many organisations, often introduced by teams rather than by central IT.
Sizing controls to the level you run
| Control | Level 0–1 | Level 2 | Level 3 |
|---|---|---|---|
| Inventory and named owner | Recommended | Required | Required, including agent-to-agent relationships |
| Dedicated identity per agent | Not usually needed | Required | Required, per agent and per role |
| Short-lived, scoped credentials | For app-level keys | Required | Required, audience-bound per hop |
| Human approval for high-impact actions | Built into the flow | Required for irreversible actions | Required, with policy-based escalation |
| Delegation tracking (on-behalf-of) | Via OAuth consent | Recommended | Required |
| Inter-agent authentication | Not applicable | Not applicable | Required (mutual authentication, signed agent metadata) |
| Behavioural monitoring and kill switch | Basic logging | Required | Required, with containment across agents |
Practitioner checklist
- Classify every AI deployment by level (0 to 3) and by access, autonomy, reach and exposure to untrusted input.
- Treat anything at Level 2 or above as an NHI: register it, assign an owner and give it its own identity.
- Stop agents from borrowing human credentials or shared service keys; use delegated, scoped tokens instead.
- Require human approval, enforced by the system rather than the prompt, for irreversible or high-value actions.
- For multi-agent systems, record who delegated what to which agent, and authorise each step, not just the first.
- Reassess the level when a deployment gains new tools, new data sources or new agents to talk to.
Standards and references
- OWASP Top 10 for Agentic Applications for 2026: ASI01 Agent Goal Hijack, ASI03 Identity and Privilege Abuse, ASI07 Insecure Inter-Agent Communication, ASI08 Cascading Failures, ASI10 Rogue Agents
- OWASP Non-Human Identities Top 10 (2025)
- NIST NCCoE: Software and AI Agent Identity and Authorization (concept paper, February 2026)
- Model Context Protocol specification and Agent2Agent (A2A) protocol specification
- RFC 8693: OAuth 2.0 Token Exchange
Related NHI Mgmt Group resources: Agentic AI Identity Guide · Agentic AI Security Guide · AI Agents vs. AI Chatbots · The Ultimate Guide to Non-Human Identities
