CommitGate

Inspiration

I kept coming back to one failure mode: an agent can receive the right approval and still execute the wrong action if the proposal changes before the tool call.

That creates a simple but serious problem: approving “a refund” is not enough when the amount, customer, evidence, tenant, policy, or authority can differ by execution time.

CommitGate enforces one invariant:

The action that executes must be the exact action that was evaluated and authorised.

What it does

CommitGate sits between an agent’s structured proposal and a consequence-producing adapter.

It:

1. Computes a canonical SHA-256 digest of the complete proposal.
2. Binds the policy decision or human approval to that digest.
3. Issues five-minute, single-use execution authority scoped to the exact request, decision, action, policy, tenant, and approving authority.
4. Recomputes and validates every binding immediately before execution.
5. Refuses drift, invalid scope, expired authority, consumed tokens, and conflicting duplicate attempts before the adapter is called.
6. Produces a terminal receipt binding the proposal, decision, policy, authority, token, adapter, status, and reported result.
7. Keeps replay comparative and non-authorising.

The demonstration uses a mock customer-refund workflow. An unchanged £25 refund executes once and produces a bound receipt. If the proposal changes after evaluation, CommitGate detects the altered digest and prevents the adapter call.

How I built it

CommitGate extends an existing AgentGate FastAPI proof.

The original AgentGate baseline already provided structured support actions, deterministic policy outcomes, evidence checks, role-gated approval, audit events, a mock refund adapter, replay, and tenant-scoped read endpoints.

During Build Week I added:

• canonical proposal identity;
• rejection of non-finite proposal values;
• decision and approval binding to proposal digest and policy version;
• explicit policy or human execution authority;
• scoped, expiring, single-use server-side tokens;
• immediate pre-consequence drift and authority validation;
• bound success and failure receipts;
• digest-bound duplicate-side-effect prevention;
• replay non-mutation hardening;
• adversarial tests proving refusal before adapter invocation.

The existing endpoint paths, request bodies, four decision outcomes, precedence rules, tenant boundaries, approval semantics, replay isolation, and demo scenarios were preserved.

The implementation uses Python, FastAPI, Pydantic, pytest, standard-library canonical JSON and SHA-256, and an in-memory repository to keep the proof inspectable.

How GPT-5.6 and Codex were used

GPT-5.6 Thinking was the architecture and adversarial reasoning partner. It helped reduce a broader governance architecture to one testable invariant, define the consequence-control contract, challenge implementation assumptions, review each slice, and translate hostile QA findings into bounded corrections.

Codex was the primary repository implementer and reviewer. It inspected the existing AgentGate baseline, implemented CommitGate in logical commits, created and ran adversarial tests, reviewed the baseline-to-head diff, found authority defects, corrected them, and prepared the evidence-backed documentation.

GPT-5.6 is not called by the runtime authority path. The enforcement remains deterministic by design.

Challenges

The difficult part was not computing a hash. It was preserving the meaning of “this exact action was authorised” across requests, decisions, approvals, tokens, execution, and receipts without breaking the existing AgentGate API.

Adversarial QA found two important defects:

• non-finite values could collide with JSON null during canonicalisation;
• mutable approval scope could weaken the authority originally required by the decision.

Both were corrected, and targeted tests now cover non-finite inputs, approval rebinding, role drift, token identity and lifetime, duplicate attempts, adapter failures, replay isolation, and zero adapter invocation after refusal.

The final suite contains 86 passing tests with one pre-existing dependency deprecation warning.

What I learned

My main lesson was blunt: a policy answer is not execution authority.

Safe agentic action requires continuity across:

proposal → identity → decision → authority → validation → consequence → receipt

The most useful design move was narrowing the project. Rather than attempting a general agent-governance platform, CommitGate proves one deep guarantee with executable adversarial evidence.

Current limitations

This is an in-memory, single-process proof.

Tokens and audit state disappear on restart. Duplicate reservation is not distributed exactly-once delivery. Tokens are server-side records, not signed capabilities. Authentication uses development placeholders. Policies are static code. The adapter is a mock and does not prove external settlement. The deepest implemented workflow is customer refunds.

What’s next

The next step is to preserve the same invariant while adding transactional durable storage, a real identity and authority source, and one genuine external adapter.

The boundary should become more durable without becoming broader or less inspectable.

Built With

• fastapi
• github
• gpt-5.6
• openai-codex
• pydantic
• pytest
• python
• rest-api
• sha-256