Governance written after a rollout is a clean-up exercise. Written before it, the same decisions take an afternoon and prevent most of the problems a clean-up would have to fix.
None of what follows requires a committee or a hundred-page policy. It requires someone to write down six answers before access goes wide, and to make sure the runtime enforces them — because a policy the system does not enforce is a slide.
1. Which surfaces are approved
Claude arrives through several doors: the Claude apps, Claude Code, the API, and every MCP server that connects it to another system. Approve each one separately. A blanket yes to "Claude" means the first person to connect a new MCP server has quietly expanded what the model can reach, without anyone deciding they should.
2. Which data may reach the model
Classify data into tiers: what may be sent freely, what must be redacted first, and what never leaves your systems. Redaction belongs on the way in — identifiers and secrets removed before the request — not filtered out of the response afterwards.
3. How logging and retention are set
Decide deliberately what is logged, where, and for how long, and match retention to your existing records policy rather than to whatever the default happens to be. When someone later asks what a workflow decided last Tuesday and why, the answer should come from a log, not from memory.
4. Who approves a workflow before it goes live
For every workflow: who proposes it, who approves it, and who can switch it off. Write this as a small decision-rights matrix. The last column matters most. The person who can switch a workflow off should be reachable, and should know they hold that authority.
A useful test
For any live Claude workflow, can you name one person — not a team — who is accountable for it? If not, it does not have an owner yet.
5. What may happen without a person
This is the most consequential line to draw, and it should be drawn per workflow, in writing, before launch. The default teams fall into is whatever the demo happened to do. A sensible starting position: reading, retrieving, summarising, drafting and proposing are fine without review; anything that posts to a ledger or a system of record, reaches a customer under your name, or cannot be undone waits for a person.
Guardrails: deciding what an agent may do unsupervised
6. Who owns the outcome when it is wrong
Models get things wrong. The question is not whether that happens but who responds. Agree a rollback position for each workflow while everyone is calm, and name the owner who will act on it.
Make the runtime enforce it
Each of these decisions has a control that enforces it: tool and MCP allowlists for approved surfaces, redaction before the request for data classes, audit logging for retention, permission modes and approval steps for the unsupervised line, and model pinning so an upgrade is tested before it reaches a live workflow. Write the policy, then set the controls to match it.
Where Focus20 fits
Our Claude consulting practice writes this governance model with you and sets the controls that enforce it, as the first step of a rollout rather than an afterthought.