DRAFT Date: 2026-10-10 Author: Reuben Bowlby •

Typed Governance Tuples: Portable Interchange and Reference Mediation for Auditable Agentic Systems

This is an unreleased working revision. Any DOI and earlier PDF shown here identify a previous snapshot and do not certify this revision or imply peer review.

Download working source

Typed Governance Tuples v0.3.0 Candidate Manuscript

Title: Typed Governance Tuples: Portable Interchange and Reference Mediation for Auditable Agentic Systems Status: Unreleased specification candidate, v0.3.0; living-source revision 2026-10-10. The existing PDF remains a prior snapshot. Original candidate date: 2026-09-21 Author: Reuben Bowlby (reuben@hummbl.io), HUMMBL, LLC ORCID: 0009-0002-5620-1103 Primary Repository: https://github.com/hummbl-io/governance-tuple-reference

Abstract

Multi-agent delegation creates an audit problem: task intent, capability grants, lifecycle transitions, execution receipts, and verification decisions are often recorded in different systems. We propose Typed Governance Tuples v0.3.0, a candidate interchange profile connecting these records through a signed envelope and explicit identifiers. Six core tuple classes represent contracts, delegated capabilities, context, system decisions, evidence, and attestations. The candidate also considers multi-parent task graphs and policy-defined co-approval.

The contribution is a specification of trust boundaries and validation obligations. An independently controlled monitor must mediate the declared side-effect boundary; signatures bind records to keys; verifiers evaluate observed evidence against contracts. These mechanisms do not establish the truth of arbitrary tool responses, the completeness of unobserved activity, or semantic goal containment for unrestricted natural language. The public reference implementation demonstrates an earlier HMAC-based design and does not substantiate all v0.3.0 requirements. This manuscript identifies the remaining protocol definitions and conformance artifacts needed before an interoperable implementation or deployment-security claim is warranted.

1. Problem Statement

Auditing an autonomous agentic decision requires answering five coupled questions:

1. Bounded Intent: What specific objective, operational boundaries, and resource budgets were authorized?
2. Delegated Authority: Which principal granted authority, to whom, under what caveats, and via what cryptographic proof?
3. Runtime Lifecycle State: Where does this task reside in the collective workflow, and what control-plane decisions (throttles, halts, approvals) were applied?
4. Mediated Execution: What tools were actually executed, what artifacts were produced, and how was this execution independently verified outside the agent's mutable process memory?
5. Attestation & Verification: What independent evaluator reviewed the evidence, and what was the verdict?

The design addresses four possible failure modes, rather than asserting they occur in every agent architecture:

• Untrusted self-reporting: An agent can claim that an action occurred without an independent observation of that action.
• Unmediated side effects: Coverage of a tool router does not imply coverage of subprocesses, filesystem writes, or direct network requests.
• Incomplete authorization: Task-local constraints may omit expiry, audience, ancestor grants, or cumulative resource use.
• Ambiguous verification: A positive review may not identify the exact contract revision and evidence it evaluated.

The tuple profile makes these questions explicit. It cannot resolve them by representation alone: a deployment needs an enforcement boundary, trustworthy keys, an evidence retention policy, and a verifier with a defined mandate. Multiple parents or signers can express a coordination policy, but graph shape alone neither prevents unilateral action nor improves resilience.

1.1 Requirement language and scope

MUST, SHOULD, and MAY denote proposed conformance requirements in the sense of RFC 2119 [1], not a claim of standards adoption or completed implementation. This is a design candidate with unresolved wire-format choices identified in Section 7. No experimental effectiveness results or formal end-to-end security proof are presented. An implementation of an earlier tuple design must not advertise v0.3.0 conformance solely because its class names match.

2. Threat Model, Adversary Capabilities & Trust Boundaries

To establish verifiable auditability, the tuple architecture operates under an explicit threat model.

flowchart TD
    subgraph Untrusted Domain
        Agent[Agent Process / LLM Core]
    end

    subgraph Trusted Execution Boundary
        RM[Isolated Reference Monitor / Kernel eBPF / Sandbox Proxy]
        Tools[Tool & API Gateways]
    end

    subgraph Governance & Audit Fabric
        Verifier[Independent Attestation Verifier]
        Ledger[(Append-Only Signed Tuple Store)]
    end

    Agent -->|1. Requests Tool Call| RM
    RM -->|2. Validates DCT & CONTRACT| RM
    RM -->|3. Mediates Execution| Tools
    Tools -->|4. Raw Execution Result| RM
    RM -->|5. Emits Out-of-Band EVIDENCE| Ledger
    RM -->|6. Returns Sanitized Output| Agent
    Ledger -->|7. Evaluates Evidence Chain| Verifier
    Verifier -->|8. Emits ATTEST Tuple| Ledger

2.1 Adversary Capabilities

The design considers four adversary classes; no attack campaign is reported here:

1. Compromised Delegate ($A_{\text{agent}}$): An agent process that has been hijacked via prompt injection, model weight misalignment, or malicious tool outputs. $A_{\text{agent}}$ attempts to execute unauthorized tools, expand its resource budget, forge execution receipts, or omit audit records.
2. Colluding Delegator-Delegatee ($A_{\text{collude}}$): An internal delegator that issues unauthorized capability grants to a sub-agent. The architecture must ensure that monotonic attenuation and root contract invariants detect and prevent privilege escalation.
3. Malicious Tool / Egress Point ($A_{\text{tool}}$): An external service or API that returns corrupted outputs, attempts side-channel exfiltration, or injects adversarial instructions into agent memory.
4. Eavesdropping / Replaying Adversary ($A_{\text{network}}$): A network-level attacker that attempts to intercept, replay, or equivocate governance records across distributed agent nodes.

2.2 Trust Boundaries

• Untrusted: Agent runtime processes, LLM inference outputs, user-supplied prompt contexts, and external network tool endpoints.
• Trusted:
• The Reference Monitor: A supervisor whose mediation scope is explicitly enumerated and whose policy, keys, and execution are protected from the agent. A proxy or eBPF observer alone is insufficient: namespace isolation, credential restriction, and denial of alternate paths must enforce the claimed scope.
• Key Custody Modules: Hardware-backed (TPM/HSM) or OS-keychain-bound cryptographic identities holding the signing keys of human principals and supervisory monitors.
• Append-Only Witness Storage: A tamper-evident log enforcing backward-hash integrity and public/witness checkpointing.

2.3 Core Security Invariants

• Invariant I-1 (Complete Mediation Within a Declared Boundary): Every side effect in the deployment's enumerated tool/network/filesystem/subprocess/IPC boundary MUST pass an enforcing monitor. Completeness outside that boundary is not claimed.
• Invariant I-2 (Non-Self-Reporting): An EVIDENCE tuple is accepted only if its signature validates under a key authorized by policy for the relevant monitor and observation scope. A valid signature under an agent key is cryptographically valid but profile-ineligible; different keys alone do not establish independent control.
• Invariant I-3 (Record Authenticity): Every normative tuple MUST contain a valid cryptographic signature over its canonical serialized envelope and payload.
• Invariant I-4 (Monotonic Attenuation): Authority granted in child capability tokens MUST not exceed the effective parent authority. Equality is permitted; a profile may require stricter reduction. Semantic containment is checked only for a defined, supported policy language, not inferred from free text.

3. The Normative Envelope

The proposed envelope supports common indexing and signature verification. Authenticity is relative to a trusted key-to-principal binding. It does not establish observation truth, prevent an authorized signer from lying, or prove that a log has not been truncated.

Table 1: Universal Tuple Envelope Specification

3.1 Cryptographic Signing and Canonicalization

In v0.3.0, signature is normatively required for all governance interchange. Unsigned structures are forbidden from circulating as valid governance records and are quarantined to a segregated, non-normative schema (draft_tuple_fixture.json).

The original candidate proposed signing only the tuple with signature excluded. The revised candidate binds the algorithm and key identifier in a protected preimage as well, using RFC 8785 JCS [2]:

preimage = JCS({
  "domain": "hummbl.governance-tuple.signature.v0.3.0",
  "algorithm": signature.algorithm,
  "key_id": signature.key_id,
  "tuple": Tuple without the top-level signature field
})
signature.value = Sign(issuer_key, UTF8(preimage))

Verification MUST resolve key_id through an authorized trust configuration and match its allowed algorithm; an untrusted record cannot select arbitrary key material or downgrade verification. Unknown algorithms, duplicate JSON object keys, non-finite numbers, invalid strings, and values outside the agreed JCS input profile are rejected. Evidence hashes bind the referenced bytes, not merely a mutable URI. JCS determines serialization, not whether the payload is truthful [2].

The proposed initial suite is Ed25519. Signature encoding, key representation, and interoperability test vectors remain release blockers. ES256 and RSA-PSS-SHA256 were previously listed without parameter/encoding definitions and are deferred. The proposed preimage is a revision of this unreleased candidate, not a claim of byte compatibility with the archived PDF or existing HMAC records.

4. Core Tuple Taxonomy

The v0.3.0 core taxonomy defines six core tuple classes, each corresponding to a distinct proposed governance role:

================================================================================
CLASS       ROLE                             PRIMARY EMITTER
================================================================================
CONTRACT    Bounded task specification       Authorizing Principal / Orchestrator
DCT         Delegated Capability Token       Authorizing Principal / Delegator
DCTX        Lifecycle & DAG Context State    Orchestrator / Runtime Scheduler
SYSTEM      Control-plane enforcement gate   Reference Monitor / Policy Engine
EVIDENCE    Execution artifact receipt       Independent Execution Monitor
ATTEST      Formal evaluation & audit        Independent Verifier / Arbiter
================================================================================

4.1 CONTRACT (Bounded Work Definition)

The CONTRACT tuple establishes the task mandate, resource constraints, permitted tool boundaries, and dispute protocols before delegation or execution begins.

Table 2: CONTRACT Payload Specification (tuple_data)

4.2 DCT (Delegated Capability Token)

The DCT tuple encapsulates delegated authority. Rather than reinventing authorization cryptography, the DCT acts as a governance container that wraps versioned capability-token formats (e.g., UCAN, Biscuit, or Macaroons), with format-specific verification rules while binding them strictly to a governing CONTRACT.

Table 3: DCT Payload Specification (tuple_data)

4.3 DCTX (Delegation Context & Polycentric Lifecycle)

The DCTX tuple records state transitions within the delegation graph. The candidate permits DAG-shaped task dependencies and adds dispute and renegotiation states. Causal parents and authorization parents must be distinguished; a dependency edge is not itself an authority grant.

stateDiagram-v2
    [*] --> PROPOSED
    PROPOSED --> ISSUED: Required Approval Policy Satisfied
    ISSUED --> RUNNING: Reference Monitor Verification
    RUNNING --> EVIDENCE_READY: Execution Completed
    EVIDENCE_READY --> VERIFIED: ATTEST Pass

    RUNNING --> DISPUTED: Anomaly / Boundary Challenge
    DISPUTED --> RENEGOTIATING: Variance Requested
    RENEGOTIATING --> ISSUED: Amended Contract
    RENEGOTIATING --> CONTESTED_HALT: Consensus Failure

    RUNNING --> FAILED: Execution Error / Timeout
    RUNNING --> CONTESTED_HALT: Immediate Protective Halt

Table 4: DCTX Payload Specification (tuple_data)

4.3.1 DAG authorization semantics

For each task, a profile MUST separately identify causal dependencies and the authority grants relied on for execution. For a conjunctive, multi-parent authorization policy, define effective authority as $A_{eff}=\bigcap_{p\in P_{auth}} A_p$. Child authority MUST be contained in $A_{eff}$ and in the governing contract. For example, parents permitting {read, write} and {read, delete} jointly permit only {read} under this policy. Taking their union would silently grant authority that neither parent jointly approved.

Alternative policies that combine separately authorized resources require an explicit composition rule and per-operation proof selection. They must not infer a union from parent_task_ids. The candidate's current envelope does not yet encode that distinction completely (Section 7).

The DAG validator MUST reject cycles, unresolved authorization parents, conflicting duplicate task identities, and inconsistent contract/intent bindings. With root depth zero, task depth is one plus the maximum depth of its authorization parents and must not exceed a policy bound. Per-child budget containment is insufficient for shared quotas: two children each granted the parent's full remaining budget can overspend in aggregate. A host needs atomic reservations or a common consumption counter.

4.4 SYSTEM (Runtime Control and Audit Records)

SYSTEM tuples record the Reference Monitor's policy decisions and observations at declared runtime phases. An enforcing pre-execution gate can mediate an effect; AUDIT_ONLY records and POST_EXECUTION_CHECK observations do not establish that a gate prevented it. The mode, phase, monitor authority, and action binding determine what a record supports (Section 5, Invariant 5).

Table 5: SYSTEM Payload Specification (tuple_data)

4.5 EVIDENCE (Out-of-Band Execution Receipt)

The EVIDENCE tuple captures the raw execution telemetry, tool invocations, and output artifacts. In accordance with Invariant I-2, the emitter MUST be the Reference Monitor, distinguishing monitor observations from agent assertions. The monitor must label what it actually observed; a signed HTTP response does not prove that the remote service truthfully performed the claimed computation.

Table 6: EVIDENCE Payload Specification (tuple_data)

4.6 ATTEST (Independent Adjudication & Verification)

The ATTEST tuple records the findings of an independent verifier (human auditor, consensus committee, or specialized verification model) that evaluates EVIDENCE against CONTRACT requirements.

Table 7: ATTEST Payload Specification (tuple_data)

5. Lifecycle Invariants & Governance Rules

The candidate proposes seven lifecycle requirements. Their enforcement depends on a conforming implementation and deployment, and is not established by the schema tables:

Invariant 1: Contract Precedence & Threshold Activation

A DCT cannot be activated without referencing an active, unexpired CONTRACT. Where the contract requires multiple approvals, activation requires proofs from $m$ distinct principals in a policy-defined eligible set of size $n$. Each proof must bind the same immutable contract/grant digest, audience, expiry, and approval purpose. Multiple keys controlled by one principal do not automatically count as independent approvals. The proof format is not yet defined by this candidate.

Invariant 2: Complete Out-of-Band Mediation (Non-Self-Reporting)

An EVIDENCE tuple is rejected if its signer is not authorized as an independent monitor for the declared execution boundary. A key unequal to the agent's is necessary under this profile but not sufficient. All tool invocations and artifact commitments MUST be observed and signed by the Reference Monitor.

Invariant 3: Semantic and Syntactic Monotonic Attenuation

Let $A(T)$ represent the authority granted by token $T$, comprising tool sets $\mathcal{T}$, operation sets $\mathcal{O}$, and semantic objective scope $\mathcal{S}$. For any child delegation $T_{\text{child}}$ derived from $T_{\text{parent}}$:

$$\mathcal{T}_{\text{child}} \subseteq \mathcal{T}_{\text{parent}} \quad \land \quad \mathcal{O}_{\text{child}} \subseteq \mathcal{O}_{\text{parent}} \quad \land \quad \mathcal{S}_{\text{child}} \models \mathcal{S}_{\text{parent}}$$

Authority expansion is rejected by policy evaluation after signature verification; cryptography alone does not compute set or logical containment. The entailment symbol assumes a defined semantic language with a sound containment procedure. If constraints are unrestricted natural language or containment is unknown, the implementation must not declare the obligation proven; it must reject the automated grant or seek a separately authorized contract amendment. If an operational agent discovers that local task success requires capabilities outside $A(T_{\text{child}})$, it MUST initiate an explicit DISPUTE / RENEGOTIATING petition rather than attempting out-of-band escalation.

Invariant 4: Freshness Challenge & Replay Defense

This candidate treats a DCT presentation as single-use: it binds a unique nonce, authenticated subject, audience, and validity interval. The audience atomically reserves (dct_id, nonce) before a side effect and durably records its disposition. A duplicate is denied or returns the existing idempotent result; it need not halt unrelated tasks. Multiple replicas require a shared consistency mechanism, and restart must not erase consumed nonces before expiry. Reusable grants need separate per-invocation nonces and signed request binding, which this wire format does not yet define. A nonce alone does not supply freshness, ordering, or crash-safe exactly-once execution.

Invariant 5: Synchronous Pre-Execution Interception Barrier

State transition from ISSUED to RUNNING in a DCTX record requires an accompanying SYSTEM tuple with decision: "PERMITTED" and barrier_phase: "PRE_EXECUTION_GATE". The record must come from an authorized enforcing monitor and bind the exact action, task, contract revision, and DCT before the effect. AUDIT_ONLY and post-execution observations cannot satisfy this requirement. Execution cannot commence asynchronously prior to policy enforcement; unavailable or unresolved policy inputs must not become permission.

Invariant 6: Evidentiary Closure Before Attestation

An ATTEST tuple cannot be accepted without referencing retained, validly signed EVIDENCE for the same task, intent, contract revision, and authority grant. A PASS requires the contract's evidence requirements and required checks to be satisfied; an evidence object's mere existence is insufficient. WAIVED records an authorized exception, not successful verification, and must identify the waiver authority and failed/omitted checks.

Invariant 7: Polycentric Contestation & Graduated Sanctions

A dispute does not grant permission to continue a prohibited action. The monitor immediately denies or contains the affected side effect according to incident policy; emergency protection does not wait for consensus. Where safe, the subsequent resolution workflow is:

1. The monitor records DISPUTED while preserving the protective block or halt;
2. A formal DISPUTE tuple is emitted, identifying the conflicting invariants;
3. The delegator and delegatee enter a bounded RENEGOTIATING window;
4. If agreement is reached, an amended contract is signed; if irreconcilable, a coordinated CONTESTED_HALT is safely executed.

6. Composition With Related Standards

Typed Governance Tuples do not replace existing standards in identity, authorization, tracing, or attestation. Rather, the tuple envelope functions as the overarching governance binding plane that cross-links these heterogeneous primitives into a unified audit graph.

These are proposed integration points, not tested interoperability claims. Each binding needs a format version, semantic mapping, identity trust policy, and positive/negative conformance fixtures.

7. Implementation & Verification Suite

7.1 Available evidence

The public governance-tuple-reference repository [5], inspected at commit 5538bfadd52dd5557b4e42732d9787f7e36dadf5, contains HMAC-based delegation tokens, context and bus modules, a synthetic log, and a hash-chain verifier. It is evidence for an earlier implementation design, not for every requirement proposed here. A code inventory at that commit does not contain the claimed schema/v0.3.0/, semantic_validator.py, or monitors/ebpf_proxy/ paths. This manuscript directory also does not bundle them. No private deployment is independently audited by this revision.

Accordingly, the prior statements that a complete JCS/Ed25519 DAG validator and eBPF reference monitor already implement v0.3.0 are withdrawn pending a version-bound artifact and test transcript. Checking a supplied chain is not a proof that all real actions were captured.

7.2 Conformance release blockers

The presence of previous_hash detects changes relative to a trusted predecessor/checkpoint; an attacker able to replace the entire unanchored chain can recompute it. A checkpoint stored only inside the same rewritable log is not an independent anchor. RFC 9162 [3] supplies relevant transparency concepts, but referencing a Merkle root field does not implement its inclusion/consistency protocol.

7.3 Evaluation plan and limitations

A future evaluation should publish valid and invalid fixture corpora and per-check outcomes, distinguish signature/schema acceptance from actual prevention, and test monitor crashes, concurrent invocations, revoked ancestors, replay after restart, partial evidence loss, and bypass attempts. Overhead measurements need hardware, software versions, workload, repetitions, and latency distributions. No overhead or attack-success measurements are reported here.

Complete mediation is an assumption to establish at a host boundary, not a property inferred from signed logs. A compromised monitor or signing key defeats its assertions. Confidentiality, denial of service, malicious remote tool behavior, verifier bias, and key compromise remain residual risks. The RATS architecture distinguishes evidence appraisal and relying-party decisions [4]; this proposal likewise separates observation, verification, and permission. It does not prove alignment or legal non-repudiation.

8. Revision History & Audit Traceability

Historical design changes attributed to an ARCANA lens review

These labels describe an internal review method; they do not mean the named thinkers authored, endorsed, or independently reviewed this paper. The list records design intent, not completion of an implementation or proof. The 2026-10-10 revision above narrows earlier claims accordingly.

1. Threat Model Formalization (Schneier P1.4, Bostrom P2): Introduced Section 2, defining explicit adversary classes, trust boundaries, and physical execution assumptions.
2. Monitor-origin evidence requirement (Schneier P1.2, Foucault P2, Bostrom P2): Mandated Invariant I-2; EVIDENCE tuples must be generated and signed exclusively by an out-of-band Reference Monitor.
3. Declared mediation boundary (Schneier P1.1, Foucault P1, Ostrom P2, Bostrom P2, Hayek P2): Re-scoped claims and established Invariant I-1 (Complete Mediation) at the sandbox/proxy boundary.
4. Mandatory Signatures in Envelope (Schneier P2.3, Foucault P2, Ostrom P3, Bostrom P3): Made signature mandatory across all normative records; relegated unsigned fixtures to a segregated testing schema.
5. Polycentric DAG Delegation (Ostrom P2.1, Hayek P2.4, Bostrom P2.3): Replaced single-parent tree restriction with parent_task_ids array, supporting DAG topologies and $m$-of-$n$ threshold signatures.
6. Contestability & Graduated Sanctions (Ostrom P2.3/P2.5, Foucault P3): Introduced DISPUTED and RENEGOTIATING states into the DCTX lifecycle to prevent catastrophic uncoordinated halts.
7. Semantic Objective Containment (Bostrom P1.1, Hayek P1.1): Added formal semantic bounds to CONTRACT payloads as a proposed containment obligation; unrestricted goal drift is not proven absent.
8. Replay & Freshness Defense (Schneier P2.7): Added mandatory cryptographic nonce and audience fields to DCT grants.

9. References

[1] Bradner, S. (1997). Key words for use in RFCs to Indicate Requirement Levels. RFC 2119. https://www.rfc-editor.org/rfc/rfc2119

[2] Rundgren, A., Jordan, B., and Erdtman, S. (2020). JSON Canonicalization Scheme (JCS). RFC 8785. https://www.rfc-editor.org/rfc/rfc8785

[3] Laurie, B., Messeri, E., and Stradling, R. (2021). Certificate Transparency Version 2.0. RFC 9162. https://www.rfc-editor.org/rfc/rfc9162

[4] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and Pan, W. (2023). Remote ATtestation procedureS (RATS) Architecture. RFC 9334. https://www.rfc-editor.org/rfc/rfc9334

[5] HUMMBL. Governance Tuple Reference Implementation, inspected commit 5538bfadd52dd5557b4e42732d9787f7e36dadf5. https://github.com/hummbl-io/governance-tuple-reference/tree/5538bfadd52dd5557b4e42732d9787f7e36dadf5

[6] UCAN Working Group. UCAN specification. https://ucan.xyz/specification/ (accessed 2026-10-10). Capability validation remains the wrapped format's responsibility.

[7] SPIFFE. SPIFFE Overview. https://spiffe.io/docs/latest/spiffe-about/overview/ (accessed 2026-10-10). Workload identity does not itself specify task authorization.