Agentic AI · Identity · Governance

The five tollgates: a practical control model for AI agents

Identity, Authorisation, Execution, Observation and Containment — a simple way to decide whether an AI agent is safe to run, and what to fix first.

Aidan Tolson · · 4 min read

Most conversations about AI security start in the wrong place. They start with the model — its training data, its guardrails, its tendency to hallucinate — when the risk that should keep a CISO awake is much more familiar. An agent is software that holds credentials, reads untrusted input and takes actions in your systems. We know how to govern that. We just have not been doing it for agents.

The five tollgates are a way of making that governance concrete. Every action an agent takes should pass through all five. If you cannot say how a given agent is constrained at each one, you have found your next piece of work.

1. Identity

Every agent has a verifiable, owned, non-human identity.

The first question is the simplest and the most often failed: which agents do you have, and who owns each one? Agents are created by product teams, platform teams, individual developers and — increasingly — by other agents. They authenticate using service accounts, API keys and delegated OAuth grants that rarely pass through your joiner–mover–leaver process.

An agent without a named owner is an orphaned account with the ability to reason. An agent that acts under a person’s session is worse: its actions are indistinguishable from that person’s in your logs.

What good looks like: an inventory of agents and non-human identities, each with a named business and technical owner, distinct credentials and an expiry date.

2. Authorisation

Least privilege, scoped to the task and bounded in time.

Agents inherit the blast radius of their credentials. An assistant given broad read access “to be helpful” can be manipulated into reading, summarising and sending anything it can reach.

Authorisation for agents has two parts. The first is conventional: grant only the permissions the task requires, and remove standing privilege in favour of just-in-time grants. The second is newer: when an agent acts on a person’s behalf, the delegation itself must be explicit — what it may do, for whom, and for how long.

What good looks like: permissions reviewed against what agents actually use, time-bound access to sensitive systems, and delegation that is recorded and bounded.

3. Execution

High-impact actions pass policy — and a human where it matters.

This is the tollgate that separates an agent that suggests from an agent that does. Payments, deletions, changes to access and communications leaving the organisation should never depend solely on the agent’s own judgement, because that judgement can be steered by the content it reads.

Put policy enforcement in front of tool calls, not just in the prompt. Define the thresholds above which a named person must approve. Then test it: adversarial testing for prompt injection and tool misuse should be a precondition for production, in the same way that penetration testing is for a customer-facing application.

What good looks like: policy checks enforced outside the model, accountable human approval above defined risk thresholds, and evidence of adversarial testing before go-live.

4. Observation

Every prompt, tool call and decision is attributable.

When something goes wrong, you will need to answer three questions quickly: what did the agent do, why did it do it, and on whose authority? Most organisations can answer the first question partially and the other two not at all.

Logging for agents needs to capture inputs, tool calls, outputs and the identity and owner behind each one — in a form your SOC can search and your regulator would accept as evidence. Detection matters too: an agent suddenly accessing systems it has never touched, or calling tools at unusual volumes, should raise an alert like any other anomalous identity.

What good looks like: attributable logs, SOC detection content for agent behaviour, and retention long enough to reconstruct an incident.

5. Containment

When an agent misbehaves, you can stop it and explain it.

The final tollgate is the one boards care about most, because it determines how bad a bad day becomes. Can you suspend a single agent within minutes without taking the whole service down? Can you revoke its credentials and roll back what it did? Can you give your board — and, if necessary, a regulator — a clear account within hours?

None of this can be improvised. Kill switches need to be built and tested; incident playbooks need an agent-specific path; executives need to have rehearsed the decisions.

What good looks like: a tested per-agent kill switch, playbooks that cover compromised or misbehaving agents, and board-level reporting prepared in advance.

Using the model

The tollgates are deliberately unglamorous. They map onto controls your organisation already understands — identity governance, privileged access, change control, logging and incident response — which is exactly the point. Governing agents does not require a new discipline. It requires extending the disciplines you already have to a new kind of actor, and being honest about where they stop short today.

Start with Identity. You cannot authorise, observe or contain an agent you have not found.

If you want a quick read on where you stand, the five-tollgate diagnostic takes about four minutes.

Start with a confidential conversation.

Sixty minutes with a senior practitioner. No sales team, no obligation — just a candid view of where you stand and what to do first.