The Security Coach for AI Agents

You do not secure a junior engineer by handing them a policy document. You give them a scope they cannot exceed, a review step on the things that are expensive to undo, and feedback tight enough that they learn the shape of the boundary.

Agents are the same, minus the learning. They will not internalise your intent between sessions.

So the interesting question in the room is never “do we trust the model?”. By the time anyone asks it, the decision that matters has already been made, quietly, by whoever wired up the tools.

The decision nobody knows they are making

Here is the distinction I now open with, because it reorganises the whole conversation.

A prompt is a promise. A tool interface is a constraint.

Promises are useful. They coordinate, they document intent, they make behaviour more likely. They are also negotiable by anyone who can talk, which now includes the input. Constraints are not negotiable by argument, only by change control.

Every team I meet has decided how much of their safety story rests on promises versus constraints. Almost none of them decided it on purpose.

There is a test for this, and it takes about a minute. Name an action you would be embarrassed to explain to your regulator. Then name the artefact that stops it. If the artefact is a paragraph of English, you have a promise. If it is a policy, a scope, or a check with a version number, you have a constraint.

What changed, and what did not

The genuinely new thing is that non-determinism moved inside the control flow.

We have shipped unreliable components for decades — flaky networks, third-party APIs, users. We handled them by validating at the boundary. What is new is a component that decides which action to take and chooses its own arguments, differently, on identical input.

What did not change is the discipline. “How do I compose an untrusted component without inheriting its privileges?” is the question I wrote a paper about for mobile mashups years before anyone said agent. The answer was capability mediation at the boundary then. It is capability mediation at the boundary now.

That is not a nostalgia point. It tells you where the budget goes.

The instinct is to spend on the model: better prompts, better system messages, a classifier watching the output. Each of those buys you a better promise. None of them buys a constraint. Spending your whole budget on the promise side is the single most common mistake I see, and it is attractive precisely because promises are cheap to write and demo beautifully.

Four things that hold up

Everything I have built in this space reduces to four patterns.

1 — Scope actions, not intentions

The security boundary belongs at the tool interface, not in the instructions.

If an agent holds a database credential, it can reach everything that credential reaches. The system prompt saying “only read customer records” is a promise made on behalf of a constraint that was never issued.

So issue the constraint. Narrowest capability per tool. Credentials minted per task and expiring in minutes. And then the deliverable that matters: the blast radius of a fully compromised agent, written down on one page.

That one page is also the most useful artefact I own in a penthouse conversation. Executives do not buy “we scoped the tools”. They buy a bounded, quantified worst case, because a bounded worst case is something they can price and sign.

2 — Decide irreversible things deterministically

Model judgement is a fine input and a poor authority.

For anything you cannot undo — deleting data, moving money, changing an access policy, pushing to production — the decision has to come from a deterministic check a human can read. The agent proposes; code decides.

This split is worth more than its engineering cost, and the reason is organisational rather than technical. It converts “do we trust the model?” — a question nobody in the room can answer — into “do we trust this rule?”, which is a question security teams have been answering competently for thirty years.

I do not raise the trust question in reviews any more. I ask which rule decides, and who owns it.

3 — Place human approval by blast radius

Human-in-the-loop is not a virtue to be maximised. This is the pattern I learned by getting it wrong.

On an early design I gated generously, on the theory that more review could only be safer. Within weeks the approvers were clicking through everything, because I had spent their attention on approvals that carried no consequence. I had not added judgement to the system. I had added latency, and taken judgement out.

Attention is a budget with a hard ceiling and no overdraft facility. Rank actions by what they cost to reverse, gate the top of that list, and let deterministic checks and an action log carry the rest.

4 — Write the threat model with the people who own the agent

I run these as a questionnaire with the customer’s own technical leads, against scenarios from their industry and their project rather than a generic checklist.

The obvious benefit is a better threat model, because the people who know the system are the ones enumerating it. The benefit that actually pays is that the requirements stop arriving from outside. Nobody argues about a mitigation for a threat they identified themselves.

This is the least glamorous of the four and it moves the most. It is also the one that makes patterns one to three possible at all: you cannot scope a tool nobody has enumerated.

The failure mode nobody admits to

The most common audit story I hear is: we log the transcripts.

Transcripts are seductive because they are free and they look thorough. They tell you what was said. They do not tell you what was done, and they are the wrong shape to reason about at volume — nobody reads them, and the one time it matters you are reconstructing intent from prose under time pressure.

What you want is a structured record of every action attempted, the capability that authorised it, the check that allowed or blocked it, and the outcome. Four columns. Queryable, alertable, and small enough to hand over.

Where this costs you

The honest trade-offs, because a pattern without a cost is marketing.

Deterministic gates make some legitimate work slower, and there will be a week where a rule blocks something reasonable and a team loses an afternoon. Task-scoped credentials mean more moving parts in your identity layer, and that layer is now on the critical path for delivery. Threat-modelling workshops cost senior engineering hours up front, from the people you least want to interrupt.

Every one of those is a real bill. I pay them because the alternative — discovering the boundary during an incident — is charged at a much worse rate, and by then the negotiation is no longer yours.

Where I would not pay: a small internal tool, read-only, on non-sensitive data, with a blast radius you can write in one line. Applying all four patterns there is theatre, and theatre teaches your engineers that security advice does not distinguish between cases.

Why this is a delivery argument, not a risk argument

With executives I deliberately do not lead with risk.

A moratorium on agentic adoption does not stop adoption. It stops visible adoption, and what you inherit instead is a shadow estate assembled by people optimising for shipping — with none of the four patterns, and no page describing the blast radius.

The organisations getting this right made the supported path the easy path: default security in the platform, self-service security for teams that want to move faster than the platform, and a governance model leadership can sign rather than one that quietly depends on nobody testing it.

You can tell it is working from two signals. Design reviews stop asking whether the model can be trusted and start arguing about which rule decides. And the number of agents in production that nobody told you about goes to zero — not because you forbade them, but because there was no reason to route around you.

That is the whole job, and it is why I would rather be called a coach than a gatekeeper.

I write about this work as it develops. If you are wrestling with the same problems, I am reachable on LinkedIn, and the tooling I maintain lives under shenril and BlueSquadron.