Sentinel Evidence Gate

• 

## Inspiration

AI coding agents can generate and review code quickly, but a confident model response is not proof that a change is safe. Security claims can be incomplete, malformed, or attached to the wrong version of the code.

We built Sentinel Evidence Gate around one rule:

The model proposes. Deterministic evidence decides.

GPT-5.6 helps localize and explain potential risks, but it is never allowed to approve its own work.

## What it does

Sentinel evaluates the exact Git base and candidate commits of a code change.

1. GPT-5.6 performs patch-aware triage and proposes typed security claims.
2. A strict, closed schema validates model output and its provenance.
3. Registered deterministic verifiers independently evaluate required claims.
4. Evidence is SHA-256-bound to the exact commits, changed files, verifier result, and recorded execution environment.
5. A fail-closed verdict engine returns:
   • BLOCK when evidence supports a security risk.
   • ACCEPT when every required verifier contradicts the risk.
   • REVISE when evidence is missing, malformed, uncertain, unsupported, or cannot be reproduced.

Current coverage includes introduced secret literals, dangerous Python execution, unsafe DEBUG configuration, and an owned SQL-injection replay case.

## Real pull-request protection

Sentinel includes a GitHub Actions pull-request gate. The trusted engine is installed from the base commit while the untrusted target is checked out separately. Candidate code is never installed, imported, or executed by the static PR gate.

We demonstrated the workflow on a temporary proof pull request:

• Introducing an owned hardcoded secret produced BLOCK with exit code 1.
• Removing it produced ACCEPT with exit code 0.
• The proof PR was closed without merging.

The CLI also produces JSON evidence that can be inspected with a dependency-free local verdict viewer.

## How we built it

We built Sentinel with Codex and GPT-5.6 during OpenAI Build Week.

Codex accelerated implementation, test generation, adversarial review, GitHub Actions hardening, and repeated verification. We made the key product decisions ourselves: keeping the model non-authoritative, enforcing default-deny behavior, separating trusted and untrusted checkouts, and limiting replay execution to frozen owned fixtures.

GPT-5.6 performs the fuzzy task it is good at—understanding and localizing suspicious changes. Deterministic code performs the authority-sensitive task: deciding whether reproducible evidence exists.

The repository includes redacted, hash-addressed provenance from a real gpt-5.6-terra API call, along with the corresponding prompt and canonical patch artifacts needed to validate the cache binding.

## Challenges we ran into

The hardest challenge was making every boundary truthful and reproducible.

We had to prevent malformed model output from reaching a verifier, distinguish real live-model provenance from offline fixtures, bind evidence to multi-file Git artifacts, and ensure the GitHub Action never trusted code from the pull request it was judging.

We also had to make our claims narrow. Sentinel does not claim that a hash makes evidence impossible to forge, or that a focused verifier set replaces a mature security platform.

## Accomplishments that we're proud of

• Built a trust boundary where GPT-5.6 can propose security claims but cannot approve code.
• Created typed evidence envelopes bound to exact Git base and candidate commits, changed files, verifier results, and execution metadata.
• Implemented fail-closed decisions: malformed, missing, uncertain, unsupported, or tampered evidence returns REVISE, never ACCEPT.
• Recorded reproducible, redacted provenance from a real GPT-5.6 Terra API call without exposing credentials.
• Built a trusted GitHub Actions gate that never installs, imports, or executes untrusted pull-request code.
• Demonstrated a complete PR workflow: an introduced secret produced BLOCK, and its removal produced ACCEPT.
• Added deterministic static verification plus isolated SQL-injection replay using frozen, owned fixtures.
• Reached 65 passing automated tests covering schemas, provenance, bindings, replay isolation, adversarial inputs, verdict policy, and CI trust boundaries.

## What we learned

Reliable agentic software needs an authority boundary. Models are valuable for reach, prioritization, and explanation, but consequential decisions require independently reproducible evidence.

A hash does not make a verdict impossible to forge. Sentinel’s narrower, honest guarantee is that a verdict cannot be reused against a different artifact without re-running validation.

## What's next for Sentinel Evidence Gate

Sentinel is a focused Build Week implementation, not a replacement for mature SAST or penetration-testing platforms. Its contribution is a trust architecture for AI-generated security claims.

Next steps include additional verifier plugins, signed attestations, broader language support, and integration with established security engines such as CodeQL and Semgrep.

Built With

• codex-5.6
• git
• github-actions
• openai-api
• openai-codex
• python
• sha-256