# Agentic API Security

Source: John Bradshaw — https://bradshaw.cloud
URL: https://bradshaw.cloud/strategy/agentic-api-security/
Type: insight
Date: 2026-08-16
Tags: Security, API security, Zero Trust, AI agents

> The caller is no longer a person. The identity, task-scoping, reversibility gates, and observability an API estate needs once autonomous agents hold the credentials.

## The threat model and the four controls

### The caller is no longer a person

Classic API security answers one question well: is this caller who they say they are? Authenticate the user, check the token, log the session — the whole edifice assumes a known identity with predictable behaviour on the other end. An agent breaks the assumption without breaking the rules: it authenticates perfectly, then calls your API in whatever sequence, at whatever volume, in whatever combination gets it closer to its goal. The question becomes four: who is this, what is it trying to do, what is it allowed to touch, and how much damage can it cause when it's wrong or compromised.

**Business take:** The thing calling your API at 3am isn't a user and isn't your code — it's an autonomous system holding a valid credential, making its own decisions about what to do next. APIs were already the front door attackers try first: machine-readable, data-rich, and more numerous than most organisations can name. Agentic AI doesn't create that problem — it pours accelerant on it. Identity is the one question most estates have solved; intent, scope, and blast radius are where the work is now.

**Diagram notes:**

- **Yesterday's question** — Not wrong, just no longer sufficient. Every control built on it — session logging, per-user rate limits, behavioural baselines — quietly assumes the authenticated party is also the deciding party. An agent is the first caller for which that stops being true.
- **Identity** — The question most estates have already answered, and the reason this is easy to miss: an agent passes authentication perfectly, because it holds a credential somebody legitimately issued. Nothing about the handshake looks wrong. Authentication was never going to be the control that caught this.
- **Intent** — A person's next request is roughly predictable from their last one. An agent's next request is whatever its planner decided gets it closer to the goal — which means "is this call normal for this caller?" needs a baseline built from agent runs, not from user sessions.
- **Scope** — Not "what is this identity entitled to?" but "what does this task need, for as long as it runs?" The gap between those two questions is standing access, and standing access is the multiplier on every other risk on this page.
- **Blast radius** — The question you answer in advance or during an incident, and it is a very different exercise on the day. Ask it as a single number: if one agent token leaked tonight, what is the worst it could do before anyone noticed?

### An agent wears its own identity, never a borrowed one

The first failure mode is an assistant wired to act "as the user", inheriting everything that person can do. That puts the full standing access of a senior employee behind an autonomous system — and an audit log that says a human did it. Agents need machine identities of their own: issued, scoped, and revocable independently of any person, with short-lived tokens and no standing access beyond the task in front of them. Zero-trust principles were written for exactly this caller: never trust by network position, verify every call, assume the credential will eventually leak.

**Business take:** Treat an agent identity the way you'd treat a microservice you don't fully trust. The practical test: if this agent's credential leaked tomorrow, what is the worst a single stolen token could do? If the honest answer is "anything the user could", the agent has too much — and you'll discover it in the post-incident review, attributed to the wrong actor.

**Diagram notes:**

- **Agent, acting "as the user"** — The default in most assistant integrations, because it is the path of least resistance: the agent already has the session, so it just uses it. Nothing is misconfigured. The design is the problem.
- **Full standing access** — Two failures for the price of one. The agent inherits everything the person can reach rather than what the task needs — and the audit trail names the person, so the first thing an investigation does is question an employee about calls they never made.
- **Agent, with its own identity** — Issued to the agent, not borrowed from a human, and revocable without disabling anybody's account. That independence is the whole point: containment should never require taking a person offline to stop a process.
- **Verify every call** — Never trust by network position, verify every call, assume the credential eventually leaks — zero trust, written years before this caller existed and describing it exactly. The enforcement point is a place calls already pass through, so the policy lives somewhere it can actually be changed.
- **Short-lived, narrow, revocable** — Three properties that compound: a short life caps how long a leaked token is worth stealing, a narrow scope caps what it reaches while it lives, and revocability caps the incident once you know. Any one alone leaves an obvious hole.

### Scope to the task, not the role

Human access is role-shaped — you're in finance, so you can see finance things. That's blunt for people and actively dangerous for agents, because an agent doesn't need standing access at all: it needs just-in-time access to do one thing, then nothing. The pattern that works is narrow, ephemeral, and task-bound. A refunds agent gets a credential that reads order history and issues refunds below a threshold — and that is the entire universe it can touch. When the task ends, the scope ends.

**Business take:** Rate limits stop being a noisy-neighbour nicety here and become a real control. A human hitting an endpoint a few times a minute is normal; an agent doing it ten thousand times is either working hard or running away with itself — and you want a ceiling that catches the second case before it empties a table or runs up a bill. Per-agent quotas, per-endpoint limits, and circuit breakers on anything expensive or destructive.

**Diagram notes:**

- **Role scope** — Built for humans, and defensible for them: a person's job is stable, so their access can be too. An agent's "job" changes with every task it picks up, so a role is always the union of everything it might ever need — permanently granted.
- **Task scope** — The credential is minted for one job and expires with it. "Nothing else exists" is literal — the agent should not be able to enumerate the endpoints it was not given, because discovery is the first half of most incidents.
- **Per-agent quota** — Set from what the task actually needs plus headroom, not from what the platform can survive. A ceiling tuned to infrastructure capacity is one a runaway agent will happily sit just underneath for hours.
- **The runaway curve** — Rarely an attack. Far more often a retry loop, a mis-specified goal, or a pagination bug — an agent doing exactly what it was told, faster than anyone expected. That is why the ceiling has to be automatic: nobody is watching the graph at 3am.

### A human stands between the agent and anything irreversible

Sort actions by reversibility, not by how much the team wants to automate them. Reading data, drafting a message, flagging a record for review — reversible, low blast radius, let the agent run. Issuing a payment, deleting customer data, changing a permission, sending something that can't be unsent — irreversible, so it routes through a human checkpoint. The agent does the work right up to the gate, presents what it's about to do, and waits for a yes. The boundary is explicit and it lives in the system, not in a policy document nobody reads.

**Business take:** Teams want to skip this control because it feels like it defeats the point of automation. It doesn't — it draws a line. Start with the gate set tight, watch how the agent actually behaves, and widen the autonomous lane only as measured performance earns it. Designing for full autonomy on day one isn't bold; it's how you find out the hard way that an agent will confidently do the wrong thing at scale.

**Diagram notes:**

- **Reversible actions** — The lane where autonomy pays for itself, and where most of the useful work lives. Reversible does not mean harmless — a wrongly flagged record still costs someone time — it means a mistake can be undone without an apology to a customer.
- **The reversibility line** — Drawn on the axis of "can this be undone?", not "how much do we want to automate it?" — those two orderings disagree constantly, and the second one is how gates end up in front of the cheap actions and nowhere near the expensive ones.
- **Irreversible actions** — The test is whether an apology is required to undo it. Payments, deletions, permission changes and anything that leaves the building all fail it — and so, quietly, does anything that triggers a downstream system you do not control.
- **The human gate** — Cheap only if the agent does all the work first and the human is approving a finished, legible proposal. A gate that asks someone to reconstruct what the agent intended is a gate they will rubber-stamp within a fortnight.

### You can't secure what you can't see

When an agent makes a hundred calls to complete one task, security depends on being able to reconstruct exactly what it did, in what order, with what data, and why. That means logging at the granularity of the agent's decisions, not just the HTTP requests — which agent, which task, which credential, what it asked for, what it got back, what it did next — tied together so a single run reads as one coherent trace rather than scattered log lines reassembled during an incident at the worst possible time.

**Business take:** Anomalous agent behaviour looks nothing like anomalous human behaviour, so monitoring needs baselines for both. And when something goes wrong — with autonomous systems acting at machine speed, it eventually will — the difference between a contained incident and a catastrophe is whether "what exactly did it touch?" takes minutes to answer or days.

**Diagram notes:**

- **One task** — The unit that matters, and the one most logging pipelines have no concept of. Without a task identifier stamped on every call, a run is only reconstructable by timestamp — which stops working the moment two agents are busy at once.
- **Many calls** — Each one individually unremarkable: valid credential, permitted endpoint, sensible payload. The signal is in the sequence — the order, the rate, and the combination — none of which survives logging each request in isolation.
- **One coherent trace** — Log at the granularity of the agent's decisions, not just the HTTP calls: what it asked for, what came back, what it did next. The decision is the part that explains the behaviour, and it is the part a request log never captures.

## Decision framework

### Is any agent wearing a human's credentials?

**Yes → give it a machine identity first. Everything else stands on that.**

An agent acting "as the user" holds the full standing access of a senior employee, and the audit log says a person did it. Issue agent identities that are scoped and revocable independently of any human — short-lived tokens, no standing access. The test: if this credential leaked tomorrow, what is the worst a single stolen token could do?

### Does the agent's access outlive its task?

**Yes → move to just-in-time, task-bound scopes. Standing access is the multiplier on every other risk.**

Role-shaped access is blunt for humans and dangerous for agents. A refunds agent gets a credential that reads order history and issues refunds below a threshold — nothing else. When the task ends, the scope ends. Add per-agent quotas and circuit breakers on anything expensive or destructive; a runaway agent should hit a ceiling, not a table.

### Can the agent do anything irreversible on its own?

**Yes → sort actions by reversibility and put a human gate on the irreversible ones.**

Reading, drafting, flagging — let it run. Payments, deletions, permission changes, anything that can't be unsent — the agent presents what it's about to do and waits for a yes. The boundary lives in the system, not a policy document. Start tight and widen the autonomous lane as measured performance earns it.

### Could you reconstruct what an agent did last night?

**No → instrument the runs before adding more agents. You can't secure what you can't see.**

Log at the granularity of the agent's decisions, not just the HTTP requests: which agent, which task, which credential, what it asked for, what it got back, what it did next — tied into one coherent trace per run. Agent anomalies look nothing like human anomalies, so build baselines for both.

## Frequently asked questions

### How does agentic AI change API security?

It breaks the assumption the whole edifice rests on: a known identity with predictable behaviour on the other end of the call. An agent authenticates perfectly — it holds a valid credential — but it is a goal-seeking system that will call your APIs in whatever sequence, at whatever volume, in whatever combination gets it closer to its objective. So the question shifts from "is this caller who they say they are?" to four: identity, intent, scope, and blast radius. Most estates have solved the first; the other three are where the work is now.

### Should an AI agent act with its user's credentials?

No. An agent wearing a human's credentials is an autonomous system with the full standing access of that person — and an audit log that says the person did it. Agents need machine identities of their own: issued, scoped, and revocable independently of any human, with short-lived tokens and no standing access beyond the task in front of them. Treat an agent identity the way you would treat a microservice you don't fully trust, because zero-trust principles were written for exactly this caller.

### What does scoping an agent's access actually look like?

Narrow, ephemeral, and task-bound rather than role-shaped. An agent processing refunds gets a credential that can read order history and issue refunds below a threshold — and that is the entire universe it can touch. It cannot read payroll, delete records, or reach endpoints that were never part of the job, and when the task ends the scope ends. Rate limits become a real control at the same time: per-agent quotas, per-endpoint limits, and circuit breakers catch a runaway agent before it empties a table or runs up a bill.

### Which agent actions should require human approval?

Sort actions by reversibility. Reading data, drafting a message, flagging a record for review — reversible, low blast radius, let the agent run. Issuing a payment, deleting customer data, changing a permission, sending something that cannot be unsent — irreversible, so it routes through a human checkpoint: the agent does the work up to the gate, presents what it is about to do, and waits for a yes. The boundary has to live in the system rather than a policy document, and it starts tight — widen the autonomous lane only as measured performance earns it.

### What should we log when agents call our APIs?

The agent's decisions, not just the HTTP requests. Which agent, which task, which credential, what it asked for, what it got back, what it did next — tied together so a single agent run reads as one coherent trace rather than scattered log lines reassembled mid-incident. This feeds detection, because anomalous agent behaviour looks nothing like anomalous human behaviour, and it decides the aftermath: the difference between a contained incident and a catastrophe is whether "what exactly did it touch?" takes minutes to answer or days.

### Where should we start with an existing API estate?

With the irreversible actions — payments, deletions, anything that touches a customer. Put explicit gates and per-agent scopes around those first: they are the smallest surface and the highest stakes. Then give every agent its own identity, instrument the calls so you can see what they are doing, and tighten outward from there. The mindset shift is the whole thing — stop asking only whether the caller is authenticated, and start asking what it intends, what it is scoped to, and what it can break.

## Diagrams

Standalone SVG diagrams, licensed CC BY 4.0 with attribution to John Bradshaw — link back to https://bradshaw.cloud/strategy/agentic-api-security/ when embedding.

- [The caller is no longer a person (SVG)](https://bradshaw.cloud/strategy/agentic-api-security/diagrams/threat-model.svg)
- [An agent wears its own identity, never a borrowed one (SVG)](https://bradshaw.cloud/strategy/agentic-api-security/diagrams/identity.svg)
- [Scope to the task, not the role (SVG)](https://bradshaw.cloud/strategy/agentic-api-security/diagrams/scope.svg)
- [A human stands between the agent and anything irreversible (SVG)](https://bradshaw.cloud/strategy/agentic-api-security/diagrams/reversibility.svg)
- [You can't secure what you can't see (SVG)](https://bradshaw.cloud/strategy/agentic-api-security/diagrams/observability.svg)

## Related

- [Read the full article](https://bradshaw.cloud/writing/api-security-when-the-caller-is-an-ai-agent/) — the argument in full, for when the caller is an AI agent.
- [Agentic AI patterns](https://bradshaw.cloud/strategy/agentic-ai/) — the architectures these controls have to contain.
- [FinOps for AI](https://bradshaw.cloud/strategy/finops-for-ai/) — the same gateway discipline, applied to spend instead of scope.
- [Model Context Protocol](https://bradshaw.cloud/strategy/mcp/) — the standard interface agents use to reach your systems.
- [All strategy insights](https://bradshaw.cloud/strategy/)