Definition
An autonomous agent is software that pursues a goal by deciding on and carrying out a series of actions, without a person confirming each step. Modern agents use language models to plan, call tools, read results and adjust. A person or organization typically sets the goal and the boundaries; the agent does the work in between.
In actor intelligence, an autonomous agent corresponds to the Agent class: the interaction originates from automation rather than from a person directing each action. See Human, AI-assisted or agent: a practical taxonomy for application traffic for how the classes compare.
Agents compared with other automation
- Scripts and crawlers follow fixed instructions. They are predictable and narrow.
- Autonomous agents adapt. They read what an application returns and choose what to do next, which means they may reach parts of an app that were never designed for automation.
- AI-assisted people use AI as a helper but keep control. See AI-assisted interaction.
Why autonomous agents matter to application owners
Agents increasingly act for real customers: comparing products, gathering documentation, filing tickets, syncing data and calling APIs. Many of these interactions are valuable. An application that blocks them by default may lose legitimate usage; an application that treats them exactly like people may expose sensitive actions to a participant with very different behavior.
Useful questions for any agent interaction:
- Which agent is this? Is there verifiable identity, such as an HTTP message signature (RFC 9421), or only a self-description?
- What may it do? Identity is not permission. That is an authorization question.
- Who stands behind it? A person may have delegated authority to the agent, or the agent may act for an organization. Evidence of identity does not establish delegation.
- What is the impact of this action? Reading a public catalog and changing account settings deserve different controls.
How to recognise an autonomous agent
Recognition combines evidence of different strength. A verified signature from a published operator is strong. A declared client name is useful but can be imitated. Behavioral and protocol patterns can support an inference. When none of these is sufficient, the right answer is Unknown rather than a guess.
Serving agents well
Applications that expect agent traffic often:
- Offer a structured API or machine-readable responses for common read operations.
- Apply route-level rate limits suited to automated callers.
- Require stronger credentials or explicit user approval for high-impact actions (see designing app-level policies for humans and AI agents).
- Keep human-facing pages fast and free of challenges meant for automation.
Common misconceptions
"Agents are bots, and bots are bad." Many agents are customers' tools. The goal is the right experience, not reflexive blocking.
"A verified agent can do anything its account can." Verification identifies the client. It does not authorize actions.
How Proof of Actor treats agents
Proof of Actor classifies agent interactions as Agent with an explicit basis (verified, declared or inferred), so your policies can treat a signed operator differently from a self-declared one. You decide what each route allows. See the APIs and MCP servers use cases or apply for early access.
Sources
- RFC 9421: HTTP Message Signatures: verifiable identity for automated clients
- IETF Web Bot Auth working group: standards work on authenticating bots and agents