# Agent Authority

Source: John Bradshaw — https://bradshaw.cloud
URL: https://bradshaw.cloud/strategy/agent-authority/
Type: insight
Tags: Security, AI, AI agents

> An AI agent needs more than an API token. The framework for assigning a sponsor, mandate, permissions, autonomy and evidence before it can act.

## The authority model

An agent’s useful scope should be explicit before it reaches a system of record.

### An agent needs an authority envelope

Every production agent needs a named sponsor, a bounded mandate, scoped permissions, explicit autonomy and a record of what happened. An API token only answers one of those questions.

**Business take:** Treat the envelope as an entry condition for production. If a team cannot name the sponsor or describe the irreversible action, the agent is still a prototype.

### Autonomous, delegated and supervised are different systems

An autonomous agent acts from its own bounded permissions. A delegated agent acts for a named user and inherits only the rights needed for that task. A supervised agent prepares the work and waits for approval before a consequential action.

**Business take:** The mode determines the control. A background inventory check may run autonomously. A contract amendment should arrive as a proposal for a human to approve.

### Control identity, tools and data separately

Identity establishes who the agent is. Tool policy limits what it can call. Data policy limits what it can see. A single broad service account collapses all three controls into one opaque permission set.

**Business take:** Separate layers let security teams revoke a tool, data owners constrain a source and platform teams retire an agent without breaking every surrounding system.

### Authority must expire as deliberately as it is granted

Register the agent and its sponsor. Approve its purpose and privileges. Observe it in operation. Review authority when the task changes. Revoke credentials, tool access and retained context when the agent is retired.

**Business take:** Most identity programmes are good at issuing credentials. Agent programmes need to be equally good at proving an agent should no longer have them.

## The authority maturity ladder

Move from shared credentials to authority that can be explained, reviewed and retired.

### Agent authority

The path from a prototype to a governed production agent

- Shared credentials — Agent shares a broad application account — Unattributable risk
- Named agent account — Identity is visible but privileges remain broad — Visible, exposed
- Scoped permissions — Tool and data access match a defined task — Contained
- Bounded authority — Sponsor, mandate and approval thresholds are explicit — Governed
- Continuous review — Authority adapts, expires and remains auditable — Defensible

_Start with the narrowest authority that lets the agent demonstrate value. Expand only after evidence shows that it needs more._

## Authority decisions

### Can the agent make an irreversible change?

**Only with a defined approval threshold.**

Use a human gate for actions that move money, change contracts, delete records or create external commitments. Put the threshold in the workflow, not in a policy document.

### Does the agent act for a user?

**Use bounded delegation.**

Preserve the originating user, limit the delegated scope and expire the delegation when the task ends. Do not turn a user session into an unbounded background credential.

### Can the organisation reconstruct an action?

**Record the authority chain.**

Keep the sponsor, mandate, retrieved context, tools called, approvals and final action together. An audit log without the delegated purpose explains activity but not authority.

### Has the agent’s task changed?

**Review the envelope before extending access.**

New tools, new data domains and new actions change the authority model. Treat that as a change request, not a minor prompt update.

## Frequently asked questions

### What is agent authority?

Agent authority is the bounded right of an AI system to take action. It joins five facts: who sponsors the agent, what outcome it may pursue, what it may access, which actions can proceed autonomously and what evidence must remain after it acts.

### Why is a service account not enough for an AI agent?

A service account authenticates a workload. It does not name the human or business sponsor, describe the agent’s purpose, express its approval threshold or establish how long its authority should last. Those gaps matter when the system chooses actions at runtime.

### When should an AI agent require human approval?

Use approval when an action is irreversible, financially material, externally binding or likely to affect a person’s rights. The useful test is blast radius: if a human would want to review the consequence afterwards, give them the chance to review it beforehand.

### What evidence should an organisation retain for an agent action?

Retain the agent version, sponsor, mandate, identity, user delegation where applicable, retrieved context, tool calls, approval events, result and final action. The aim is to reconstruct both what happened and why the agent had authority to do it.

## Related

- [Agentic AI patterns](https://bradshaw.cloud/strategy/agentic-ai/) — choose the architecture before you widen the authority.
- [Model Context Protocol](https://bradshaw.cloud/strategy/mcp/) — the tool connection layer that needs a control model.
- [API security for agents](https://bradshaw.cloud/writing/api-security-when-the-caller-is-an-ai-agent/) — the security implications when software takes action.
- [AI governance in practice](https://bradshaw.cloud/writing/ai-governance-in-practice/) — who owns the guardrails.
