H33
L2 · Reconstructed · June 2, 2026

First Agent Authority Envelope
What was the agent allowed to do?

Every IN-envelope capability is in the agent's scope. Every OUT-of-envelope capability is not. The envelope lives in signed canonical events — not in policy text, not in runtime config. A regulator three years later can ask "what exactly was this agent allowed to do?" and reconstruct the answer from the canonical event log alone.

View the reconstruction JSON Prior level (L1) → Markdown report
Transfer Agents Fund Administrators Insurance Examiners AI Governance Buyers Compliance / Risk Regulators
What was proven · 10-second read

The agent's boundary is in the event log. Not in policy text. Not in config.

01
The agent's envelope is in signed canonical events.
02
Every IN-envelope capability is present. Every OUT-of-envelope capability is absent.
03
A regulator three years later reconstructs the boundary from the event log alone.
Reading any H33 proof · the six questions

Same six answers. Different scope. The reader recognizes the machine.

  1. 1What happened?

    A human supervisor (princ_customer_9) delegated a bounded capability set to an AI agent. The agent received exactly two capabilities; three OUT-of-envelope capabilities are retained by the human.

  2. 2Who had authority?

    Human supervisor: princ_customer_9 via auth_44962d9b-…_envelope_supervisor (scope of 4 including supervise_agent). AI agent: princ_ai_envelope_agent_001 via auth_44962d9b-…_envelope_agent (scope of 2).

  3. 3How was authority reconstructed?

    replay_until(events, T=1800000000000, …) against the canonical event log. trace_provenance walks AI grant → human grant → root.

  4. 4What state was produced?

    state_id = b52fe565…dae66, verdict Valid, 2 active grants, 0 excluded. AI scope reconstructed as exactly [review_transfer_request, classify_risk].

  5. 5What artifact was returned?

    reconstruction.json — snapshot, envelope IN/OUT matrix, supervisor's retained capabilities, regulator-question answer.

  6. 6How can a third party verify it?

    Run scif-backend tests/agent_authority_envelope_001.rs at SHA d4b6c27b0. Expect identical state_id; expect IN-set complete and OUT-set fully denied.

01The envelope (reconstructed from signed events)

Agent Authority Envelope · princ_ai_envelope_agent_001
Two capabilities inside. Three capabilities outside. Asserted in both directions.
▸ Inside — allowed
  • ✓review_transfer_request
  • ✓classify_risk
▸ Outside — denied
  • ✗approve_transfer
  • ✗move_assets
  • ✗grant_authority
Envelope size = 2 · Asserted: IN.all(present) AND OUT.all(absent) · Hard test failures both directions.

The OUT capabilities are retained by the human supervisor (princ_customer_9), whose grant carries [supervise_agent, approve_transfer, move_assets, grant_authority]. The human's grant is signed by the tenant root; the agent's grant is signed by the human. trace_provenance walks agent → human → root and emits "chain to root verified" via the human delegator.

02The reconstructed state_id

Agent envelope tenant — reconstructed at T = 1800000000000
b52fe565185a057fdb69a153756a954469a9bff9c35d6c36f1b430b14cedae66
Determinism: r1 == r2 · Self-consistency: verify_state_id() = true · Verdict: Valid · Active grants: 2

03The IN / OUT matrix (verifiable)

CapabilitySetReconstructed presence
review_transfer_requestIN✓ in AI scope
classify_riskIN✓ in AI scope
approve_transferOUT✗ absent from AI scope · retained by human
move_assetsOUT✗ absent from AI scope · retained by human
grant_authorityOUT✗ absent from AI scope · retained by human

Hard failure messages in the test:

ENVELOPE FAILURE (IN missing): capability `X` inside AI envelope; scope is {…}
ENVELOPE FAILURE (OUT leaked): capability `Y` MUST be outside but appears in scope {…}

Either failure mode is loud, named, and forensically diagnostic.

04The forensic explanation

{
  "authority_id": "auth_44962d9b-…_envelope_agent",
  "included": true,
  "reason": "Granted by princ_customer_9 to princ_ai_envelope_agent_001;
             policy pol_envelope_agent_v1;
             chain to root verified."
}

The phrase "chain to root verified" confirms the human delegator's grant exists, is unrevoked, and is itself rooted. The replay engine walks the chain in `trace_provenance` and emits the explanation a regulator would consult.

05The regulator's question (answered)

Q · The question every transfer agent / fund admin / insurance examiner asks about an AI agent

"What exactly was this agent allowed to do at T?"

A · Reconstructed

Exactly these capabilities: [review_transfer_request, classify_risk]. Not these: [approve_transfer, move_assets, grant_authority]. Reconstructed from the canonical event log alone — no platform-state trust required.

06Known limitations

  1. Reconstruction-only, not live agent execution. No live agent has been rejected by a constrained endpoint here. The receipt-issuing service still needs to enforce scope at request time.
  2. Two IN, three OUT — illustrative. Real production envelopes can be wider; same mechanism scaled.
  3. No conditional limits (amounts, jurisdictions). "May approve transfers ≤ $25k, US, accredited" requires finer-grained capability strings or a policy-text layer. Both are extensions of the same model.
  4. Scope-subset enforcement is policy-layer, not chain-layer (same limitation as L1).
  5. AuthEvent.signature not verified at replay ingestion (Phase E lock).

07Where this proof sits in the agentic management ladder

L1
Agent Recommendation — AI recommends, human approves. Delegation in the canonical event log. first-ai-assisted-transfer
proven
L2
Agent Authority Envelope — explicit IN/OUT capability set; envelope reconstructable from event log. This proof.
proven now
L3
Agent Supervisor Chain — Human Supervisor → AI Reviewer → AI Risk Agent → Recommendation → Human Approval. Multi-agent governance.
next (Proof #8)
L4
Autonomous Transfer Operations — AI validates KYC + restrictions + limits + recommends; transfer officer reviews exceptions only; full chain replayable 3 years later.
killer proof

08Evidence appendix

FieldValue
state_idb52fe565185a057fdb69a153756a954469a9bff9c35d6c36f1b430b14cedae66
Replay-until T (ms)1800000000000
Tenant IDtenant_agent_envelope_44962d9b-25f5-5622-bd9a-98d5580bb8a2
Tenant rootprinc_root_agent_envelope_44962d9b-…
Human supervisorprinc_customer_9 — scope: [supervise_agent, approve_transfer, move_assets, grant_authority]
AI agentprinc_ai_envelope_agent_001 — scope: [review_transfer_request, classify_risk]
Human authority IDauth_44962d9b-…_envelope_supervisor
AI authority IDauth_44962d9b-…_envelope_agent
Human policypol_envelope_supervisor_v1
AI policypol_envelope_agent_v1
Reconstruction artifactreconstruction.json
Harnesstests/agent_authority_envelope_001.rs (scif-backend @ d4b6c27b0)
Same human, prior proofsV101 first proof · L1 first-ai-assisted-transfer

09Readiness determination

Determination

First Agent Authority Envelope (L2): PROVEN IN OPERATION for one root → human → bounded-AI delegation, two IN capabilities, three OUT capabilities, reconstructed deterministically.

What this unlocks: conversations with transfer agents, fund administrators, insurance examiners, and AI governance buyers — every one of whom is worried about agent boundaries. The answer is the IN/OUT matrix, reconstructable from the canonical event log alone.

What this does not unlock: a claim that any platform has deployed a bounded AI agent against this tenant; a claim that capability-set subset is enforced at the engine layer; L3 or L4 properties.

Issued by H33, Inc. · Eric Beans, CEO · 2026-06-02

Independently reconstructable. Inputs: canonical event log access · scif-backend @ d4b6c27b0 · harness tests/agent_authority_envelope_001.rs.