Nexa ProofGate

Tests prove code runs. ProofGate proves AI stayed within authority by verifying Git changes, repository policy, required checks, owner approval, and tamper-evident evidence.

Comment

Inspiration

AI coding agents can generate useful code and pass every repository test. But passing tests do not prove that the agent changed only what it was authorized to change.

As AI agents become more autonomous, repository owners need evidence of both technical correctness and authority compliance. Nexa ProofGate was built to create a deterministic, owner-controlled admission layer between AI-generated changes and trusted code.

What it does

Nexa ProofGate is a local-first AI-code admission control system.

It captures the bounded task, observes real Git working-tree changes, loads the committed repository authority policy, classifies allowed and protected paths, runs repository-declared checks, and produces a deterministic admission result.

A passing test is not enough to unlock approval.

If an agent changes a protected or out-of-scope file, ProofGate blocks admission even when every test passes.

When all changes stay within authority and the required checks pass, ProofGate stops at Owner Review Required. Only the declared owner can explicitly approve or reject the exact tested snapshot.

An approved result is sealed into a SHA-256 Proof Pack that binds:

  • the authorized task
  • Codex session lineage
  • Git branch and snapshot
  • changed-file evidence
  • committed policy and policy hash
  • test results
  • owner decision
  • timestamps and proof lineage

ProofGate can later verify the sealed proof against the current repository. Any post-approval source or policy drift invalidates the old proof.

Why it is more useful than blind trust

Tests answer: “Does the code run?”

ProofGate additionally answers:

  • What was the AI authorized to change?
  • What did it actually change?
  • Did every changed path remain within committed policy?
  • Which repository-declared checks passed or failed?
  • Did the owner explicitly approve this exact snapshot?
  • Is the approved proof still current?

The central principle is:

Request ≠ Proposal ≠ Approval ≠ Authority ≠ Execution

How we built it

ProofGate was built as a Node.js developer tool with a local browser-based evidence control room.

The deterministic core includes:

  • real Git evidence collection
  • committed-policy loading
  • allowed and protected path enforcement
  • safe repository-declared test execution
  • immutable owner decisions
  • concurrent-decision protection
  • policy and repository drift detection
  • process timeout and child-process termination
  • workspace traversal and symlink protection
  • sensitive-output redaction
  • Proof Pack generation and integrity verification
  • fail-closed API behavior

The interface connects three questions:

  1. Task Contract — What was authorized?
  2. Live Evidence — What actually changed?
  3. Admission Verdict — Can the owner admit it?

Demo journeys

Safe Proof

The agent changes only the quotation source and test files. Tests pass and every changed path remains within authority.

ProofGate does not approve automatically. It unlocks owner review and waits for an explicit decision.

Red-Team Proof

The quotation code and tests change, but the agent also modifies a protected compliance policy.

The repository test still passes, but ProofGate blocks admission and keeps owner approval locked.

Post-approval tamper proof

The owner approves and seals an exact tested snapshot.

After the repository is modified, ProofGate detects snapshot drift and marks the previously approved proof as invalid. The old approval cannot authorize the new state.

How we used Codex

Codex was used extensively to build, audit, test, and harden the product.

It helped implement the Git evidence pipeline, authority enforcement, secure test execution, Proof Pack integrity, current-proof verification, server APIs, regression coverage, documentation, and the final judge-facing evidence control room.

Codex also performed an adversarial final audit covering policy self-modification, stale evidence, concurrent owner decisions, path traversal, junction and symlink escape, sensitive-output redaction, process-tree timeouts, browser responsiveness, and fail-closed behavior.

How we used GPT-5.6

GPT-5.6 was used for product reasoning, architecture review, threat-model analysis, explainability design, UX planning, test strategy, demo sequencing, and submission preparation.

Inside ProofGate, GPT-5.6 remains advisory only. It may explain risk, but it cannot change a deterministic PASS or BLOCK result, unlock owner authority, approve code, or override repository policy.

Challenges

The hardest challenge was separating technical success from authority.

A test can pass even when an agent edits a protected compliance policy. ProofGate therefore had to preserve strict boundaries between tests, policy, owner authority, evidence, and execution.

Other challenges included:

  • using committed policy instead of an agent-edited working copy
  • preventing stale or concurrent owner decisions
  • detecting post-approval drift
  • safely terminating test-process trees
  • redacting sensitive local output
  • keeping the browser interface responsive during repeated evidence updates

Accomplishments

  • Passing tests cannot override protected-path violations
  • Repository authority comes from committed policy
  • Owner decisions are explicit, immutable, and snapshot-bound
  • Post-approval repository or policy drift invalidates proof
  • GPT-5.6 cannot modify deterministic admission decisions
  • Proof Packs bind policy, repository, checks, owner decision, and lineage hashes
  • Safe, Red-Team, approval, current-proof, and tamper journeys work in one interface
  • Every result explains what happened, why, what is proven, what is not proven, and the next safe action
  • The complete automated verification workflow and smoke test pass

What we learned

AI-code safety is not only about whether code works. It is also about whether the agent stayed inside the authority it was given.

Tests, AI review, owner approval, and execution are different security boundaries and should never be treated as interchangeable.

What’s next

Future work includes cryptographic owner authentication, signed external attestations, CI-provider adapters, multi-process evidence storage, policy templates for different repositories, and controlled enterprise source-control integrations.

The current V0.5 remains deliberately local-first, deterministic, and owner-controlled.

Current limitations

ProofGate provides deterministic local evidence and authority enforcement. It does not guarantee that code is bug-free, replace professional security review, or provide independent third-party attestation.

Built With

Share this project:

Updates