Shipping agents to production without a compliance bill you did not plan for

Almost nobody ships an autonomous agent because they finished a compliance programme. But almost everybody discovers, one procurement questionnaire at a time, that they needed certain controls to exist — and retrofitting them after the agent is live is far more expensive than building them in.

This is the subset that carries most of the real risk, and none of it requires a dedicated governance team.

1. Scope the blast radius

List every tool the agent can call and what each one can affect. Then split them: read-only, reversible writes, and irreversible actions. Irreversible actions get a human approval step by default, and turning that off is a deliberate decision someone signs off, not a config flip.

2. Know where the data goes

For every tool, know the destination and whether data is retained. Customer PII should not reach a third-party analytics endpoint by accident, and the answer should be in a table you can hand to a customer, not reconstructed from memory during a security review.

3. Keep the audit trail append-only

Log every tool call with its arguments, its result, and the decision the model made. Append-only, retained for the window your customers actually ask about, with the retention period written down. This is also the single most useful debugging asset you will own.

4. Make the agent's identity real

The agent acts as a service identity, not as a human user. It has its own credentials with narrow scope and its own audit subject. A shared admin token under someone's name is the thing that turns a contained mistake into an unattributable incident.

5. Have a kill switch and test it

One switch that stops the agent taking new actions, keeps it readable for forensics, and does not require a deploy. Then actually pull it once during a rehearsal. A kill switch that has only ever been described in a document is a rumour.

6. Publish what you do with failures

People are far more comfortable with agents that say "I could not do that and here is why" than ones that guess. A visible failure with a reason is a feature. A silent wrong answer discovered by your customer is the incident that ends the project.