Sentinel SCA
Proof, With Scope

Inspect what Sentinel has actually proved.

Sentinel separates product claims from evidence. This page distinguishes a bounded execution-enforcement proof, a working physical prototype, and tested runtime control behavior.

Sentinel governs execution paths placed behind its boundary. Alternate or direct execution paths remain outside Sentinel until they are integrated behind that boundary.

Inspectable EET-1 record · 7 September 2026

One file-write run, with its evidence limits.

The execution log reports local permit verification, acquisition of a live execution commit and a completed 72-byte write. A separately collected observer record matches the target within the reported permit window.

{
  "action_id": "act_1788793369608_4566b2d5",
  "action_type": "write_file",
  "execution_audience": "codex_local_v1",
  "approved_at": "2026-09-07T15:02:49.608052Z",
  "observed_at": "2026-09-07T15:02:51.958115+00:00",
  "expires_at": "2026-09-07T15:03:49.608052Z",
  "bytes_written": 72
}

Preview combines selected fields from the execution and observer records. The download preserves the original records and supplies an offline Python consistency checker.

Verification boundary: These are first-party records. The raw signed permit is absent, so the reported signature verification cannot be independently reproduced from this bundle. Target-and-time matching does not identify the writer or exclude another process creating the same target. The observer does not record file contents; a later supplied target copy matches the expected 72 bytes.

The original result reports Layer 3 as attributed. Our reproducible check establishes record consistency, not independent cryptographic proof of the complete execution chain. This record is not the negative-test matrix and does not establish enforcement over alternate execution paths.

Captured 11 September 2026 · First-party integration test

Inspect a real signed decision.

The agent proposed a health read. Sentinel returned REVIEW because its reputation was below the required threshold. No execution permit was returned.

{
  "timestamp": "2026-09-11T13:06:04.238165Z",
  "decision": "review",
  "reason": "Reputation gate: rep=0.32 < 0.40",
  "risk_score": 0.65,
  "replay_id": "5c48dd750f4105ce",
  "execution_permit": null
}

This preview shows selected fields; agent identifiers are omitted. Download the original response to verify its signature.

The response signature and payload hash were verified against the public key captured from Sentinel over HTTPS. Matching audit records subsequently recorded timeout denial. This test did not execute the proposed action or test the execution boundary.

Verification instructions and scope

Use Ed25519 to verify the response signature over the object named by signed_fields, serialized with sorted keys and compact JSON separators. The captured key is first-party key material, not independent attestation. The full response remains unchanged; the preview is not independently signed.

Bounded Enforcement

The EET-1 file-write path

This is the enforcement sequence demonstrated for the Codex EET-1 file-write integration. It is intentionally narrower than a claim about every agent or every execution path.

01
Action proposed

Codex proposes a concrete file-write action.

02
Sentinel evaluates

Identity, policy and action context are checked.

03
Permit issued

An ALLOW can carry bounded signed execution authority.

04
Local verification

The executor verifies the permit cryptographically.

05
Live checks

Commit, revocation and replay state are checked.

06
Side effect

The governed file write occurs only after those checks pass.

07
Evidence

Governance and target-effect evidence can be reconciled.

BOUNDED ENFORCEMENT PROOF

Codex EET-1 file-write integration

For the Codex EET-1 file-write integration, execution proceeds only when the permit passes local cryptographic verification and the live commit, revocation and replay checks immediately before the side effect.

This proof is specific to the Codex EET-1 file-write integration. It does not claim control of every Codex action or alternate execution path.

Evidence Inventory

Three kinds of AI agent execution proof

BOUNDED ENFORCEMENT PROOF

Codex EET-1

Inspect the recorded run and offline consistency checks. First-party records; raw signed permit and authenticated commit receipt are not included.

For the Codex EET-1 file-write integration, execution proceeds only when the permit passes local cryptographic verification and the live commit, revocation and replay checks immediately before the side effect.

This proof is specific to the Codex EET-1 file-write integration. It does not claim control of every Codex action or alternate execution path.
WORKING PROTOTYPE

ESP32 farm-control path

The ESP32 farm-control prototype demonstrates a governed physical-control path from sensor or agent proposal through Sentinel decision to fan and actuator control.

Watch the guided prototype →

Read the case study →

Prototype evidence demonstrates the control pattern; it is not represented as a customer production deployment.
VALIDATED CONTROL BEHAVIOR

Runtime validation

Sentinel validation covers governance correctness, signatures, replay behavior, concurrency, review handling and evidence export behavior within the tested surfaces.

Inspect validation results →

Validation evidence is bounded to the tested Sentinel runtime surfaces and does not establish control of external execution paths that bypass Sentinel.
Public Verification Surfaces

Inspect the cryptographic contract

Governance response key

Public Ed25519 verification metadata for signed Sentinel governance responses.

/.well-known/sentinel-response-key
Execution permit key

Public verification metadata for Sentinel execution permits and their signed fields.

/.well-known/sentinel-execution-key
Validation summary

Tested Sentinel behavior, operational boundaries, signatures, replay and evidence.

/validation
Claim Boundary

What these proofs do not mean

  • They do not prove that every autonomous system is governed by Sentinel.
  • They do not prove control over direct or alternate execution paths that bypass the Sentinel boundary.
  • An ALLOW or DENY response by itself is not proof that a downstream side effect was enforced or prevented.
  • Prototype evidence is not represented as a customer production deployment.
  • Runtime validation is bounded to the surfaces actually tested.
Next Step

Put one real execution path behind the boundary.

Start with a concrete consequential workflow. Define the proposed action, the executor, the authority it needs, and the exact point where Sentinel must be enforced.