Computational Jurisprudence: Verifiable Law for Machine Societies

1. Introduction: The Collapse Argument

Three boundaries organized the security and governance of computing for fifty years, and all three are collapsing at once.

• The perimeter collapsed first.

Cloud, mobile, and API-driven architectures dissolved the network boundary; the industry’s answer—zero trust [1]—replaced where you are with who you are as the basis of authority.

• Identity is collapsing now.

Zero trust presumes a stable principal behind every credential. Autonomous agents break the presumption: they spawn sub-agents, delegate slices of their authority, hold and spend funds, and act on instructions synthesized from untrusted content. When an agent’s effective authority is the union of everything in its credential store, and its behavior is steerable by any text it reads, the mapping from principal to action that all of authorization theory presumes no longer exists. Prompt injection, today’s marquee vulnerability, is not new: it is the confused deputy problem [2] at civilizational scale—a deputy holding ambient authority, tricked into exercising it on an attacker’s behalf. Four decades of experience say that confused deputies are not fixed by inspecting inputs; they are fixed by removing ambient authority [3].

• Oversight is collapsing next.

Governance, risk, and compliance (GRC) as practiced is a documentation discipline: controls are described, sampled, and audited by humans on quarterly cycles. Agentic systems act on millisecond cycles. A compliance regime that verifies behavior months after the fact, by sampling, against prose policies, is not slow governance of machine societies—it is no governance at all. Meanwhile, AI-generated code is overwhelming the human capacity for review, eroding the last implicit control: that a person understood the system before it ran.

• The thesis.

These are not three problems but one. Each collapse has the same root cause—verification latency: the time between an action and the confirmation that the action was authorized and compliant. Human-latency verification of machine-speed action is a category error. The only stable fixed point is verification at the speed of action, which means:

Compliance must become a runtime, compositional, proof-carrying property of computation. We call the discipline that studies how to specify, prove, compose, and adjudicate such propertiescomputational jurisprudence.

The name is deliberate. Jurisprudence is not law enforcement; it is the theory of how norms are expressed, how authority is delegated and bounded, how violations are attributed, and how disputes are resolved. Machine societies need all four, and they need them as mechanism, not as prose.

• Why a synthesis.

No single literature owns this problem, and that is the problem. The mechanisms a normative substrate needs already exist, scattered across four research communities that rarely cite one another: object-capability security, which knows how to bound delegated authority; verifiable and proof-carrying computation, which knows how to make evidence portable and cheap to check; policy-as-code and computational law, which know how to make norms executable; and agentic AI and agentic payments, which are deploying autonomous authority-holders faster than any of the other three can respond. This article reviews the four literatures as one body of work, organized by the question each answers and the question each leaves open. It revises and extends a position paper by the author [4]; the synthesis, the comparative analysis of Section 2, and the measured results of Section 7 are new.

• Guiding questions.

The survey is organized around four research questions, which the four components of Definition 1 (Section 3) make precise:

RQ1. 

How can authority be delegated between autonomous agents so that its worst-case reach remains statically boundable and every exercise is locally verifiable? (Authority; Section 4)

RQ2. 

What mechanisms allow individual actions to carry machine-checkable evidence of norm conformance, at costs compatible with machine-speed transaction budgets? (Norms, evidence; Section 5)

RQ3. 

How can the privacy of delegation relationships be reconciled with the attribution that adjudication requires? (Dispute; Section 6)

RQ4. 

Which requirements of a runtime normative substrate does no surveyed line of work meet, alone or in combination—and what research agenda follows? (Section 8)

• Roadmap.

Section 2 states the scope and method of the survey, covers the four literatures, and compares them against the requirements of a normative substrate (Table 1). Section 3 defines computational jurisprudence. Section 4, Section 5 and Section 6 develop the three pillars of the synthesis—a delegation calculus, runtime compliance proofs, and sealed delegation chains with graduated attribution—each pillar an answer to one research question, assembled from the surveyed work and honest about what must still be built. Section 7 grounds the architecture in agentic payment protocols and reports first measurements. Section 8 states the open problems (RQ4), and Section 9 concludes.

2. Background and Scope of the Survey

2.1. Scope, Method, and Inclusion Criteria

The survey is integrative, not systematic, and the distinction is load-bearing. The literatures surveyed here span programming-language theory, applied cryptography, distributed-systems engineering, standards work, and legal informatics; their venues, terminologies, and evaluation cultures are mutually foreign, and no shared keyword vocabulary exists against which a PRISMA-style search protocol could be honestly executed. We therefore proceed by requirement decomposition: Definition 1 (Section 3) factors a normative substrate for machine societies into four components—norms (N), authority (A), evidence (E), and dispute (D)—and the corpus is selected as the union of the research lines that supply mechanism for at least one component.

Three inclusion criteria discipline the selection. A surveyed mechanism must (i) operate at runtime, on the decision path of individual actions, rather than at audit time; (ii) hold up under an explicit adversarial model, not merely under fault assumptions; and (iii) be designed for, or plausibly extensible to, operation across trust boundaries—between organizations that do not share an administrator. We include peer-reviewed work from 1966 to 2026, documentation of deployed systems where the system itself is the primary artifact (OPA [15], Zanzibar [17]), and standards documents where interfaces are crystallizing (GNAP [7], W3C Verifiable Credentials [20]). We exclude three adjacent bodies of work: AI alignment and model-behavior control, which governs a model’s dispositions rather than an agent’s authority; blockchain consensus per se, from which we borrow cost structures [23] but not global-replication architecture; and legal scholarship without mechanism, which diagnoses the accountability gap [24] but does not close it.

The four literatures that survive this filter are surveyed in Section 2.2, Section 2.3, Section 2.4 and Section 2.5; Table 1 compares them against the four components, and Section 2.6 states the synthesis gap that the remainder of the article addresses.

2.2. Object-Capability Security and Delegable Authorization

The oldest of the four literatures answers RQ1. Capabilities originate with Dennis and Van Horn [25] as unforgeable references that combine designation with authority; Saltzer and Schroeder [26] codified the least-privilege principle they serve; Levy [27] documents the hardware lineage. Hardy’s confused deputy [2] supplied the diagnosis that still organizes the field: a deputy holding ambient authority can be tricked into exercising it on behalf of a request that never carried the corresponding right, and no amount of input inspection repairs the decoupling. Miller’s object-capability model [3] restated the cure as a discipline: authority flows only by explicit grant, and reachability bounds authority.

A second strand made delegation deployable. SPKI/SDSI [6] and trust management [28] moved authorization from identity lookup to credential presentation; authorization logics [29] gave the reasoning tools; Macaroons [5] and their successor Biscuit tokens realized attenuation-on-delegation as caveats appended to a bearer token and verified offline. The web’s production stack evolved in parallel and more conservatively: OAuth 2.0 [30] scopes remain coarse, non-attenuable grants, and GNAP [7] is the IETF’s current attempt to renegotiate that interface. The agent era has re-energized the strand: South et al. [19] extend OAuth and OpenID Connect with authenticated, auditable delegation to AI agents; CaMeL [8] and FIDES [9] impose capability and information-flow discipline inside a single agent system and defeat prompt injection by construction rather than by classifier.

What the literature supplies: delegable, attenuable, locally verifiable authority—component (A), with the beginnings of (N) in caveat languages. What it lacks: formal semantics under which attenuation is provably monotone for expressive caveat languages (Section 4); portable evidence that an exercised authority also conformed to regulatory or contractual norms (E); and any attribution story beyond bearer-token anonymity or, at the other extreme, fully visible chains (D).

2.3. Verifiable Computation, Proof-Carrying Artifacts, and Zero-Knowledge Systems

The second literature answers RQ2’s evidence half. Its founding pattern is Necula and Lee’s proof-carrying code [10]—producer proves, consumer checks cheaply—generalized to authorization by proof-carrying authentication [31] and to outsourced computation by verifiable computing [32,33]. Zero-knowledge proofs [34] added the qualifier that makes the pattern usable over sensitive inputs; succinct arguments [11,35] and recursive composition [36] made proof size and verification time independent of statement size, at the price of heavy proving. The credential strand runs in parallel: delegatable anonymous credentials [12], randomizable BBS-style presentations [37], revocation via cryptographic accumulators [13,38,39,40,41], and practical identity systems built from them [42], with recent schemes adding fine-grained delegation management and chainable revocation [43]. Two further mechanisms complete the toolbox at opposite trust points: hardware attestation [14] buys cheap evidence by trusting a vendor, and optimistic fraud-proof schemes [23] buy cheap evidence by trusting economics. Applied to compliance, the machinery has so far been pointed at fixed financial predicates: zkFi [44] and the ZK-AML/KYC line [45] prove regulatory conformance of payments without disclosing their contents.

What the literature supplies: evidence (E) that is portable, adversarially checkable, and asymmetrically priced; exactly the cost structure a machine-speed substrate needs. What it lacks: norm semantics (a proof certifies a predicate; nothing in the proof system says which predicate a jurisdiction requires); delegation semantics (DAC tracing is all-or-nothing identity opening by a structural authority, not harm-anchored adjudication); and composition (each proof certifies one action; norms bind workflows, Section 5).

2.4. Policy-as-Code, Runtime GRC, and Computational Law

The third literature answers RQ2’s norms half. Policy-as-code matured from XACML through OPA [15], now the de-facto cloud-native policy engine, to formally grounded languages: Cedar [16] ships verification-guided authorization semantics, and Zanzibar [17] demonstrates relationship-based access control at planetary scale and five-nines consistency. These systems made norms executable, a real advance over prose GRC, but they share an architectural ceiling: a logically centralized policy decision point that must be trusted, must be reachable on every decision, and keeps the evidence of each decision inside its own trust domain. Runtime GRC tooling (posture management, SIEM) shares the ceiling from the monitoring side: post-hoc observation within one administrative estate. Computational law is the same ambition aimed at statutes and contracts: a four-decade lineage [18] of norm representation, normative multi-agent systems, and electronic institutions, joined by legal scholarship arguing that accountability must be designed into algorithmic systems [24].

What the literature supplies: machine-interpretable norms (N) with engine-checked decisions, and hard-won evidence about policy-language ergonomics. What it lacks: decisions that survive outside the engine’s trust domain (E), authority that attenuates as it delegates rather than being re-granted centrally (A), and an adversarial, cross-organizational dispute model (D); the engine’s log is a record, not an adjudication.

2.5. Agentic AI and Agentic Payment Protocols

The fourth literature is the forcing function. The harms of increasingly agentic systems were mapped early [22]; what has changed since is deployment: agents now hold credentials, spawn sub-agents, and spend money. Agentic payment protocols are the sharpest instance—x4021 revives HTTP 402 into a machine-native payment channel, and Google’s Agent Payments Protocol (AP2)2 layers mandates and verifiable intent over agent-initiated payments—and the identity substrate they will settle on is crystallizing in W3C Verifiable Credentials and DIDs [20] and IETF GNAP [7]. The empirical study seeding the case study of Section 7 hardened x402 in production form: middleware that redacts personal data from payment metadata and enforces declarative spending policies pre-execution, at machine-speed latency budgets [21].

What the literature supplies: the deployment surface, the requirements, and the urgency—live protocols whose interfaces are not yet frozen. What it lacks is, precisely, the other three literatures: authority in these stacks is scoped-token or wallet-ambient, evidence is a log entry or a statement line, and dispute is a chargeback modeled on human commerce.

2.6. Synthesis: The Gap No Literature Closes

Table 1 summarizes the survey against Definition 1. Read column-wise, the table is an assembly diagram: every component of a runtime normative substrate exists somewhere in mature form. Read row-wise, it is a gap statement: no surveyed line supplies more than two components, and the components interlock—evidence without delegable authority certifies actions nobody was entitled to perform; authority without attribution cannot support remedy; norms inside a central engine do not survive the trust boundaries that inter-organizational delegation must cross. The three pillars developed in Section 4, Section 5 and Section 6 are the assembly: each takes the mature mechanism of one literature and adds the interface the others require of it. That assembly is a synthesis with open problems—Section 8 names seven—but the survey’s central finding is that the gap is architectural, not technological: the parts exist; the discipline that composes them does not.

3. Computational Jurisprudence, Defined

Definition 1

(Computational jurisprudence). The study and engineering of normative order for autonomous computational actors, comprising:(N) machine-interpretablenorms(policies as formal, executable specifications);(A) authority(how permission to act is granted, delegated, attenuated, and revoked);(E) evidence(machine-checkable proof that actions conformed to norms); and(D) dispute(protocols that attribute violations to responsible parties and impose remedies, with minimal disclosure).

The four components map onto three architectural pillars. Authority (A) is Pillar I: a delegation calculus. Norms and evidence (N, E) are Pillar II: runtime compliance proofs. Dispute (D) is Pillar III: graduated attribution, together with the standards and institutional layer that makes remedies enforceable.

Two design commitments distinguish this program from adjacent work. First, security and performance are the same requirement, not a trade-off to be balanced: every mechanism below is chosen so that the honest path adds $O\left(1\right)$ local cost at exercise time and no round-trips on the decision path, while dishonest paths bear the cost of disputes. Second, privacy and accountability are reconciled cryptographically, not by policy: no component may depend on a ubiquitous audit log of who delegated what to whom, because such a log is both a surveillance instrument and the single most valuable attack target one could construct.

4. Pillar I: Toward a Delegation Calculus for Autonomous Agents

4.1. Ambient Authority Is the Vulnerability Class

Contemporary agent frameworks grant authority ambiently: the agent process holds API keys, wallet credentials, and OAuth tokens, and every instruction the model follows executes with the union of that authority. Under ambient authority, the security question “can this action be performed?” is decoupled from “did the request that triggered it carry the right to perform it?”—which is precisely Hardy’s confused deputy [2]. Input filtering (prompt-injection classifiers, content firewalls) attacks the symptom; the disease is architectural.

Object-capability (ocap) security [3,25] removes the disease by construction: authority exists only as unforgeable references (capabilities), a subject can exercise only the capabilities it has been explicitly handed, and the only way to obtain authority is to be granted it by someone who holds it. There is no ambient store to confuse a deputy into using. This diagnosis is beginning to be shared: CaMeL [8] defeats prompt injection by imposing capability discipline on a single agent system, and FIDES [9] does so with information-flow control. Our claim is the cross-domain generalization these systems stop short of: capabilities not as an intra-process discipline but as inter-organizational legal instruments—attenuable, revocable, attributable, and disputable across trust boundaries.

4.2. Monotone Attenuation and the Delegation Lattice

The property that makes ocap analyzable rather than merely safer is attenuation-on-delegation:

Property 1

(Monotone attenuation). If agent a delegates capability c to agent b, the authority conferred by the delegated capability $c^{\prime }$ satisfies $〚c^{\prime }〛\subseteq 〚c〛$: each hop may only narrow—never broaden—scope, budget, time window, or permissible counterparties.

A caution that motivates the calculus rather than substituting for it: Property 1 holds by construction only for caveat languages that are conjunctive and negation-free, where appending a caveat can only intersect the permitted set. Richer languages—negation, defaults, caveats whose satisfaction conditions interact—can silently break monotonicity, so that a syntactically “attenuated” token confers authority its parent never had. Characterizing the largest caveat languages for which monotonicity is preserved (or recovered by typing) is a core deliverable of Problem 4. Within the monotone fragment, the reachable authority of an entire multi-agent system forms a meet-semilattice ordered by delegation, and worst-case authority analysis reduces to reading caveats off root grants—a static, compositional bound of exactly the kind GRC frameworks assert in prose but can never verify. Practical instantiations already exist in embryo: Macaroons [5] and Biscuit tokens realize attenuation as appended caveats verified offline; SPKI/SDSI [6] and trust-management systems [28] supplied the authorization-logic groundwork [29]. What is missing—and what we name as the first work item of the field—is a delegation calculus: a formal system in which caveat languages have compositional semantics, attenuation is proved monotone by type-checking, and revocation and expiry are first-class, so that properties like “no reachable agent can spend more than $100/day outside jurisdiction J” are theorems, not aspirations.

4.3. The Performance Dividend

Capability verification is local: a verifier checks the token’s caveat chain against the requested action, with no call to a central policy decision point. Centralized-PDP architectures (XACML, and OPA [15] as commonly deployed) place a policy-engine round-trip on the hot path of every decision and a global availability dependency on the engine. The ocap discipline removes both. This is the paper’s recurring pattern: the architecture that is more secure is also the one with less coordination, because both security and performance degrade with every party you must trust and every party you must call. Section 7 puts numbers to this dividend.

5. Pillar II: Runtime Compliance Proofs

5.1. From Proof-Carrying Code to Proof-Carrying Transactions

Necula and Lee’s proof-carrying code [10] established a pattern of enduring value: the producer of an artifact bears the cost of constructing a proof of its safety; the consumer bears only the cost of checking it, which is small and fixed. Appel and Felten’s proof-carrying authentication [31] carried the pattern into authorization logics; what we propose is that lineage extended along four axes it lacked—attenuation semantics, zero-knowledge privacy, tiered assurance economics, and attribution—at the level of actions: a proof-carrying transaction (PCT) is an action request accompanied by a machine-checkable certificate that the action satisfies the applicable norm set—authorization (a valid attenuated capability chain, Pillar I), regulatory predicates (e.g., data-protection constraints on payloads), and contractual terms (e.g., SLA and budget caveats). Verification is again local and $O\left(\right|\mathrm{proof}\left|\right)$, independent of the policy corpus size.

5.2. The Three-Tier Evidence Regime

Insisting on maximal cryptographic assurance for every action would price the architecture out of existence. We instead borrow the cost structure that blockchain scaling discovered under adversarial economics [23] and propose three tiers, selected per action by value-at-risk:

1.

Attested compliance (cheap, hardware-trusting). The action executes inside a trusted execution environment whose remote attestation [14] covers a reference monitor enforcing the norm set. Evidence is an attestation quote. Appropriate for high-frequency, low-value actions; the residual trust is the hardware vendor’s key infrastructure (a systemic root risk if compromised) and a side-channel record that history counsels humility about—which is why tier assignment must be revisable and vendor attestation keys must be revocable objects within the same architecture.

2.

Optimistic compliance (cheap, trust-minimized). The actor posts a bond and asserts compliance; the assertion is presumed valid unless a fraud proof is submitted within a dispute window, in which case the bond is slashed and the dispute layer (Pillar III) engages. This tier is, to our knowledge, novel as a general compliance mechanism, and it is the workhorse: honest-path cost is a signature, and the deterrent is economic, exactly as in optimistic rollups. Its guarantee must, however, be scoped by observability: permissionless watchers can construct fraud proofs only for violations visible in the action and its public envelope (budget, scope, counterparty, and tier caveats checkable against the presented proof). Violations over sealed content—a purpose-limitation breach inside an encrypted payload—are not watcher-detectable and must instead be raised by the harmed party or an entitled regulator, whose dispute then drives the attribution machinery of Section 6. Optimistic compliance therefore deters observable deviation permissionlessly and unobservable deviation only as strongly as victims can detect harm; conflating the two would overclaim.

3.

Zero-knowledge compliance (expensive, trustless, private). The actor supplies a succinct proof that the action satisfies the norm predicate without revealing the inputs—appropriate when the evidence itself is sensitive (payloads containing personal data; competitive terms) or when finality must be immediate.

The tiering is itself governable: a norm may demand a minimum tier as one of its caveats, so assurance level becomes a delegated, attenuable quantity like any other.

5.3. The Composition Problem

The deepest technical obstacle in this pillar is that compliance does not compose. Agent A may provably satisfy purpose-limitation norm $\phi$ and agent B likewise, while the composite workflow $A\to B$ violates $\phi$ (e.g., each hop’s data use is individually permitted, but the join of their outputs re-identifies a data subject; or two individually-within-budget payments breach a joint cap). Formally, PCTs certify local predicates; norms are frequently hyperproperties of workflows. The nearest existing machinery is behavioral typing—multiparty session types and choreographies [46]—which types the protocol rather than the endpoints. We conjecture that a compliance choreography: a global norm compiled into per-participant local obligations whose satisfaction provably entails the global property, is the right object, and we flag its theory (Problem 1) as the field’s hardest open problem.

6. Pillar III: Sealed Delegation Chains and Graduated Attribution

6.1. The Tension

Pillars I–II have quietly created a conflict. Capability-based authority is bearer-like and private: verifying a caveat chain does not require knowing who the intermediate delegators were, and this privacy is a feature—delegation graphs are commercially and personally sensitive. But jurisprudence requires attribution: when harm occurs, remedy must attach to the responsible hop, not to a cloud of anonymous intermediaries. The naive resolution—log every delegation to an audit store—destroys the privacy property and erects the largest honeypot in the system. The requirement, stated precisely:

Attribution must be conditional (available only upon adjudicated dispute), minimal (revealing no hop beyond the violating one), and cryptographically gated (impossible for any party, including the adjudicator, to obtain outside due process).

We call the primitive that meets this requirement a sealed delegation chain, and the property it delivers graduated attribution.

6.2. Threat Model

We consider five adversary classes, any of which may collude except where noted: (T1) malicious delegators and presenters, who attempt to forge chains, broaden authority under the guise of attenuation, or exercise revoked links; (T2) curious verifiers and network observers, who attempt to learn chain membership or link repeated exercises; (T3) a colluding subset of the adjudication committee below the decryption threshold; (T4) abusive disputants, who attempt de-escrow without demonstrated harm; and (T5) a protocol-following but curious adjudicator. Trust assumptions: chains terminate in accountable roots (Section 6.4); the proof system is sound and zero-knowledge; accumulator state is agreed per epoch; at least a threshold of committee members is honest (an assumption we flag as the construction’s weakest and target for elimination in Problem 3).

The construction is designed to provide, informally: chain integrity (against T1: no accepting verifier for an action outside the monotone closure of an actually-issued, unrevoked chain); conditional anonymity (against T2, T3, T5: absent a valid dispute, no party learns hop identities beyond the existence of an accountable root, and exercises are pairwise unlinkable); attribution soundness (upon valid dispute, de-escrow identifies the violating hop, whose posted bond makes the remedy executable); and minimal disclosure (against T4, T5: de-escrow reveals no hop beyond the violating one, except via the one-hop-per-cause continuation rule below). Formalizing these as cryptographic games and proving the construction secure is deliberate future work; we state them here so the claims are falsifiable.

6.3. Construction

A sealed delegation chain layers four mechanisms onto the Pillar-I capability:

(1) Sealed chain commitments.

At each delegation hop i, the delegator appends a binding, hiding commitment ${\gamma }_i=\mathsf{Com}({\mathsf{id}}_i,{\kappa }_i,t_i)$ over its identity, the caveats added, and a timestamp; the capability carries only the running commitment root ${\rho }_i=H({\rho }_{i-1},{\gamma }_i)$. Identities never travel in the clear; the chain structure is committed but sealed.

(2) Recursive zero-knowledge authorization.

When the capability is exercised, the presenting agent supplies a succinct proof of the statement: “there exists a delegation chain from an accountable root to me, consistent with root ${\rho }_n$, monotonically attenuated, none of whose links is revoked, whose accumulated caveats permit this action.” Recursive proof composition [35,36] keeps the proof constant-size in chain depth. The cost asymmetry is the design’s engine: proving happens at delegation time; exercise time is $O\left(1\right)$ verification. No chain traversal, no directory lookup, no policy-engine call at exercise time—ever. Honesty about the prover: recursive proof generation costs hundreds of milliseconds per folding step, and seconds to produce a compressed constant-size proof, even on server-class hardware (Table 2); and “delegation is rare” fails precisely for orchestrators that spawn sub-agents per request. Delegation-time proving is therefore the construction’s bottleneck; mitigations—batched proving across sibling delegations, cached proofs for recurring sub-agent templates, and hardware proving—are engineering, but the asymmetry itself (the frequent path pays verification, not proving) is what makes the design viable, and we scope our performance claims to it.

(3) Graduated de-escrow.

Each hop’s identity opening is encrypted under a threshold scheme to an adjudication committee. Upon a valid dispute—a fraud proof from the optimistic tier, or an adjudicated claim of harm—decryption proceeds one hop at a time, backwards from the point of harm, halting at the first link whose caveats were violated. Liability attaches to that link; per-link bonds posted at delegation time make the remedy executable. Disclosure is minimal by construction: an onion peeled by due process. Where harm does not localize to a single hop (collusive multi-hop violations), the adjudicator may extend de-escrow by exactly one further hop per demonstrated cause—a de-escrow continuation rule that keeps disclosure proportionate to demonstrated culpability rather than pretending single-hop localization always holds.

(4) Accumulator revocation.

Revoked links are inserted into a cryptographic accumulator [38,39,40]; the exercise-time proof includes non-membership of every chain link. Revocation thus takes effect without certificate-revocation-list distribution or per-exercise status checks. We concede what this does not eliminate: each revocation invalidates outstanding non-membership witnesses, so provers must synchronize to the current accumulator epoch—a residual global coordination channel. Table 2 quantifies the channel: after a ${10}^4$-element batch revocation, updating each outstanding witness costs $\approx 2$ s of holder computation [13]; Section 7 reports our own measurement of the same operation. The honest characterization is not “no coordination” but a strictly better trade: coordination moves off the verification path (verifiers need only the epoch root), its frequency is set by revocation rate rather than exercise rate, and staleness is a tunable freshness parameter (epoch length) rather than a per-decision availability dependency.

6.4. Honest Limitations

Three weaknesses are intrinsic and should be stated rather than obscured.

Committee trust. Graduated de-escrow trusts a threshold committee not to collude. Rotation, distributed key generation, and legal liability for committee members are the practical mitigations; the principled endgame is witness encryption [48] keyed to the dispute event itself, under which decryption is mathematically impossible absent a valid fraud proof—no committee at all. Witness encryption remains impractical today, which is why it appears in our agenda (Problem 3) and not in our construction.

Accountable roots. Graduated attribution is only as good as the root it terminates in: if chains may originate from unaccountable (Sybil) identities, de-escrow reveals a burner. Chains must therefore terminate in credentials binding a legally accountable entity—which makes root registration the load-bearing interface between the cryptographic and legal systems, and a point of concentration that must itself be governed. We regard this not as a flaw of the design but as the honest residue of the problem: some link to legal personhood is irreducible if remedies are to be real.

Metadata linkability. Zero-knowledge presentation hides the chain, but a static capability handle would let observers link repeated exercises. Presentations must therefore be randomizable—BBS-style signatures [37] provide the standard technique—so that each exercise is unlinkable to the last.

7. Case Study: Hardening Agentic Payment Protocols

Agentic payment protocols—x402’s HTTP-native machine payments and Google’s Agent Payments Protocol (AP2) among them (Section 2.5)—are the first deployed systems in which autonomous agents hold and disburse funds against machine-negotiated terms, and they exhibit every pathology of Section 1 in miniature: ambient wallet authority, delegation by credential-copying, compliance by after-the-fact statement inspection, and personal data traversing payment flows with no enforced purpose limitation. The empirical seed of this program exists [21]: presidio-hardened-x402, open-source middleware that intercepts x402 payment requests before transmission, redacts personally identifiable information from the three metadata fields the protocol otherwise ships in plaintext to payment server and facilitator, enforces declarative spending policies, and blocks replay. On a labeled corpus of 2,000 metadata triples, the recommended configuration detects PII at micro-F1 $0.898$ with precision $0.972$, at a p99 latency of $5.73$ ms; pre-execution enforcement fits inside machine-speed payment budgets. The limits teach as much as the numbers: the middleware asserts compliance rather than proving it, must itself be trusted, and defends one boundary. Runtime enforcement without evidence, attribution, or composition—exactly the residue the three pillars remove.

Recast in the present architecture: the wallet root grants a capability attenuated by budget, merchant-category, jurisdiction, and data-minimization caveats (Pillar I); each payment is a proof-carrying transaction whose tier is selected by amount—attested for micro-payments, optimistic with bonded settlement for the mid-range, zero-knowledge where invoice contents are themselves sensitive (Pillar II); and the delegation chain from human principal through orchestrator to task agent is sealed, so that a fraudulent charge triggers de-escrow to exactly the hop that exceeded its caveats, whose bond compensates the victim (Pillar III). Governance properties that payment-industry compliance asserts on paper—spend limits, KYC boundaries, per-action purpose constraints—become runtime-checkable properties with a constant-time verification cost.

The remainder of this section reports first measurements of three of the architecture’s load-bearing cost claims: that capability verification is cheaper than a centralized policy decision point precisely where centralization hurts (E1, Section 7.1); that capability enforcement composed onto a live payment path fits inside machine-speed budgets end-to-end (E2, Section 7.2); and that accumulator-based revocation prices active recall off the verification path (E3, Section 7.3). All three experiments come from the article’s reproducibility harness (Section 7.4).

7.1. Measured: Local Capability Verification versus a Centralized PDP (E1)

E1 is a three-way comparison over one canonical, seeded workload: Biscuit (biscuit-auth, Rust, in-process), capability-grant@1 (a shipped Python capability artifact, benchmarked as-is), and OPA [15] as a centralized PDP evaluating an equivalent Rego policy over localhost, in local, +5 ms, and +20 ms configurations—the delay configurations inject one-way latency in front of the PDP with toxiproxy to model a remote decision point honestly. A single generator emits system-neutral delegation fixtures at chain depths $\{1,2,4,6,8,10\}$; each system materializes its own token, grant chain, or input document from the same fixture, so semantic equivalence is by construction, and a fail-closed correctness gate asserts identical ALLOW/DENY verdicts across all three systems before any timing begins. Each configuration runs ${10}^5$ exercises. One bias is disclosed because it matters: the Rego policy models the PDP decision and re-verifies no Ed25519 signatures, giving OPA strictly less work than the capability systems—the conservative direction, since the claim under test is round-trip and availability cost, not cryptographic speed.

Table 3 reads honestly in both directions. Both capability systems sit in the microsecond range and grow mildly with depth, while local OPA is sub-millisecond and roughly flat—and at depth 10 local OPA edges past Biscuit, which we report openly. The performance dividend claimed in Section 4 is the injected delay: the moment the PDP is remote, every decision pays the network, and a $+5$/$+20$ ms decision point costs milliseconds to tens of milliseconds per action—one to two orders of magnitude above the local capability path, plus an availability dependency the local path does not have. That is the round-trip cost the architecture removes, measured; it is not a claim of faster cryptography.

7.2. Measured: Capability-Enforced x402 Payments, End-to-End (E2)

E1 prices the primitive in isolation; E2 prices it where it must live. The experiment replays the labeled corpus of 2,000 payment-metadata triples of [21] through the full screening pipeline with a capability enforcer configured at chain depths $\{1,2,4,6\}$ (seeded grant chains), collecting the per-stage latency breakdown—redaction, capability verify, evidence write—as p50/p99. The added latency (verify plus evidence write) is the cost the capability stage composes on top of the published $5.73$ ms p99 redaction-only baseline, which is cited, not re-derived; the reported curve is the worst-case per-call-verification posture. A separate 50-case crafted violation set (over-budget, out-of-prefix, expired, broadened-child, replayed) drives a detection table—counts of blocked, evidence-emitted, and signed-decision-record outcomes per class—rather than an accuracy score.

Table 4 gives the composition: the capability check and evidence write together add $0.52$ ms p99 at depth 1, rising with depth as the per-call verify cost grows, to $1.45$ ms p99 at depth 6—an order of magnitude below the redaction baseline they compose with, and comfortably inside the payment-path budget the prior release established. Table 5 gives the enforcement side: every crafted violation is blocked with evidence emitted, and the replayed class shows zero signed capability decision records because the replay gate fires before the capability stage, which the table records truthfully rather than papering over. Together the two tables state the case study’s claim in measured form: runtime capability enforcement on a deployed agentic-payment protocol costs about half a millisecond per payment at realistic depths, and it blocks by construction the violation classes that documentation-based compliance only samples for.

7.3. Measured: The Price of Active Revocation (E3)

Pillar III’s revocation story (Section 6) rests on cryptographic accumulators, and Table 2 prices them only from the literature. E3 measures the primitive directly: vb_accumulator [49], a pairing-based universal accumulator over BLS12-381 with non-membership witnesses and batched witness update via a published $\Omega$ vector, benchmarked single-core, with every timed operation verified against the post-revocation accumulator state before it is timed. Base operations over a $2\times {10}^4$-member state: non-membership witness generation 0.55 ms; verification of the 80-byte witness 1.03 ms, a constant-size pairing check independent of revocation history.

Table 6 quantifies the coordination channel that Section 6 concedes. The costs land where the design puts them: the verifier pays a constant pairing check regardless of revocation volume; the holder pays to fold a batch revocation into its witness (82 ms at $B={10}^4$); and the expensive term, the manager’s $2.6$ s $\Omega$ publication at $B={10}^4$, is computed once per epoch, amortized across every holder, and consistent with the single-core $2.1$ s Vitto–Biryukov figure for the same batch size in Table 2. Revocation coordination is real, but it scales with revocation rate, not exercise rate, and none of it touches the verification path—which is the claim the measurement was designed to test.

7.4. Provenance

All numbers in Section 7.1, Section 7.2 and Section 7.3 were produced on the reference platform: Apple M4 Mac mini (4P+6E), macOS/aarch64, CPython 3.11.15, OPA 1.18.2, rustc 1.96.1, with the remote-PDP delay injected by toxiproxy. Exercise counts and seeds are recorded in every result row (${10}^5$ exercises per E1 configuration; the full 2,000-triple corpus per E2 depth); tables are generated from the committed CSVs by a single script; the official run is tagged in the reproducibility harness (Data Availability Statement). The numbers characterize single-machine shape, not a distributed production deployment; the E1 comparison is deliberately biased in OPA’s favor; and the E2 baseline is composed, not re-measured. What remains unmeasured is scoped in Section 8: delegation-time proving under orchestrator fan-out, and the dispute path—fraud-proof construction, de-escrow latency in committee rounds, and bonded capital per unit of payment volume.

8. Open Problems and Research Agenda

The synthesis of Section 2, Section 3, Section 4, Section 5, Section 6 and Section 7 leaves a residue that no surveyed literature covers; we state it as seven open problems. Together they answer RQ4: what separates the assembled state of the art from a deployable normative substrate.

Problem 1

(Compositional compliance: trace properties). Develop a theory ofcompliance choreographies: compilation of global norms expressible as trace properties of workflows (ordering, budget-respecting protocols, mandated interaction patterns) into local, proof-carrying obligations whose satisfaction provably entails the global norm. Candidate foundation: multiparty session types and choreographic programming [46].

Problem 2

(Compositional compliance: hyperproperties). Many norms that matter—re-identification bounds, joint caps across concurrent chains, non-discrimination—arehyperproperties [50], relating sets of traces, and are outside the reach of choreographic decomposition. Their enforcement needs information-flow and quantitative type systems, and their proof-carrying form is open even in principle; we regard this as the field’s hardest problem and flag known undecidability boundaries as the place to start.

Problem 3

(Witness-encrypted de-escrow). Replace the threshold committee of Section 6 with witness encryption keyed to adjudication events, eliminating trusted parties from attribution. Requires either practical general witness encryption or special-purpose constructions for the fraud-proof relation.

Problem 4

(The delegation calculus). A core calculus with caveat languages as first-class citizens, monotone attenuation by typing, revocation semantics, and decidable authority-bound queries; mechanized metatheory.

Problem 5

(Accountable roots without concentration). Root registration binds cryptographic chains to legal persons (Section 6.4); design registration ecosystems that avoid re-centralizing the very authority the architecture distributes.

Problem 6

(Norm engineering). Regulatory and contractual norms are drafted in natural language; compiling them to enforceable predicates is today artisanal. Develop verified norm-compilation toolchains and, critically, the discipline of writing law amenable to compilation.

Problem 7

(Economic calibration). Optimistic compliance is sound only if bonds, dispute windows, and watcher incentives are calibrated to attacker economics; this is mechanism design under adversarial, high-frequency conditions.

• Standardization pathway.

The protocols this program must inhabit are crystallizing now—W3C verifiable credentials [20], IETF GNAP [7], and the agentic-payment stack (x402, AP2). A field that waits for its theory to complete will find the interfaces frozen without it. We therefore advocate a dual-track posture: theory and artifacts in the research track; caveat formats, proof envelopes, and dispute interfaces contributed to standards bodies in parallel. Our own standards engagement proceeds through IEEE SA.

9. Conclusions

The governance of computation is about to pass from documents to mechanisms, for the same reason navigation passed from stars to instruments: the required precision exceeded unaided human faculties. This article has traced four literatures—object-capability security, verifiable and proof-carrying computation, policy-as-code, and agentic systems—to a common gap, and has argued that the transition through that gap has a coherent shape: authority as attenuable capabilities, compliance as portable proofs, attribution as graduated disclosure. It has a name: computational jurisprudence. The open problems are hard, the standards windows are short, and the alternative to building this field deliberately is inheriting its absence as infrastructure. We invite the community to treat verifiable law for machine societies not as metaphor but as the systems, theory, and standards program it must become.