Writing the policy

Writing the policy

If you have to produce a policy, make it short and make it about actions.

The useful shape is a small number of rules that can be checked: irreversible actions require a gate decision and a recorded verdict; agents hold per-task capabilities rather than standing credentials; every agent has a current trifecta audit; outbound destinations are allowlisted; every agent appears in the register.

Five rules, all verifiable from artifacts that already exist, none of which mention a model or a vendor. A policy written in terms of models dates the moment someone switches provider. A policy written in terms of actions and authority survives it.

Resist the urge to specify tooling. The moment a policy names a product it becomes a procurement document, and it will be out of date before it is approved.

Getting it funded

None of this work demos. That is its central political problem and it is worth naming before you walk into the meeting.

The five primitives produce no feature. At the end of a quarter the agent does exactly what it did before, slightly slower, with a test suite and an audit log nobody outside the team will look at. Meanwhile the team next door shipped three visible things.

Three arguments that work better than the security case, in roughly this order.

The incident you can describe. Not a hypothetical. The Replit case from chapter 1 is public, specific, and features a code freeze that existed only in a prompt. Most executives understand "the instruction was there and nothing enforced it" immediately, because it is a failure mode they recognise from outside software entirely.

The audit you will be asked for. Chapter 17's hour is the concrete version. The question is not whether an incident occurs, it is whether the answer to "which customers were affected" takes an hour or a fortnight. That is a number a finance function understands.

The thing you cannot ship without it. Most teams have an action they have deliberately not given the agent, because nobody was comfortable. Name it. The architecture in this book is what makes that action shippable, which turns a cost centre into the thing standing between you and the feature everyone wants.

The argument that reliably fails is the abstract one about attack surface. Lead with the blocked feature.

Reviewing it later

Whatever you write down goes stale, so decide up front what triggers a re-read.

Three events are worth binding to a review: a new tool with an irreversible action, a new untrusted channel, and a change to how output is rendered. Each of those invalidates part of the trifecta audit, and none of them currently triggers a security review at most companies.

Put those three in the policy and you have a document that maintains itself, because the engineer adding the tool is the one who updates the sheet.

What this costs

Time in meetings, and the work of restating engineering artifacts in a vocabulary the governance function recognises.

The real cost is that this chapter is where the boundary of your own responsibility gets drawn, and drawing it means admitting what you have not done. A trifecta audit that shows three open legs is an uncomfortable document to hand to a risk committee. It is also the document that gets the work funded, which is the argument for writing it before someone asks.

Chapter 19 assembles everything and runs the attacks one last time.

Sources for this chapter

The artifact mapping table, the six procurement questions, the five-rule policy shape and the argument that policies should be written in terms of actions rather than models are the author's. The characterisation of shadow AI as reliably more privileged than sanctioned agents is experience rather than survey data. Nothing in this chapter is legal advice; the regulatory dates are cited from the Official Journal and from law-firm analysis and should be confirmed with counsel for your own situation.