Proof-of-Care

Runtime governance for AI agents: one authenticated decision authorizes one exact action, for at most one dispatch attempt, with auditable policy and human review.

Comment

Inspiration

AI agents need more than static permission toggles and activity logs. They need a runtime control point that can answer: may this agent perform this exact action right now, under the current policy, identity, provenance, and trust conditions?

Proof-of-Care began as an executable governance specification for that boundary. Our Build Week goal was to harden the prototype against adversarial use—not merely add another happy-path feature.

What it does

Proof-of-Care places an enforceable, auditable trust boundary between agent intent and tool execution. For its narrow first deployment profile, it validates the active session and signed capability manifest, evaluates provider and operator policy, incorporates domain-specific standing and authenticated contextual provenance, binds authorization to a canonical exact-action envelope, requires a single atomic dispatch claim at the final adapter boundary, and preserves a causally linked, reviewable history of authorization decisions, dispatch claims, and execution outcomes.

The current governed workflow supports a fail-closed filesystem read and one tightly allowlisted HTTPS webhook path. Review-required actions pause for a human decision. Authorization, execution outcome, standing changes, manifest reissue, and projection checkpoints remain causally linked and auditable.

How we built it

The implementation is Python 3.9+ with SQLite-backed governance state, HMAC-signed capability manifests, strict canonical JSON action envelopes, transactional event and projection writes, a local executor subprocess, and concrete filesystem and webhook adapters. It intentionally has no runtime third-party dependencies.

The project existed before the challenge, so this submission isolates the complete Milestone 8 extension added after the submission period opened. From July 13 through July 18, Codex and GPT-5.6 helped deliver M8.0 through M8.12: the security design freeze, CI security-regression harness, authenticated standing, canonical action envelopes, final parameter binding, one-dispatch claiming, authoritative provenance, atomic projection rebuild, delayed-authority refresh, safe key/schema lifecycle, an independent closure audit, and two post-audit remediation packages.

Codex was used as a constrained engineering collaborator rather than an unconstrained code generator. Repository-level AGENTS.md instructions required every behavioral change to identify the governing invariant, trusted and untrusted boundaries, complete action envelope, state transitions, atomic writes, crash windows, replay and concurrency risks, lower-level bypasses, negative tests, and positive controls. GPT-5.6 was especially valuable for tracing authority through the call graph, designing adversarial matrices, and reasoning about failure atomicity. Human decisions set the scope, security claims, milestone boundaries, and acceptance standard.

Challenges we ran into

The hardest challenge was proving authority at the lowest reachable boundary. A typed object is not authenticated authority, a preferred shim path is not a security boundary, and one completion record does not prove one side effect.

The independent M8.10 audit intentionally attacked directly reachable lower-level modules. It found two bypasses that supported-path tests had not disproved: manufactured request authority and reusable unbound execution permits. M8.11 replaced copied request context with stored, expiring, single-use authenticated authority. M8.12 removed raw operation-bearing runner and adapter entry, requiring the lowest reachable dispatch boundary to load, refresh, and atomically claim the exact stored action.

Crash windows before validation, after authorization, after claim, after dispatch, and before callback also required distinct terminal states rather than a single generic failure. Concurrent claimants, stale policy, replay, projection drift, and direct module calls all needed dedicated negative tests.

Accomplishments that we're proud of

  • One authenticated governance decision binds one exact action envelope.
  • Stored request authority is lifecycle-scoped, expiring, single-use, and atomically consumed.
  • Direct runner and adapter entry accepts only a bounded stored authorization reference.
  • Sequential and concurrent second claimants fail before a second local adapter attempt.
  • Delayed reviews and dispatches refresh current policy, manifest, standing, risk, provenance, and parameters.
  • Governance events and required projections commit atomically or rebuild deterministically.
  • Across the Build Week range, 73 files changed with 20,669 insertions and 2,625 deletions.
  • The suite grew from the 343-test security-review baseline to 528 passing tests; the end-to-end simulation and diff validation also pass.

What we learned

Security claims follow executable enforcement, not documentation intent. The most valuable result of M8.10 was not a green checklist—it was finding that two broad security claims were still false and turning those failures into executable remediation contracts.

We also learned that Codex can accelerate rigorous security engineering when its work is constrained by an explicit specification, adversarial tests, narrow claims, and independent review.

What's next for Proof-of-Care

First, rerun M8.10 independently over the merged M8.11/M8.12 call graph and close each governance flag only if every final-boundary criterion passes. Runtime remediations are merged, but formal Milestone 8 closure still awaits that audit rerun and required-check enforcement; this submission does not claim production readiness.

After that gate, the next stage can integrate a Codex agent team against the stable governance contracts without broadening the tool surface prematurely.

Built With

Share this project:

Updates