There are two types of AI agents, autonomous and delegated. An autonomous AI agent is an AI agent that acts on its own behalf, under its own identity, rather than on behalf of a person. A delegated agent is an AI agent that acts on behalf of a person, using authority that person has delegated to it. Whether a human is in the approval loop is a separate question, answered by attended or unattended, and the two axes combine into four types of AI agents.
autonomous AI agent
An autonomous AI agent is an AI agent that acts on its own behalf, under its own identity, rather than on behalf of a person. The other type of AI agent is the delegated agent, which acts on behalf of a person, using authority that person has delegated to it.
The identity question decides whose permissions the agent runs with, whose name appears in the audit log, and which event ends its access. The approval question decides whether a mistake can be caught before it takes effect or only afterward. Answer both for every agent before granting it access to anything.
Why is identity the line between agent types?
Most glossaries define an autonomous agent by its independence. It plans, decides, and acts without a person stepping in at each turn. That definition describes capability well, and it matches how the word is used in conversation, where “autonomous agent” usually means an agent nobody is watching.
Independence is a weak basis for a type, though, because it varies by task and changes with configuration. The same agent plans more freely when given a vague goal than when given a checklist. Two agents that are equally independent can also carry very different risk. One runs with a vice president’s mailbox access because that person handed it a task. The other runs with a service account the platform team created for it. Revoking the first means ending a person’s delegation, while revoking the second means disabling an identity that nobody in the directory answers for unless someone was named as its owner.
Identity answers the questions security and platform teams face for every agent: whose permissions apply, who is accountable for the outcome, and what ends the access. OAuth drew the same line long before AI agents. The OAuth 2.0 framework describes a client acting on behalf of a resource owner or on its own behalf, and OAuth token exchange separates delegation, where the actor keeps an identity distinct from the person it acts for, from impersonation. Delegated and autonomous agents map onto that existing split, so the identity systems organizations already run can represent both.
This page uses “autonomous” more narrowly than everyday usage does. The independence most people mean by the word lives on the second axis, attended or unattended, where it can be configured and checked per action.
What are autonomous AI agents?
An autonomous AI agent is an AI agent that acts on its own behalf, under its own identity, rather than on behalf of a person. It authenticates as itself, usually with a service account or workload identity, and holds permissions granted to the agent directly. Its actions are attributed to the agent, and accountability runs to the team or person who owns it.
Autonomous agents do standing work that doesn’t belong to any one person: triaging alerts as they arrive, reconciling records overnight, answering customers in the company’s name, or reviewing new records for policy violations. They outlive the people who built them, so each one needs a named owner who can say whether its purpose and access are still valid.
An autonomous agent can still wait for a person. A remediation agent that runs under its own identity and asks the on-call engineer to approve each production change is autonomous and attended. Autonomy describes whose authority the agent carries; attendance describes how closely its work is checked.
What are delegated agents?
A delegated agent is an AI agent that acts on behalf of a person, using authority that person has delegated to it. The person’s grants set the ceiling for what the agent can do, and most organizations narrow the agent further, for example by letting it read where the person could also write. Its actions are attributed to the person, with the agent recorded as the actor, which is the pairing described in agent composite identity.
A coding assistant in an editor, an agent drafting replies from a person’s inbox, and a cloud coding agent preparing a pull request for the developer who assigned the issue are all delegated agents. The first is usually a user-steered agent, where the person drives the session. The last keeps working after the person walks away and is often called a background agent.
Delegation should have an end. When the task finishes or the person leaves the organization, the agent’s access should end with it. Task-scoped credentials are the usual mechanism when the person isn’t present to keep a session open.
What do attended and unattended mean?
Attended and unattended describe whether a human is in the approval loop. An attended agent waits for a person to approve consequential steps before they take effect. An unattended agent proceeds without approval while it runs, and people review the outcome afterward.
Approval is configured per action rather than per agent. A common setup lets an agent read and draft unattended, then requires approval for anything that publishes, spends money, deletes data, or changes a shared system. Classify the agent by the actions that carry consequences. If a person approves those, the agent is attended for governance purposes.
Background and unattended are often treated as synonyms, but they answer different questions. Background describes where execution happens, and a background run can stream updates to a person who is ready to step in and approve the next step.
What are the four types of AI agents?
Identity and approval are independent, so every agent run falls into one of four combinations.
Approval →
Acts for one person with that person's delegated access, and waits for them to approve consequential steps.
Completes a task for one person with that person's delegated access, after the person stops watching.
Acts under its own identity for a team or the organization, and a person approves its consequential steps.
Acts under its own identity when a schedule, event, or queue starts a run, with no human approving steps.
Acts for one person with that person's delegated access, and waits for them to approve consequential steps.
Completes a task for one person with that person's delegated access, after the person stops watching.
Acts under its own identity for a team or the organization, and a person approves its consequential steps.
Acts under its own identity when a schedule, event, or queue starts a run, with no human approving steps.
Classify each run or action rather than the product. The same software can run attended for one task and unattended for the next, and an agent can switch identities between steps.
What is an attended delegated agent?
An attended delegated agent acts for one person, with that person’s delegated access, and waits for them to approve consequential steps. This is the copilot arrangement: a developer accepting or rejecting each proposed edit, or an analyst reviewing a query before it runs against production data. Oversight is strongest here, but the agent’s reach is as wide as whatever the person delegated, and people who approve many steps in a row start approving by reflex. Narrow the agent below the person’s own grants and keep approval for actions that are hard to undo.
What is an unattended delegated agent?
An unattended delegated agent completes a task for one person, with that person’s delegated access, after the person has stopped watching. The developer assigns an issue and comes back to a pull request, or a manager asks for a briefing and reads it the next morning. A schedule or trigger doesn’t make the agent autonomous. A weekly task that runs on one person’s delegated credentials is still delegated. The main risk is authority outliving the task, so the credential should be scoped to the task, expire, and name both the person and the agent.
What is an attended autonomous agent?
An attended autonomous agent acts under its own identity, for a team or the organization, and a person approves its consequential steps. Examples include a remediation agent that proposes a production fix for the on-call engineer to approve, and a billing agent that prepares refunds under its own service account for a support lead to sign off. The approver is often not the person who asked for the work. A requester can steer the agent’s standing access toward actions they couldn’t take themselves, so check each request against the requester’s rights as well as the agent’s role.
What is an unattended autonomous agent?
An unattended autonomous agent acts under its own identity when a schedule, event, or queue starts a run, with no human approving steps while it runs. This is what most people mean by a fully autonomous agent: a nightly reconciliation job that investigates invoice discrepancies and files tickets, or an incident agent that starts from an alert and gathers diagnostics. It has the fewest checkpoints of the four types, so a faulty decision repeats on every run until someone notices. It needs a named owner, run limits, monitoring, an escalation path, and periodic review of its access.
How do you classify an agent that uses both identities?
Many production agents switch identity partway through a run. A shared agent in a team chat channel might read a knowledge base under its own identity, then file a ticket on behalf of the employee who asked. That agent is autonomous for the read and delegated for the write, and the audit record should say so for each action.
Don’t infer identity from the channel, trigger, or product name. A shared chat agent can act with its own bot identity or with the requester’s delegated access, and a scheduled agent can keep running on its creator’s credentials. The test is which principal the downstream system authorized for the action. Record it when the action happens, because it can’t be reconstructed reliably afterward.
Subagents follow the same rule. An orchestrator acting for a person passes delegated authority to the subagents it starts, and each subagent should receive a narrower slice of that authority than the orchestrator holds.
What happens when a delegated agent runs on a shared key?
It becomes autonomous by accident. A team that pastes a shared API key or bot token into an agent’s configuration has given the agent an identity of its own, one with the combined access of everyone who needed the key and no owner in the directory. The audit log shows the key rather than the person who prompted the agent, and nothing revokes the access when that person leaves.
An agent that looks delegated in a design document can be autonomous on the wire for this reason. The fix is to decide the type on purpose and issue the matching identity: the person’s delegated authority for a delegated agent, or a dedicated, owned identity for an autonomous one.
What are the main security risks for each type of AI agent?
The identity axis decides how far a mistake can reach. The approval axis decides whether anyone sees the mistake before it lands. The same prompt injection does different damage in a reviewed draft, a delegated background task, an agent with standing service access, and a recurring job nobody watches.
Approval →
Its reach is as wide as the person's access, and repeated approvals turn into reflex.
It can exceed the task or keep the person's authority after the task ends.
A requester can steer its standing access toward actions the requester could not take directly.
A faulty decision repeats on every run, and standing access outlives the job it was granted for.
Its reach is as wide as the person's access, and repeated approvals turn into reflex.
It can exceed the task or keep the person's authority after the task ends.
A requester can steer its standing access toward actions the requester could not take directly.
A faulty decision repeats on every run, and standing access outlives the job it was granted for.
These are the primary risks for each type, not a complete list. Every agent still needs constrained tools, handling for untrusted input, output validation, logging, and an incident process. OWASP describes excessive agency as the damage that unnecessary functionality, permissions, or autonomy can enable, and each of the four types reaches it by a different route.
What does each type cost to govern?
Neither identity model is free, and neither approval mode is. The trade-offs:
- Autonomous agents add identities. Each one needs an owner, credentials that rotate, an access review, and a decommissioning plan. An organization that gives every agent its own identity takes on a service-account estate that grows with every deployment.
- Delegated agents inherit the person’s reach. They reuse the directory, so offboarding follows the person’s account, but a person’s grants are rarely scoped to what one agent needs. Without narrowing, a delegated agent can touch everything its person can.
- Attended agents trade speed for oversight. Every approval adds latency, and approvals that arrive too often get rubber-stamped, which keeps the cost and loses the oversight.
- Unattended agents move the checks out of the run. Correction has to come from scoped access, run limits, monitoring, and later review, and each of those takes work to set up and maintain.
For most new agents the cheapest defensible default is delegated and attended. Relax approval, or move the agent to an identity of its own, when the work requires it and someone is ready to own the result.
How do other agent labels map to these types?
Vendors describe agents with labels that mix product positioning, runtime mechanics, and architecture. Most of them say nothing about identity or approval on their own.
- Assistant and copilot usually describe attended delegated agents, but the label doesn’t define the agent’s permissions.
- Background, asynchronous, cloud, and long-running describe where or how execution happens. A background agent can be delegated or autonomous, and it can stream progress to a person who is still approving its steps.
- Scheduled, event-driven, and triggered usually describe unattended work. They don’t prove the agent is autonomous, because a schedule can run on one person’s delegated credentials.
- Service account, workload identity, and non-human identity describe the credentials autonomous agents typically use. Non-human identity covers how those credentials are managed.
- Human-in-the-loop describes an approval control. It is how an agent becomes attended for the actions it gates.
- Multi-agent, subagent, and orchestrator describe architecture. Each agent in the system still has an identity and an approval setting.
- Reflex, goal-based, utility-based, and learning describe how an agent chooses actions. They classify decision-making, which is independent of both identity and approval.
How does offboarding differ between autonomous and delegated agents?
Agent access goes stale when a person leaves, a task ends, an owner changes teams, or a workflow is retired. What to revoke follows the type:
- Attended delegated: End the session and remove temporary grants. Deprovisioning the person should end the agent’s access on the same directory event.
- Unattended delegated: Cancel outstanding tasks and recurring runs, then revoke the retained delegation.
- Attended autonomous: Remove the agent from the channels and queues where people reach it, and disable or reassign its identity.
- Unattended autonomous: Stop its triggers and queues, revoke its credentials, and transfer or close its ownership.
Preserve audit records and confirm that downstream systems reject the old identity. Credentials already issued can stay valid until they expire or the service checks for revocation.
A note on Speakeasy
The Speakeasy AI Control Plane governs agent identity for both types on the path agents take to tools. Delegated agents authenticate as the person through the organization’s identity provider, and unattended delegated runs receive a temporary credential tied to the person and the agent. Autonomous agents get a dedicated identity with a named owner. The Model Context Protocol (MCP) gateway checks each tool call against whichever principal applies and records it in the audit log. It governs the traffic routed through it, so agents that call systems directly still need controls of their own.
Start with the agents you already run
Pick one agent in production and answer two questions about it: does it act under its own identity or a person’s, and does a person approve its consequential actions? Record the answers in your agent inventory next to the agent’s owner and access, then move on to the next one. If you’re working out which of your agents should have an identity of their own, we’d be interested to hear how you’re approaching it. Talk to us.