A governance audit gateway is three files in your repo, not a vendor's licensed runtime.

It is the single policy enforcement point that every tool call the agent makes has to pass through. The gateway reads a policy file to decide whether the call is allowed, records the call (allowed or refused) in an append-only audit log with a hash chain, and lets a CI contract test replay the audit log against the current policy on every pull request. We ship the whole thing as three files in the client's repo: tools/_gateway/policy.yaml, tools/_gateway/wrap.py, and tools/_tests/test_gateway_audit_replay.py.

Those are vendor-attached runtimes. Their policy lives in a console behind SSO, the audit log lives in the vendor's database, and the enforcement point is a network hop you do not control. Ours is three files in your repo. policy.yaml is a git artifact. wrap.py is ~50 lines of stdlib Python you can read in one sitting. The audit log is YAML on disk. There is no per-call enforcement charge, no per-seat console fee, no audit-log retention tier. When the vendor pivots, our gateway does not notice. The model-vendor neutrality extends to the governance layer: model_primary lives in agent.yaml as a one-line swappable value, policy.yaml never names a model, and the gateway is indifferent to which provider answers the call.

A policy file alone is a wish. A gateway that enforces the policy at runtime is real. But a policy that changes over time without re-checking the past is a regression waiting for a regulator. The replay gate runs on every PR that touches policy.yaml or wrap.py. It loads the last 7 days of audit log rows, verifies the prior_hash chain has no breaks, then replays every historical tool call against the proposed policy. If any historical call would now escape scope (or, in the other direction, get blocked by a new tightening), the gate fails. The merge does not happen until the diff is either rolled back or signed off by two owners in writing. This is the bit that vendor consoles structurally cannot do: their previous policy stops existing the moment Save is clicked.

Each row: call_id (uuid), prior_hash (sha256 of the previous row's content), agent name, agent_version_sha (git commit), policy_version (integer), timestamp, tool name, args (with PII redacted before write), decision (ok, reason on refusal), outcome (executed, refused, raised), duration_ms, and a content_hash for the body if applicable. YAML because a human on call at 3am will read it without tools, an examiner will read it with a checklist, and grep, jq via yq, and git all work. It is the same audit-row shape the existing fde10x AML eval harness page describes, generalized to non-financial tools.

The EU AI Act Article 12 requires automatically generated logs for high-risk systems with at least 6 months of retention. Our default retention is 400 days. The Act also requires human oversight (Article 14); confirm_required: true on irreversible tools plus a tokenized human review queue is the operational shape. FFIEC examiner asks for per-alert evidence packs; the audit log row IS the evidence pack, pinned to agent_version_sha and policy_version. SR 11-7 was rescinded for generative AI by OCC Bulletin 2026-13 on April 17 2026, but the FFIEC BSA/AML Examination Manual still drives the exam in the interim governance void; the gateway pattern is what bridges that void, because the audit log is a file an examiner can read.

On a single tool call the gateway adds about 1 to 3 ms of validation plus the time to fsync the audit row (a few ms with a buffered writer; sub-ms with an async sink). Compared to a tool call that hits a database or an external API, the gateway is rounding noise. The bigger latency story is that confirm_required adds a human-in-the-loop wait on irreversible writes; this is intentional and the whole reason the gate is there. We sized the email.send queue at Monetizy.ai so the wait was bounded; 8K outbound emails per day shipped through a confirm-token queue without backpressure.

The gateway sits at the tool-invocation boundary, which is exactly where MCP servers, A2A messages, and orchestrator tool calls all converge. For MCP, wrap.py wraps the MCP client's call_tool method; the policy file gains an mcp_server: section that pins server SHAs. For A2A, the gateway treats inter-agent messages as tools with their own scope and confirm requirements (the policy file gets an agent_to_agent: block). For frameworks (LangGraph, Pydantic AI, custom), the gateway hooks the framework's tool registry on init. The policy.yaml shape does not change; the wrap.py is ~10 lines longer.

Each row is roughly 600 to 1,000 bytes in YAML before compression. At 8,000 calls per day that is 5 to 8 MB per day, ~2 to 3 GB per year. We rotate files by day and compress files older than 30 days with zstd; storage cost over 400 days at 8K calls/day sits well under a single coffee per month on any major object store. The PII redaction step is what keeps the log boring enough to keep around: the gateway replaces matched patterns with [REDACTED:type] tokens before write, and the original is never persisted by the gateway. If the agent calls a database, the row records the table name and arg hash, not the row content.

The gateway is what makes a prompt injection survivable rather than catastrophic. The model can be talked into trying to call db.write or email.send-without-token. policy.yaml says no. wrap.py returns PermissionError. The audit log records 'refused: scope_blocked' as a structured outcome. Your on-call engineer sees a refusal metric spike, not a SAR-filed incident. The work to prevent the LLM from being tricked still matters, but the worst case stops scaling linearly with prompt cleverness. This is the blast-radius framing we covered in /t/ai-agent-blast-radius-database-write-scope; the gateway is the operational shape of that framing.

Week 1 day 3: wrap.py merged behind a feature flag, monitor-only. Week 2: policy.yaml v1 ships with the prototype, paired with the agreed rubric. Week 3: CI replay gate turned on. Week 4: confirm_required wired into the human review queue. Week 5: compliance artifact list rendered from the gateway when high-risk classification applies. Week 6: handoff, runbook, 90-minute transfer session. The IP (policy.yaml, wrap.py, the contract test, the audit log, the runbook) stays in the client's repo when we leave. No platform license, no vendor-attached runtime, no SaaS dashboard the rubric depends on. We have shipped this shape into named production agents at Monetizy.ai (8K emails per day in 1 week), Upstate Remedial Management (400K+ emails sent under tokenized send scope), OpenLaw, PriceFox, and OpenArt.

Yes, and the 7-day monitor-only window is how. Drop wrap.py in around your existing tool functions, set policy.yaml to allow every tool with no constraints, and ship. The audit log starts immediately. In week 2 you read what the agent actually did and write the real policy file from that data, not from a whiteboard guess. The replay gate then prevents the policy from drifting away from what the agent operationally needs. We have retrofitted this onto agents that were 6 to 12 months in production; the work is two PRs and one week, not a rewrite.