Polymodum: An Open Protocol and Verification Network for Policy-Bound AI Agents§

Implementation-aligned working paper, v0.9

Abstract§

AI agents invoke models, software tools, databases, communication systems, and financial services. Conventional audit logs record what an operator claims occurred, but do not by themselves identify the governing policy, establish that authorization preceded execution, or allow another party to reproduce the decision. Polymodum is an open protocol and verification network for exchanging independently verifiable evidence that AI-agent execution traces conformed to cryptographically identified, machine-checkable policies under explicitly stated enforcement and trust assumptions. An agent signs an action request. A deterministic gateway evaluates an immutable policy and signs a permit or denial. A permit creates a short-lived, one-use capability bound to the exact action and a bounded reservation. Only a controlled adapter may consume it. Decisions and outcomes become signed receipts in an ordered chain. Receipt batches are committed by a Merkle root and may be anchored in Bitcoin. Signed node manifests and fresh challenge-response handshakes allow independently deployed nodes to authenticate one another without a central registry. A portable proof bundle permits local verification without the gateway database or an official explorer. The protocol does not prove internal model reasoning, trace completeness, host integrity, external metering, or real-world truth.

1. Introduction§

An autonomous system can be evaluated at three levels: what it reasoned, what it requested, and what it was able to do. Internal reasoning may be unavailable or non-deterministic. A signed request establishes intent but no effect. The operationally decisive boundary is the point at which an agent acquires authority to create an external effect.

A post-execution statement of compliance is weak evidence. An agent may omit actions, alter a trace, or submit a compliant-looking record after bypassing the intended control. Stronger evidence requires complete mediation for the protected path: credentials and side-effecting endpoints are unavailable except through an enforcement boundary that evaluates policy before execution and issues authority only for the exact permitted action.

Proof of Work and blockchain Proof of Stake determine which ledger history a distributed network accepts. Smart contracts apply deterministic state transitions within that history. Polymodum serves a different purpose. It produces evidence that a particular disclosed agent action was evaluated and mediated under a particular policy. It is not a consensus mechanism, does not require a custom blockchain, and introduces no native token in the Genesis profile.

2. Problem Definition§

Let a policy be P, a signed action request be A, the policy state before evaluation be S, and the deterministic transition be

Evaluate(P, A, S) -> (decision, S').

A verifier should be able to establish that:

1. P has a stable cryptographic identity and an authorized issuer;
2. A was signed by the stated agent key;
3. a signed decision is bound to P, A, and the relevant state limits;
4. a permitted effect required a one-use capability issued before execution;
5. disclosed usage did not exceed the signed reservation;
6. receipts form the disclosed order;
7. a target receipt is included in a signed Merkle batch;
8. the batch root is bound to a stated public commitment; and
9. the disclosed checks can be repeated locally.

The verifier cannot infer trace completeness merely because every disclosed entry is valid. It also cannot infer that the enforcement host was uncompromised or that an external provider reported usage honestly. These remain explicit assumptions.

3. Related Work and Scope of Contribution§

The term Proof of Policy predates this work and has been used for an attribute-based blockchain consensus protocol [7] and later security analysis [8]. Policy enforcement, capability systems, signed authorization decisions, execution receipts, append-only logs, Merkle trees, content addressing, Bitcoin commitments, and machine settlement are established ideas.

Recent agent-governance systems overlap substantially with the present problem. AgentBound evaluates actions before execution using delegated authorization, owner constitutions, and site contracts, and emits replay-verifiable governance receipts [9]. The Agent Passport System specifies cryptographic agent identity, monotonic authority attenuation, revocation, policy chains, and signed enforcement evidence [10]. ACTA defines portable signed decision receipts with offline verification [11]. XAIP specifies a tool-system-agnostic execution-receipt wire format [12]. AgentROA places signed authorization and execution evidence at an external capability boundary [13]. AgentLedger’s Proof-of-Behavior draft specifies a pre-execution policy gate and hash-linked signed receipts [14]. LedgerAgent maintains structured task state and checks state-dependent policy before environment-changing tool calls [15]. EMILIA composes heterogeneous authorization evidence into an offline verdict and separately specifies exact-action human authorization receipts [16, 19]. Notarized Agents shifts receipt signing to the receiving service and publishes confidential evidence through a witness-cosigned log [17]. VET composes TEEs, succinct proofs, and web proofs to authenticate agent outputs independently of the host [18]. The Internet-Draft references are works in progress, not IETF standards.

Polymodum therefore does not claim invention of policy enforcement, signed authorization or execution receipts, content-addressed storage, Merkle trees, Bitcoin anchoring, or machine settlement. Its contribution is a production-oriented interoperability and network profile that binds canonical policy artifacts, pre-execution decisions, one-use capabilities, execution evidence, content-addressed distribution, cross-operator verification, Merkle aggregation, and public commitments into portable proof bundles. It also defines signed node manifests, direct peer authentication, public conformance vectors, compatibility rules, and a progressive path from one independently deployable node to a multi-operator network. Productionization is a systems contribution, not by itself proof of scientific novelty.

4. System and Threat Model§

The principal components are an agent, policy issuer, enforcement gateway, controlled executor, evidence store, batch producer, public anchor, remote verifier, and optionally an independent node operator. The agent and its language model are not trusted to enforce policy on themselves. The gateway is trusted to mediate the declared protected path unless stronger attestation is present. The executor must reject calls that lack valid capability evidence.

The adversary may forge or modify policies, actions, decisions, receipts, manifests, handshakes, or Merkle paths; replay permits; substitute parameters; exploit expired authority; omit trace entries; manipulate clocks or usage data; publish incorrect content for a claimed identifier; or bypass the gateway through an unprotected route. Cryptographic verification detects many forms of artifact substitution and replay. It does not detect a bypass that was never observed by the declared enforcement boundary.

5. Canonical Policies and Identity§

A policy is an immutable, versioned document containing an issuer, allowed and denied capabilities, endpoint and recipient restrictions, resource limits, logging and privacy rules, enforcement and failure modes, expiry, revocation information, and optional ancestry. Modification produces a new policy identifier.

The Genesis implementation uses a restricted deterministic JSON profile. Strings and keys are normalized to Unicode NFC; object keys are sorted; floating-point values are forbidden; decimals are represented as strings or integer micro-units; and UTF-8 is emitted without insignificant whitespace. For canonical policy payload C(P) and domain D_policy,

policy_id = SHA256(D_policy || 0x00 || C(P)).

The issuer signs the canonical policy under Ed25519. The policy ID establishes content identity; the signature establishes authorization relative to an independently trusted issuer key. Neither operation establishes that the policy is socially desirable.

Policies may be published through IPFS or another content-addressed store. Integrity derives from the verified bytes and digest, not trust in a public gateway. Private policy values need not be publicly published when a profile supports selective disclosure.

6. Authorization and Enforcement§

An action envelope contains an action ID, agent ID, run ID, action sequence, nonce, policy ID, tool identifier, parameter and input commitments, policy-relevant context, a maximum resource request, issuance time, and expiry. The agent signs the complete envelope.

The gateway verifies signature, schema, policy status, nonce, sequence, expiry, and current state. It then applies a deterministic, side-effect-free policy function. The first semantics, bounded-email-v1, checks capability, destination, attachment count, input and output tokens, cost, runtime, tool-call count, policy expiry, and remaining budget.

A denial is signed and produces a denial receipt before any provider side effect. A permit atomically reserves declared maximum resources, consumes the nonce, and issues a signed capability bound to the action hash, decision ID, agent, run, tool, parameter commitment, reservation, nonce, protocol version, and expiry. The capability is usable once.

Protected providers must reject requests without a valid capability. The reference draft provider exposes only email.create_draft; the network profile also contains a bounded one-message exchange adapter for separated-node testing. Real deployments must isolate credentials and network routes so the agent cannot call the underlying provider directly.

7. Execution Receipts and Evidence§

The controlled executor verifies the capability, performs the operation, measures disclosed usage, and signs an attestation. The gateway checks exact request binding and that actual usage does not exceed the reservation. Unused capacity is returned and a signed receipt is emitted.

A permit that is never executed can be cancelled, returning the reservation and producing a cancellation receipt. Each admitted request ends as

deny    -> signed denial and denial receipt, no capability;
execute -> signed execution evidence and settled receipt;
cancel  -> invalidated capability and cancellation receipt.

For canonical unsigned receipt body R,

receipt_id = SHA256(D_receipt || 0x00 || C(R)).

Each run receipt references the preceding receipt, while a separate monotonic log sequence orders receipts across runs. Sensitive inputs and outputs are not public by default. Salted commitments support selective disclosure; unsalted hashes of predictable content must not be treated as private.

8. Portable Proof Bundles§

A portable proof bundle embeds or references the signed policy, content location, target action, decision, optional capability, optional executor attestation, receipt, disclosed trace, Merkle proof, signed batch header, anchor state, node manifests, and explicit assumptions. Trust roots remain external. A bundle cannot make its own signer trusted merely by including that signer’s key.

The offline verifier recomputes canonical identifiers, verifies signatures, reproduces deterministic policy decisions, checks action, capability and provider bindings, validates resource transitions and receipt ordering, verifies Merkle inclusion, and checks anchor-payload binding. Results are reported per check, together with unverified operational assumptions. No single “safe” score is produced.

9. Merkle Aggregation and Bitcoin Anchoring§

Anchoring every action is inefficient. Signed receipt bytes become leaves using the Certificate Transparency history-tree construction [2]:

leaf   = SHA256(0x00 || canonical_signed_receipt)
parent = SHA256(0x01 || left || right).

Receipts are ordered by global sequence and grouped into contiguous batches. A signed header binds batch number, previous batch hash, tree size, first and last receipt sequence, root, time, and producer identity. An individual proof contains only its leaf index and logarithmic audit path.

The first public anchor profile uses Bitcoin. Policies and traces are not stored on-chain. A compact OP_RETURN payload contains protocol magic, version, commitment type, digest algorithm, and one SHA-256 digest. No bitcoin value is sent to the commitment: a wallet input funds the transaction, the remainder returns as change, and only the miner fee is consumed. Anchor state distinguishes pending, broadcast, mempool, included, reorganized, invalid, and unknown. Inclusion at a block height is not an exact legal timestamp. Strong offline consensus verification additionally requires an SPV proof or a trusted full-node view and reorganization handling.

10. Node Identity and Direct Peering§

Every node publishes a signed, expiring manifest containing a self-certifying node ID, operator declaration, supported protocol versions and profiles, service endpoints, software metadata, and public keys. A verifier checks the manifest digest, Ed25519 signature, node-ID binding, freshness, revocation state, and version compatibility.

Direct peering uses a fresh challenge containing both manifest digests, both node IDs, a random nonce, supported versions, and a short expiry. The responder selects a mutually supported version and signs the complete response. Successful verification establishes fresh key control and endpoint response. It does not establish legal identity, operator independence, software conformance, host integrity, or continuing availability.

The Genesis implementation persists peer evidence locally. Discovery by explorer, registry, DNS, IPFS collection, DHT, or gossip remains optional. Indexing is not permission to participate. The explorer displays the network; it does not own the network.

11. Cross-Operator Verification§

The first network application profile is bounded email. An outbound policy constrains recipient, count, forwarding, copies, attachments, body size, token use, cost, runtime, reply order, and required evidence. The receiver verifies the sender’s manifest, handshake, decision, action binding, receipt, and profile before applying its own inbound policy. A bounded reply follows the same path in the opposite direction.

Both parties retain independent proof bundles. Public interaction records contain node IDs, profile, action class, receipt commitments, verification state, batch and anchor references, and minimal timing metadata. Message bodies, prompts, addresses, attachments, credentials, and salts remain private by default.

Two separated deployments controlled by one operator demonstrate deployment separation, not independent-operator interoperability. The stronger “Genesis Network” designation requires separate operators, keys, infrastructure, local verification, and a signed bilateral interoperability report.

12. Bounded Resource Ownership§

A policy may allocate finite execution capacity. Before execution, the requested maximum is reserved; after execution, actual usage is consumed and the remainder returned. Delegation may transfer only existing authority and capacity. These rules improve cost predictability, bound token and tool consumption, and make resource transitions auditable.

This application-layer accounting may be described as bounded execution credits or policy stake, but it is not blockchain Proof of Stake. A token, market, or slashing economy is optional and outside the Genesis protocol core. The core requires deterministic accounting and authenticated state transitions.

13. Explorer, Conformance, and Implementation Diversity§

The explorer is a non-authoritative view over signed public evidence. Its index can be rebuilt from node manifests, bilateral interaction records, public anchor records, and conformance results. It does not issue protocol membership, define trust, or participate in proof verification. Operator independence, endpoint reachability, implementation independence, and runtime integrity are displayed as separate evidence dimensions rather than one score.

Public vectors cover canonicalization, policy hashing, signatures, action binding, permit expiry, replay rejection, resource transitions, receipt chaining, Merkle proofs, anchors, node manifests, handshakes, version negotiation, downgrade rejection, and proof portability. Conformance results are signed and bound to implementation version and source digest.

A second deployment of the reference code is not an independent implementation. Implementation diversity requires separately authored code that reproduces the public vectors and interoperates over the wire. Conformance establishes agreement with the tested profile, not general security or operator trustworthiness.

14. Formal Semantics§

The Lean companion models policy state, capabilities, remaining action, token, cost and runtime budgets, deterministic transitions, and accepted or rejected traces. The target theorem is: given canonical policy P and ordered disclosed trace T, if every transition in T is accepted by the versioned transition function, all defined invariants remain valid, and disclosed trace-integrity checks succeed, then T conforms to P under the stated enforcement assumptions.

Lean cannot establish that the trace is complete, the host uncompromised, external usage correct, or the real-world effect equal to the receipt. The present model also does not yet prove correspondence with the Python runtime. Shared transition vectors and differential testing are required before that stronger claim.

15. Reference Implementation and Production Architecture§

The reference implementation uses Python, FastAPI, Pydantic, SQLAlchemy, SQLite for reproducible local tests, PostgreSQL as the deployment target, local or Kubo content storage, local or Bitcoin Core anchoring, a controlled email adapter, a Python SDK, JSON Schemas, deterministic vectors, a conformance runner, Docker Compose, Helm definitions, and Lean source.

The local vertical slice demonstrates one permitted draft and one denied send. The separated-node profile demonstrates distinct keys and state, signed manifests, bilateral handshakes, bilateral proof verification, co-signed public interaction evidence, signed anchor evidence, and a rebuildable privacy-preserving explorer snapshot. It remains a single-operator test and is not independent-operator interoperability. Current release qualification still requires clean Compose execution with Kubo, Bitcoin Core regtest and PostgreSQL; migration and concurrency tests; Lean compilation; idempotent external-provider semantics; HSM or KMS key custody; SBOM and image provenance; and measured load tests.

16. Privacy and Future Extensions§

Public evidence is minimized. Private interaction content remains in local evidence vaults or encrypted attachments, while public objects use salted commitments and explicit retention policy. A later proof-provider interface may support zero-knowledge statements such as private allowlist membership or hidden budget compliance. Zero knowledge alone does not prove trace completeness, prevent gateway bypass, or attest host integrity.

Lightning may later settle storage, verification, anchoring, inference, execution, or audit services. It is not the consensus or trust layer. Other extensions include threshold witnesses, multiple explorers, independent verifiers, post-quantum signatures, policy-language adapters, reproducible runtime attestations, and decentralized discovery.

Recent results in coding theory, high-dimensional geometry, parallel repetition, circuit complexity, lattice problems, and extremal combinatorics motivate research on heterogeneous validators, repeated challenge rounds, narrow verifiable transitions, and correlated coalitions [20]. These are research directions, not security reductions for the present protocol.

17. Genesis Launch Participation Profile§

The pre-launch service accepts a portable proof bundle only after its signatures, receipt, Merkle inclusion and anchor evidence verify. Executed input and output token counts are reduced to one canonical public compute commitment. PostgreSQL assigns a monotonic sequence and enforces uniqueness by commitment hash and receipt. Proof bundles and verifier trust inputs are not stored in this public commitment table. This records verified disclosed compute expenditure; it is not economic token destruction.

Launch eligibility is a separate, fail-closed step. A participant must present one Ed25519 credential from an externally pinned issuer, bound to the exact agent, epoch and cutoff. The service enforces a configurable minimum verified token expenditure and durable uniqueness for credential ID, agent plus epoch, and commitment hash. This is a resource and issuer control against cheap identity multiplication, not proof of a unique human, organization, model, host or independent operator. Admission grants no token, allocation, payment or airdrop right.

The Genesis cutoff is 28 August 2026 at 12:00 CEST (1787911200000 milliseconds since the Unix epoch). Time windows are half-open: new participation is rejected at the exact cutoff. After cutoff, the admitted records are ordered by their persistent sequence. Each canonical Merkle leaf binds the compute commitment, admission credential ID, issuer, agent, epoch, cutoff and acceptance times. One immutable snapshot manifest records the root, tree size, first and last sequences, profile and cutoff; every participant can request an RFC 9162-style inclusion proof.

Approvers sign one canonical statement binding protocol version, snapshot profile, epoch, cutoff, complete snapshot hash, Merkle root, tree size and Bitcoin network. Approval succeeds only with the configured threshold of unique valid signatures from externally pinned keys. Multiple keys do not prove multiple independent operators; key custody and organizational independence remain governance evidence. The deployed profile permits regtest statements only and cannot broadcast a mainnet transaction. A future official mainnet Genesis anchor requires a separately authorized fee policy, fee UTXO, final-root ceremony and broadcast step. The commitment output carries no bitcoin value; a wallet input pays the miner fee and change returns to the wallet.

18. Experimental Direction: Compact Agent Relay§

Natural language is useful at the human boundary, but it may be unnecessarily verbose and ambiguous for repeated agent-to-agent coordination. A later Polymodum application could exchange compact canonical envelopes instead: typed intents, content commitments, policy references, bounded resource declarations, signatures, and receipt references. The claim is a design hypothesis, not a measured efficiency result; it requires benchmarks against ordinary language-based coordination.

The first proposed application is a relay in which one bounded message passes through a sequence of agents. Each hop verifies the incoming envelope, performs only the permitted transition, signs its own receipt, and forwards a new canonical envelope. Humans need not read every internal message to audit the flow. They can inspect the public schema and decoder, verify hashes and signatures, reproduce the disclosed transition checks, and selectively reveal human-readable content where policy allows.

Such a relay could make useful verified hops the source of a growing network graph. It does not by itself establish consensus, honest metering, useful work, operator independence, or Sybil resistance. General relay routing, compact envelope negotiation, human-verification tooling, efficiency measurements, and distribution rules are not implemented in Genesis alpha.3. The current bounded message exchange and portable proof bundle are only protocol building blocks for this direction.

19. Limitations§

Polymodum verifies disclosed boundaries and evidence, not intelligence, truth, morality, or alignment. A correctly verified harmful policy remains harmful. A valid receipt proves what the declared signer stated under the encoded protocol object; it does not prove hidden execution facts beyond the enforcement and attestation assumptions. Public anchoring increases tamper evidence but does not decentralize an otherwise centrally controlled deployment.

20. Conclusion§

Polymodum turns policy-bound agent execution into portable evidence. The agent may propose actions, but protected authority is issued only after deterministic evaluation of an immutable policy. Signed decisions, one-use capabilities, bounded reservations, executor attestations, receipts, ordered logs, Merkle aggregation, node authentication, and public commitments allow another party to verify the disclosed record without an official website. The result is deliberately narrower than proof of safe intelligence: it is evidence that a declared enforcement boundary applied a declared policy to a declared trace under declared assumptions.

References§

1. S. Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System,” 2008.
2. B. Laurie et al., “Certificate Transparency Version 2.0,” RFC 9162, 2021.
3. S. Josefsson and I. Liusvaara, “Edwards-Curve Digital Signature Algorithm,” RFC 8032, 2017.
4. A. Rundgren et al., “JSON Canonicalization Scheme,” RFC 8785, 2020.
5. J. Benet, “IPFS—Content Addressed, Versioned, P2P File System,” 2014.
6. G. C. Necula, “Proof-Carrying Code,” 1997.
7. R. Mythili and R. Venkataraman, “Proof of Policy (PoP): A New Attribute-Based Blockchain Consensus Protocol,” 2021.
8. S. Wang et al., “On Security of Proof-of-Policy (PoP) in the Execute-Order-Validate Blockchain Paradigm,” IEEE CNS, 2022.
9. A. Kaul, Q. Lan, and P. Gupta, “AgentBound: Verifiable Behavioral Governance for Autonomous AI Agents,” arXiv:2606.30970, 2026.
10. T. Pidlisnyi, “Agent Passport System,” Internet-Draft draft-pidlisnyi-aps-01, work in progress, 2026.
11. T. Farley, “Signed Decision Receipts for Machine-to-Machine Access Control,” Internet-Draft draft-farley-acta-signed-receipts-01, work in progress, 2026.
12. xkumakichi, “Signed Execution Receipts for AI Agent Tool Calls,” Internet-Draft draft-xkumakichi-xaip-receipts-00, work in progress, 2026.
13. J. Michalak, “Agent Route Origin Authorization,” Internet-Draft draft-nivalto-agentroa-route-authorization-01, work in progress, 2026.
14. J. Dembowski, “Proof-of-Behavior Protocol for Autonomous AI Agents,” Internet-Draft draft-dembowski-agentledger-proof-of-behavior-00, work in progress, 2026.
15. M. N. Uddin, A. Saeidi, E. Blanco, and C. Baral, “LedgerAgent: Structured State for Policy-Adherent Tool-Calling Agents,” arXiv:2606.20529, 2026.
16. I. Schrock, “Authorization Evidence Chains: Composing Heterogeneous Agent-Action Evidence,” Internet-Draft draft-schrock-ep-authorization-evidence-chain-04, work in progress, 2026.
17. J. Figuera, “Notarized Agents: Receiver-Attested Confidential Receipts for AI Agent Actions,” arXiv:2606.04193, 2026.
18. A. Grigor, C. Schroeder de Witt, S. Birnbach, and I. Martinovic, “VET Your Agent: Towards Host-Independent Autonomy via Verifiable Execution Traces,” arXiv:2512.15892, 2025.
19. I. Schrock, “Authorization Receipts for High-Risk Agent Actions,” Internet-Draft draft-schrock-ep-authorization-receipts-08, work in progress, 2026.
20. OpenAI, “Ten Advances in Mathematics and Theoretical Computer Science,” 2026.
21. L. de Moura and S. Ullrich, “The Lean 4 Theorem Prover and Programming Language,” 2021.