Pattern: External Governance for Codex — “Codex Proposes, Beacon Decides” (Receipts + Trust Score + Enforcement

Codex
1

Hi all — I’m experimenting with a production-grade pattern for governing Codex agents without relying on model-vendor tool semantics or post-hoc monitoring.

The thesis

Codex is a powerful proposer (plans, code, tool calls) — but it doesn’t currently provide an enterprise-grade execution boundary (policy, proof, revocation, audit evidence) as a first-class primitive.

So instead of “wrapping Codex,” I’m treating Codex as an untrusted probabilistic planner and placing it inside an enterprise-controlled runtime gateway (Beacon):

Codex proposes → Beacon gates/receipts/scores → only ALLOW executes

Why I’m posting

The community digest shows a lot of reoccurring issues:

  • context window exhaustion / compression not triggering as expected
  • tool visibility inconsistencies
  • occasional strange token generation / reliability regressions

Those issues are real, but they’re not the core deployment problem once tool-using agents touch enterprise systems.
The core problem is: how do we allow a probabilistic planner to operate inside deterministic control?

What Beacon does (in my environment)

(Observed in my system; not affiliated with OpenAI.)

  • Beacon runs as an external gate on localhost.
  • Every “material action” must pass through Beacon:
    • policy checks / risk checks
    • receipt creation (append-only audit trail)
    • scalar trust score update (300–850 surface with bands + factor explanations)
    • kill-switch / revocation is possible because execution is centralized

Endpoints I have live on the Scalar-enabled instance:

  • GET /api/scalar
  • GET /api/scalar/:agentId
  • POST /api/scalar/emit (loopback/admin-only; writes a non-billable SCALAR_SCORE evidence event)

The integration (fastest viable path)

I’m adding a single choke-point endpoint:

POST /api/execute
Body: { agent_id, tenant_id, opportunity_id, proposed_plan, tools, code, idempotency_key }

Response:

  • ALLOW → returns receipt_id + constraints → Codex executes in its sandbox
  • DENY → returns reason + receipt_id → Codex stops and reports the denial verbatim

Codex-side, I force execution through one custom tool (beacon_gate) so it can’t bypass the gate:

  • before any tool call, code execution, or external operation → call Beacon
  • only proceed on ALLOW
  • include receipt_id in the final output

Gotcha I hit (worth sharing)

Even if you pump “ALLOW” receipts, your trust score can stay low if receipts don’t qualify.

In my setup, post-cutover scoring requires signature-qualified receipts.
I was generating receipts with opportunity_id populated, but signature_verified remained 0, so:

  • total receipts were increasing
  • but “valid receipts” remained ~flat
  • scalar stayed near the floor

Fix was: wire signature verification into the gate (or emit via the canonical signed ingestion path).

Question to the community

  1. Has anyone seen a native way to enforce external gating for Codex tool use (middleware hooks, required tool, or similar)?
  2. If you’ve built agent governance layers: what contract shapes worked best for you (ALLOW/DENY + reason + receipt)?
  3. If you’re seeing context compression/tool visibility issues: are there patterns that reduce the blast radius (chunking, self-throttle, forced small plans)?

If people are interested, I can share a sanitized contract spec for /api/execute and the receipt schema / verifier approach (no secrets).