background agent
A background agent executes asynchronously or outside the foreground interaction. Background describes how work runs, not who the agent works for, whether a person remains involved, which authority it uses, or how independently it decides.
Background agents are frequently called autonomous agents, but the terms aren’t synonyms. Autonomous describes how independently an agent decides and acts. Background describes where or how execution happens. A nightly triage worker can be both. Background work can also stream progress while a person actively participates, and an unattended agent can pause at an approval gate.
The four types of AI agents classify accountability and engagement. When background work proceeds without active human participation, it is an unattended individual agent if it completes work for one person, or an unattended organization agent if it performs a standing job for the organization. The user-steered agent is typically an attended individual agent, even when it starts a background operation and streams the result.
How do common background labels map to the four types?
Workflow, product, and assistant-style labels describe triggers, architecture, or product experience. They do not define a working arrangement by themselves.
Workflow agents
A workflow agent is deployed to run a specific workflow. A schedule, queue, or event starts each run. A nightly support-triage worker is usually an unattended organization agent. A scheduled research task for one person can instead be an unattended individual agent. The trigger alone does not decide accountability or authority.
Product agents
A product agent is a product that many people use. That architecture can support different arrangements. A customer-support agent working with a customer in live chat is an attended organization agent. A vendor-hosted coding agent that prepares a pull request after its requester leaves is an unattended individual agent. Product identity does not determine the cell.
Assistant-style agents
An organization can set up an assistant-style agent for many people to use. An internal Slack assistant is an attended organization agent when employees actively participate in each exchange. If a person delegates a task and returns later for the result, that run is unattended individual. Assistant describes the experience, not accountability, engagement, or authority.
Why can the same software use different working arrangements?
Classify each run rather than assigning the software a permanent type. Cursor used to call its Cloud Agents Background Agents, and GitHub calls its Copilot coding agent an asynchronous, autonomous background agent. In both products, a person assigns a task, leaves, and later reviews a pull request. The run is unattended individual because it proceeds without active participation but remains accountable to that person.
Grok on X illustrates another combination. It has a product identity and persists between requests, but a run can be attended organization when a person actively exchanges messages with it. A coding agent launched from a terminal can be attended individual. A scheduled run can be unattended individual or unattended organization, depending on who the work is for.
The vendor’s label does not decide the working arrangement or identity strategy. Accountability asks who the work is for. Engagement asks whether a person actively participates. Authority separately asks whether each action uses delegated-user, service/workload, or hybrid authority.
What identity do background agents need?
Identity follows the authority for the action, not whether execution happens in the background. An unattended individual agent can retain one person’s delegated authority through a task-scoped credential. An unattended organization agent usually acts through a dedicated service or workload identity. Running either on the deployer’s standing credentials or an undifferentiated shared bot credential creates the failures catalogued in non-human identity. Agent identity explains what is bound, and agent auth explains how the agent proves that binding on each request.
A dedicated identity with a fixed grant
Organization agents using service or workload authority require a dedicated account in the directory, assigned to a specific person and granted credentials tailored to the agent’s job, just like any other role would be approved. This applies to attended and unattended organization agents. The grant remains the same each time the agent runs. These three controls, which a user session automatically receives, must be incorporated into the system.
- Attribution. Every action resolves to the agent’s own name, and through the owner of record to an accountable person, without being mistaken for that person’s own activity.
- Least privilege. The grant covers the workflow the agent was deployed for, not the union of everything its deployer can reach.
- Lifecycle. The agent does not stop when anyone leaves, so offboarding is an explicit event where the identity is reassigned to a new owner or revoked.
Just-in-time credentials per task
Unattended individual agents operate without direct participation from the person who delegated the work. If a standing grant is broad enough to cover everyone who might make a request, it turns the agent into a confused deputy, allowing whoever triggers the grant to access the agent’s full range of permissions. Keeping standing keys for each person who asks is worse. A task-scoped credential lets the agent keep a basic identity without blanket access to anyone’s data. Each request creates a short-lived credential that identifies the requesting person as the subject, the agent as the actor, and only the scope required by the task. When the task is done, the credential stops working. If someone loses access, they cannot request new credentials. Extending IAM to agents covers the same authority question for a custom workflow built by one person and triggered by another.
When a vendor hosts product agents, that adds another boundary. The organization can’t control Cursor’s virtual machines or GitHub’s runners. Therefore, the only identity it can manage is the one the agent shows when it accesses the organization’s tools and data. That identity is the one to bind, scope, and revoke.
How should CISOs inventory background agents?
Background agents belong in the agent inventory, with fields matched to their type.
What should a background agent inventory record include?
An unattended organization agent’s record should include:
- The identity it uses.
- The person or team responsible for it.
- The workflow it was set up for.
- The tools, data, and MCP servers it can access.
- Its trigger, such as a schedule, queue, or event.
- The last time it was active.
- The steps required to remove it.
An unattended individual agent’s record also retains the requester, task boundary, delegated scope, and expiry. An assistant-style agent also tracks who can interact with it and the limits on what those requests can do.
Discovery works differently than it does for the user-steered population. Endpoint and MDM tools can see Claude Desktop on a managed laptop, but they miss the worker that runs overnight in a virtual machine. Instead, background agents show up when you go to find tools.
- MCP gateway traffic from clients that are not desktops or IDEs
- Service identities in the identity provider with no matching human sign-in pattern
- Standing automations and scheduled jobs in orchestration platforms
- Bots that act on a schedule with no corresponding human session
Each finding lands in the register as a record with an owner and a disposition, the same place that holds findings from shadow AI discovery. An unauthorized background agent is still a principal that can access things, so it must be managed or removed from the record.
How does the Speakeasy AI Control Plane govern background agents?
The Speakeasy AI Control Plane supports both authority strategies on the path background agents take to tools. Organization agents using service or workload authority get a dedicated identity with a named human owner. Individual agents using delegated-user authority receive a temporary credential for each request, tied to the person and agent and deleted when the task finishes. Hybrid runs record the principal used for each action. The MCP gateway is the chokepoint between agents and the tools an organization exposes.
This traffic keeps the inventory up to date. Every worker that accesses a tool through the gateway is logged as being used, showing a live “last-seen” time and audit logs that the security team can download. When you remove someone’s access, the process depends on what is being taken away. Switching ownership or canceling a unique identity is handled through the directory, while cutting off a person’s account altogether stops their temporary credentials from being issued for any assistant they have used. To put an identity, an owner, and a revocation path behind the background agents already running in your organization, talk to us.