The three review gates that scale

Gate 1 · Tool and MCP allowlisting — run it as a supply-chain process

An MCP server is not a library. It is code running with your agent’s privileges that also gets to put text into your agent’s context — so it can both act and persuade. Treat additions the way you treat a new production dependency with an interactive shell.

The gate is a short, boring form per entry, held in a registry the platform owns:

• Owner (a named human, not a team alias) and a review date.
• Pinned version or digest — never a floating tag. The supply chain risk is a future version, not today’s.
• Scope requested: which tools of that server are enabled, what data they reach, what egress they need.
• Who can reach it: which agents, which environments, which tenants.
• Re-review trigger: any version bump, any scope increase, any maintainer change.

Containment, so the gate is not your only defence: least privilege credentials per tool, an egress allowlist so a compromised server cannot reach an arbitrary host, output treated as untrusted data rather than instructions, and the inventory query — which agents can reach this server? — answerable in minutes, because that is the first question of the incident.

Gate 2 · Pre-production eval sign-off — a person signs a number

The mechanism is the CI regression suite; the gate is the accountability wrapped around it. A sign-off record that actually works is one screen:

• The version under review (prompt, tools, pinned model snapshot) and the version it replaces.
• Pass rate on the golden set, with the delta, and the specific cases that regressed.
• The failure modes seen, not just the score — a flat pass rate hiding a new class of wrong action is a regression.
• Cost and latency per task against budget.
• A named signer, and what they would have blocked on.

Two rules keep it honest. First, the threshold is agreed before the run, otherwise it is negotiated afterwards against the launch date. Second, if the suite is advisory, it is not a gate — it is a dashboard with extra steps.

Gate 3 · Security review triggers — a new trifecta leg means review

Reviewing every release is impossible; reviewing every capability change is tractable. The clean trigger comes from the lethal trifecta — an agent is exposed when it combines access to private data, exposure to untrusted content, and the ability to communicate externally. Two legs is a design; three legs is an exfiltration path waiting for injected text.

So the trigger list is short and mechanical:

• The agent gains a new data source (a leg-one change) — including a new read-only one.
• The agent begins reading content it does not control: web pages, inbound email, tickets, PRs, tool output from third parties.
• The agent gains an outbound channel: send, post, webhook, write to a shared store, or any tool with a free-text URL parameter.
• The autonomy tier for any action rises, or an approval gate is removed.
• A tool’s scope widens — same tool, broader permissions.

Containment: the review’s job is not to say no; it is to pick which leg to cut. Usually that means an egress allowlist, a narrower credential, or moving the risky read into a subagent whose output is summarised text rather than raw untrusted content.

What does not deserve a gate

Naming this matters as much as naming the triggers, because a process that gates everything gets bypassed for everything.

Copy edits to a prompt with no behavioural intent, dashboard and alert-threshold changes, adding an eval case, retention and logging config, and scaling parameters all ship on the fast path — versioned, traced, reversible, no committee. The gates buy their credibility from being rare.

Routing one change through the gates

1. A change is proposed

   Prompt edit, new tool, model bump, orchestration change, config tweak — everything enters here.

2. Adds a tool or MCP server?

   Also fires on a version bump or a scope increase for a tool you already allow.

3. Allowlist gate: registry entry, pin, owner, scope

   Platform plus security own the gate; the requesting team owns the justification and the narrowest workable scope.

4. New trifecta leg, wider scope, or higher autonomy?

   New data source, new untrusted content, new outbound channel, removed approval gate, widened credential.

5. Security review: which leg do we cut?

   Output is a design change — egress allowlist, narrower credential, or isolating the untrusted read in a subagent — not a signature.

6. Does agent behaviour change?

   Prompt semantics, tool set, model snapshot, orchestration, retrieval corpus. Copy edits and dashboards do not.

7. Eval gate: suite runs, a named human signs the number

   Threshold agreed before the run. Regressed cases and new failure modes are reviewed, not just the headline pass rate.

8. Staged rollout: shadow → canary → full

   Automatic rollback on the metrics agreed in advance; kill switch armed and drilled.

9. Live, inventoried, revocable
10. Fast path: ship it — versioned and traced

    Config, thresholds, retention, new eval cases, copy edits. The gates keep their credibility by being rare.