PaperlayerView exact revision on arXiv

Source-linked AI summary

Provable Authority: A Protocol for Verifiable Authority Resolution and Control Across Human, Organizational, and Agentic Transactions

Jeremy Blackburn, Tim Hines, Matthew Koepp, Russell Lessard, Jason Patrick

arXiv:2610.22899v1cs.CRcs.MA

TL;DR

Relying parties generally lack compact, independently verifiable evidence that an exact transaction is currently authorized under applicable authority, evidence, policy, budget, and approval state. The paper proposes a subject- and rail-neutral pre-execution control plane that binds decisions to transactions and governs execution. It also states that the design does not guarantee fraud-proof operation or instantaneous revocation everywhere.

  • Problem

    Relying parties generally cannot independently verify that a party presenting an exact transaction has current organizational authority under applicable evidence, policy, budget, and approval state.

    Source: Executive Summary · p. 9

  • Method

    The protocol links identity, organizational authority, sourced evidence, reason-coded policy predicates, transaction binding, capacity reservation, EAC-gated execution, and lifecycle evidence.

    Source: Executive Summary · p. 9, §2.5 · p. 15

  • Results

    The protocol supplies a structured answer connecting identity, authority, evidence, policy, transaction semantics, approval, execution, and outcome evidence.

    Source: §10 · p. 30

  • Takeaways & Limitations

    For agentic use, the Agent Subject Profile keeps AI outside unrestricted private-key and final execution control while allowing agents to propose and coordinate economic activity.

    Source: §10 · p. 30

    The design is not fraud-proof, non-spoofable, unstealable, tamper-proof, or instantaneously revoked everywhere.

    Source: §7.3 · p. 27

Abstract

from arXiv · show

Payment systems authenticate users, devices, accounts, and cryptographic credentials, but a relying party, such as a counterparty, payment rail, marketplace, or autonomous agent runtime, generally cannot obtain compact, independently verifiable evidence that the party presenting one exact transaction holds current organizational authority to execute it under the applicable evidence, policy, budget, and approval state. Agentic commerce makes this gap operationally urgent: a software agent can produce a valid signature while acting outside its delegated purpose, after its sponsor's authority has changed, or on transaction details that differ from those a human approved. We describe the ChainIT Authority Protocol, a subject-neutral and rail-neutral pre-execution authority and evidence control plane. The protocol separates durable identity, a versioned organizational authority record (the Authority Resolution Pactvera), sourced evidence assertions, deterministic reason-coded policy predicates, and organization-configured dispositions; binds each decision and human approval to a canonical transaction digest; reserves capacity atomically so that limits hold under concurrency; and authorizes commit only through a single-use, sender-constrained Execution Authorization Credential consumed at the rail adapter, with append-only lifecycle evidence sealed after the terminal outcome. An Agent Subject Profile adds the workload registration, attested key hierarchy, and sovereignty boundary required when the acting subject is an AI agent, without introducing a separate authority concept. We specify the commit-time execution predicate and bounded-freshness status rules, give enforcement profiles for fiat (ACH, wire, card, instant payment) and stablecoin rails, and state residual risks and non-goals.

Definitions

The Authority Protocol resolves authority for a specific action across subjects and payment rails, while the Agent Subject Profile adds workload identity and containment controls. Its records distinguish organizational authority, sourced evidence, policy evaluation, transaction-specific decisions, and execution.

Agent controls

  • The Agent Subject Profile adds workload registration, an attested key hierarchy, and a sovereignty boundary; delegated agent authority remains grounded in the ARP.An Agent Authority VDT records the grant and its bounds, while present validity is checked against current ARP status; session credentials cannot authorize payment.Source: Definitions · pp. 5, 7, 8

Core authority concepts

  • The Authority Protocol applies across subject classes and payment rails; the ARP records who may act, for what purpose, within which limits, and under what conditions.A subject may be an individual, group, organization, or permitted agent; scheduled workflows act on an organization's behalf.Source: Definitions · pp. 5, 7

Policy and decisions

  • The BRE evaluates configured predicates and returns reason-coded results, while the organization-configured Workflow Engine maps them to a disposition.The Authority Policy Profile specifies the versioned rules for a reliance event; disposition and risk tier are evaluated independently.Source: Definitions · pp. 5–8

Evidence

  • Evidence Assertion VDTs preserve individual sourced facts and their provenance, freshness, scope, and privacy classification rather than collapsing them into a single compliance status.A Compliance Decision VDT supplies a time-bounded, purpose-specific predicate about whether current evidence and policy permit exercising authority; it does not amend the ARP.Source: Definitions · pp. 6, 8

Execution and evidence lifecycle

  • A single-use, transaction-bound EAC authorizes commit, while append-only lifecycle records and a sealed Valitorum preserve terminal handling and outcome evidence.Status freshness rules and risk tier determine when cached status is acceptable versus live introspection; a session eligibility decision is not transaction-specific and cannot authorize payment.Source: Definitions · pp. 6–8

Transaction control

  • A transaction-specific decision records policy, evidence, authority, approvals, expiration, and reason codes against a canonical transaction digest.The digest changes when a material transaction field changes; a reservation atomically holds capacity before an EAC is issued.Source: Definitions · pp. 6–8

Executive Summary

Payment systems authenticate credentials, but relying parties generally lack portable evidence that the exact transaction presented is currently authorized under applicable evidence, policy, budget, and approval state. The paper proposes a subject- and rail-neutral control plane that binds authority and approvals to the transaction, controls execution, and preserves lifecycle evidence.

Executive Summary

  • Relying parties generally cannot independently verify that the party presenting an exact transaction has current organizational authority under applicable evidence, policy, budget, and approval state.The gap also affects conventional transactions: delegations can change, approvals can mismatch transmitted instructions, and concurrent requests can exceed limits.Source: Executive Summary · p. 9
  • The protocol connects verified identity, a versioned ARP, sourced evidence, deterministic predicates, a transaction-bound decision, atomic capacity reservation, EAC-gated execution, and append-only outcome evidence.It is designed to apply across subjects and rails without replacing the payment rails.Source: Executive Summary · p. 9
  • An authorized principal may grant an agent narrower authority bounded by purpose, counterparty, transaction class, rail, value, and effective period.The append-only grant is evidence of delegated authority, not a bearer credential; its present validity is resolved against current ARP status.Source: Executive Summary · pp. 9–10
  • An agent may act without a human within its granted band, while crossing specified boundaries requires biometric exact-digest approval from a person with independent authority.The Agent Subject Profile adds workload registration, an attested key hierarchy, and a sovereignty boundary, but no separate authority concept.Source: Executive Summary · p. 10
  • Before consequential action, the protocol is designed to establish who is acting, whose authority supports the action, whether it is currently permitted, what exact transaction is authorized, whether capacity is reserved, and what occurred.Evidence assertions preserve sourced facts and their provenance; the organization configures how predicate results become dispositions and remains responsible for that policy logic.Source: Executive Summary · pp. 9–10

1. The Problem: Authentication Is Not Portable Authority

Authentication and internal controls are common, but their authority evidence is often not portable to relying parties. The unresolved question is whether current authority and controls apply to the exact instruction ultimately presented for execution.

1. The Problem: Authentication Is Not Portable Authority

  • Payment infrastructure already includes entitlements, approval limits, maker-checker controls, authentication, screening, and fraud scoring; the missing capability is portable, transaction-bound authority evidence.That evidence must be independently consumable across organizations, banks, processors, marketplaces, agent runtimes, and counterparties.Source: §1 · p. 10
  • A valid signature does not establish that a person or workload acts under a current delegation, within applicable evidence and policy, against available capacity, on the evaluated and approved transaction.Without that answer, organizations either block agent-initiated activity or permit it through controls that are difficult for outsiders to verify.Source: §1 · p. 10
  • The control gap spans people, organizations, agents, and multiple rails because authority, evidence, approval, and capacity are often verified inside systems the relying party cannot inspect.Those controls may also lack cryptographic binding to the exact instruction ultimately reaching the rail.Source: §1 · p. 10
  • Authentication, session validity, and human approval do not alone establish transaction authority; approvals must match the exact transaction ultimately presented to the rail.A per-transaction limit also requires atomic capacity reservation, and current non-revocation requires live status or a sufficiently fresh signed snapshot.Source: §1 · pp. 10–11

2. The ChainIT Architecture: Identity, Authority, Evidence, and Execution

The architecture separates identity, organizational authority, sourced evidence, and execution controls so relying parties can use only the facts needed for their purpose. Agent-specific identity and containment controls supplement, but do not replace, the protocol’s shared authority model.

2. The ChainIT Architecture: Identity, Authority, Evidence, and Execution

  • The Authority Protocol resolves whether an identified subject may perform a specific action, while the Agent Subject Profile adds workload identity and containment without adding an authority concept.The same authority artifacts apply across individuals, groups, organizations, and permitted agents; subject authentication and containment are what vary.Source: §2 · p. 11

2.1 ChainIT ID and the Individual VDT; 2.2 ChainIT Org ID and the Organization VDT

  • ChainIT ID anchors individual identity, while ChainIT Org ID identifies the legal entity and authority remains in a separately versioned record.The Organization VDT should not be a static container for authorized persons because authority changes independently.Source: §2.1 · p. 12, §2.2 · p. 12

2.3 Authority Resolution Pactvera, Delegated Authority, and the Agent Authority VDT

  • The ARP records who may act, for what purpose and scope, and during what period; permitted principals may delegate narrower authority within defined limits.Portable delegated-authority records reference the ARP and depend on its current status.Source: §2.3 · pp. 12–13
  • The Agent Authority VDT records an agent’s grant and its limits, but present validity, workload identity, policy fit, and permission to commit require separate checks.The grant defines an autonomous band; crossing its boundary requires exact-digest approval by a person with independent authority.Source: §2.3 · p. 13

2.4 Evidence Assertion VDTs and Context-Specific Decision VDTs; Evidence Assertion VDTs

  • Evidence Assertion VDTs preserve sourced facts individually, including their source, timing, jurisdiction, confidence, and privacy classification, rather than collapsing them into a universal compliance status.Evidence freshness follows source-specific cadence, risk triggers, material changes, and policy.Source: §2.4 · p. 14, Evidence Assertion VDTs · p. 14

Session Eligibility Decision VDT; Transaction Policy Decision VDT

  • A session eligibility decision evaluates whether a subject may use a consequential-action session, whereas a transaction policy decision is bound to one canonical transaction digest and cannot serve as permanent status.A session decision cannot authorize payment; the transaction decision is newly derived for the proposed transaction.Source: Session Eligibility Decision VDT · p. 14, Transaction Policy Decision VDT · p. 14

Regulatory precision

  • Regulatory checks are contextual: a PEP identification is not automatic disqualification, and an alert is evidence for evaluation rather than a portable invalidity label.A relying party may receive a manual-review disposition without protected source details that would reveal SAR existence or non-existence.Source: Regulatory precision · pp. 14–15

2.5 Business Rules Engine, Workflow Engine, and Execution Eligibility

The Business Rules Engine evaluates explicit, reason-coded predicates, while the organization configures how those results produce dispositions. The same control flow distinguishes agent identity and session access from transaction-specific authority to commit.

2.5 Business Rules Engine, Workflow Engine, and Execution Eligibility

  • The BRE evaluates session and transaction inputs as explicit reason-coded predicates, while the organization’s Workflow Engine configuration determines how those results combine and which dispositions follow.The BRE does not assign the disposition; the organization owns the policy logic it configures.Source: §2.5 · p. 15
  • Commit requires every execution predicate, including authenticated subject, valid authority, acceptable evidence, permitted disposition, fresh status, reserved capacity, required approvals, matching digest, and an unused valid EAC.For an agent, authentication resolves to workload attestation; for a person, it uses ChainIT ID at the required assurance level.Source: §2.5 · p. 15

2.6 Stable Agent Identity and Key Domains

  • The Agent Subject Profile establishes what a workload is, while the ARP and Agent Authority VDT determine what it may do; stable agent identity persists across workload and session key rotation.Workload keys authorize ephemeral session keys, to which session and execution credentials are sender-constrained.Source: §2.6 · pp. 15–16

2.7 Session and Execution Credentials; 2.8 Agent Authentication and Session Bootstrap

  • Session credentials permit proposal activity, but only a one-time credential bound to the exact canonical transaction digest may authorize commit, for either a person or a workload.The human authentication path converges with agent authentication at session-eligibility evaluation.Source: §2.7 · p. 16, §2.8 · p. 16

2.8 Agent Authentication and Session Bootstrap

  • Before issuing an agent session, ChainIT authenticates the registered workload using its registration reference, attested key, deployment evidence, and proof of possession.The workload key authorizes an ephemeral session key, and the SAC is bound to that session key.Source: §2.8 · pp. 16–17

2.9 Pactvera, ChainIT Pay, Lifecycle VDTs, and Valitorum; 2.10 Relationship to Provable Compliance

  • The rail adapter enforces EAC use, records material transitions as append-only lifecycle VDTs, and the Valitorum Service seals terminal evidence regardless of who initiated the proposal.The ARP governs authority, while the Compliance Decision VDT gates whether present evidence and policy permit its exercise; neither substitutes for the other.Source: §2.9 · p. 17, §2.10 · p. 17

3. Verification at Runtime: Status, Risk Tier, and Disposition

Runtime verification must account for revocation and evidence freshness at each reliance event rather than relying on credential signatures and expiration alone. Organizations configure dispositions for the resulting policy state, with bounded offline verification recorded as an auditable decision.

3. Verification at Runtime: Status, Risk Tier, and Disposition

  • A valid signature and unexpired credential do not establish that the credential, agent registration, ARP, person, organization, or supporting authority remains unrevoked.Current non-revocation requires live status or a signed status artifact within an approved freshness bound.Source: §3 · pp. 17–18
  • Freshness is assessed at reliance events, including session issuance, transaction initiation, human approval, scheduled review, and material source or risk changes.Each required item has its own maximum age derived from source, evidence type, transaction risk, product, jurisdiction, and reliance event.Source: §3 · pp. 17–18
  • StatusFresh checks cached non-revocation status, while EvidenceFresh checks each underlying sourced assertion; commit requires both, with live retrieval required when either fails or risk requires it.A current status snapshot alone does not establish that underlying evidence is current.Source: §3 · p. 18

3.2 Policy Disposition Selects the Outcome

  • Organizations configure dispositions: incomplete or stale evidence may be held, invalid authority may be rejected, and a mandatory restriction may prohibit execution.The disposition set is illustrative, and unresolved matches or contextual judgments require an authorized reviewer.Source: §3.2 · pp. 18–19
  • Risk tier and disposition are independent, and an offline verification record should preserve the status snapshot, evaluation time, permitted staleness, and reason the mode was acceptable.A high-risk transaction may be allowed after required controls, while a low-risk one may fail because the ARP was revoked.Source: §3.2 · p. 19

4. Applying the Protocol to Payment Pre-Authorization

Payment pre-authorization evaluates the actor, authority, evidence and policy, capacity, and exact instruction before value moves. The control sequence is subject-neutral, with rail-specific enforcement and authenticated outcome handling.

4. Applying the Protocol to Payment Pre-Authorization

  • Before value moves, the control plane evaluates who acts, whose authority supports the action, whether evidence and policy permit it, whether capacity is reserved, and whether the rail instruction matches the authorized transaction.The routine sequence proceeds from proposal and canonicalization through evaluation, reservation, approval if needed, EAC consumption, submission, reconciliation, and sealing.Source: §4 · p. 19

4.1 Subject Profiles: Human, Organizational, and Agent Initiation

  • The control sequence is subject-neutral: human, organizational, and agent initiation differ at authentication and proposal origin, while downstream authority, digest, reservation, execution, and evidence controls remain shared.For agents, action within the granted band can proceed without human interaction; crossing it invokes step-up approval, and the rail adapter reconstructs the digest for the one-time EAC.Source: §4.1 · pp. 20–21

4.2 Fiat Rail Profiles

  • Fiat rails use a rail-specific enforcement profile because existing ACH, wire, card, instant-payment, and bank interfaces do not universally accept arbitrary ChainIT credentials.The adapter reconstructs the transaction digest, validates the EAC and related controls, then consumes it through a recoverable commit path before or atomically with submission.Source: §4.2 · p. 21

4.3 Stablecoin and On-Chain Profiles

  • Stablecoin and tokenized-value controls may use a custody wallet, smart-contract gate, account-abstraction flow, relayer, paymaster, signing service, or off-chain preflight tied to an approved transaction hash.The canonical object binds network, asset, wallets, amount, nonce, contract call, fees, finality policy, and expiration.Source: §4.3 · p. 21

4.4 Outcome Events, Idempotency, and Unknown State

  • Rail outcome events must be authenticated and idempotent, and a timeout after possible submission is an unknown state that requires reconciliation before any new submission.Duplicate or out-of-order delivery must not create a duplicate payment or rewrite prior evidence.Source: §4.4 · pp. 21–22

5. Exact-Digest Approval and Append-Only Lifecycle Evidence

Human approval and execution are bound to one canonical transaction digest, while a short-lived EAC authorizes operational execution and append-only records preserve lifecycle evidence. Later exceptions are linked without changing the original sealed record, but these records do not guarantee legal enforceability, admissibility, or liability allocation.

5.1 Human Approval and Assurance

  • An approver must have independent authority and approve the exact transaction digest; higher-risk or irreversible transactions should require the approved high-assurance profile.Assurance depends on authentication properties such as phishing resistance and replay resistance, not whether approval occurs in an app, browser, or messaging channel.Source: §5.1 · p. 22

5.2 Canonical Transaction Digest: What You See Is What You Authorize

  • Deterministic encoding fixes the canonical transaction object, and any material change requires a new digest, decision, reservation, approval, and EAC as applicable.The same digest is bound across decisions, approvals, credentials, rail instructions, and lifecycle evidence; the adapter independently reconstructs and compares it.Source: §5.2 · p. 22

5.3 Operational EAC Versus Permanent Evidence

  • The EAC is a short-lived operational credential, while permanent lifecycle VDTs record its consumption, expiration, cancellation, or rejection.Separate immutable issuance and consumption or disposition records may preserve contemporaneous evidence; reusable credentials and private keys are excluded.Source: §5.3 · pp. 22–23

5.4 Append-Only Lifecycle VDTs and Valitorum

  • Linked immutable events preserve transaction lifecycle evidence, and a later return, reversal, chargeback, recall, or dispute is recorded as a new event.A Supplemental Valitorum may link the later exception graph to the original sealed Valitorum without modifying it.Source: §5.4 · p. 23
  • Pactvera and Valitorum provide structured evidence but do not guarantee enforceability, evidentiary admissibility, or liability allocation across every jurisdiction or rail relationship.Source: §5.4 · p. 23

6. The Agent Subject Profile: Agentic Commerce and the Sovereignty Boundary

The Agent Subject Profile adds workload identity and containment controls while delegated authority remains under the general, subject-neutral Authority Protocol. Its sovereignty boundary leaves final execution authority with the deterministic control plane.

The Agent Subject Profile

  • Agentic commerce requires proof both that the requesting workload is registered and that a currently authorized human or organization stands behind the action.A legitimate agent identity can act outside scope, while valid delegation can be misused by an unregistered or compromised workload.Source: §6 · p. 24
  • An autonomous agent may reason, gather evidence, and propose actions, but the deterministic control plane resolves authority and issues the one-time EAC enforced by the rail adapter.The agent does not receive unrestricted payment-account credentials, custody keys, or final execution authority.Source: §6 · p. 24
  • Verification can rely on a bounded set of issuer keys and status services, with cryptographic work per verification approximately constant but total operational cost scaling with transaction volume and other deployment factors.Comparative economics depend on deployment profile.Source: §6 · p. 24

7. Design Principles, Credential Lifetimes, and Residual Risk

The design separates authority, evidence, policy, and execution while applying current-context checks, bounded status freshness, and controlled failure dispositions. It is designed to reduce specified transaction risks, not eliminate fraud or other residual risks.

No implicit trust from prior success

  • Prior identity proofs, sessions, policy decisions, or approvals do not carry forward beyond their scope and freshness; required predicates are reevaluated for the present context.Source: No implicit trust from prior success · p. 24

Least privilege and intersection of constraints

Separate identity, authority, evidence, policy, and execution

  • Artifacts answer separate questions and can be refreshed, revoked, or disclosed independently; protocol artifacts are generally shared across subject classes, with specified registration and key artifacts specific to agents.Source: Separate identity, authority,… · p. 24, §7.2 · p. 25

Organization-owned policy logic

  • The organization owns the policy logic and assigns dispositions from BRE predicate results, while ChainIT supplies evidence, predicate evaluation, and workflow tooling.Source: Organization-owned policy logic · p. 25

Sender-constrained operational credentials

Atomic reservation and idempotency

Fail controlled

7.3 Residual Risk and Non-Goals

  • The protocol does not eliminate deception, coercion, collusion, malicious authorized actors, faulty evidence, infrastructure or workload compromise, accepted stale-status exposure, or irreversible settlement after induced approval.It is designed to reduce unauthorized, stale, replayed, substituted, duplicate, and out-of-scope transaction risk, not to be fraud-proof or instantaneously revoked everywhere.Source: §7.3 · pp. 26–27

8. Illustrative Scenario

The scenario applies the same ARP-based authority framework to human and agent proposals, with exact-digest approvals, capacity reservations, and rail-adapter enforcement. It illustrates bounded autonomous execution, concurrent capacity control, human step-up, and exception handling.

8.1 Human-initiated wire under the same ARP

  • Jane’s $60,000 wire requires high-assurance authentication and a second authorized approver under the ARP’s threshold, with capacity reserved before approval and the digest reconstructed by the adapter.Changing the beneficiary account after approval changes the digest and requires a new decision, reservation, and approval cycle.Source: §8.1 · p. 27

8.2 Agent-initiated payment within the delegated scope

  • The agent’s $3,800 routine invoice falls within its delegated scope and proceeds through an Allow decision, atomic reservation, one-time EAC, rail submission, reconciliation, and evidence sealing.The agent has no unrestricted access to the organization's bank account, wallet, or rail credentials.Source: §8.2 · p. 28
  • With only $5,000 of monthly capacity remaining, two simultaneous $4,000 proposals yield one successful reservation and one insufficient-capacity disposition.Source: §8.2 · p. 28
  • A $50,000 new-vendor proposal exceeds autonomous execution scope but can proceed through the required exact-digest approvals without expanding the agent’s standing delegation.The system revalidates policy and status and confirms the reservation before it may issue an EAC.Source: §8.2 · p. 28

8.3 Exception handling under either subject profile

  • A possible sanctions match is held for resolution; stale status requires live introspection, and a later return is recorded as a linked event without changing the Settlement VDT.Source: §8.3 · p. 28

9. Related Work

The Authority Protocol builds on credentials, delegation, transaction binding, workload identity, and tamper-evident logging, while resolving authority against a versioned organizational record at each reliance event. Its distinct contribution is to join those controls in a pre-commit process that binds approval and execution to one transaction and reserves capacity atomically.

Verifiable credentials and credential status

  • Verifiable credentials standardize cryptographic subject claims, while the protocol keeps each sourced fact separate and derives decisions anew for each reliance event.The passage also identifies Bitstring Status List [10] as a privacy-preserving revocation and suspension-status mechanism.Source: Verifiable credentials and credential… · p. 28

Authorization, delegation, and capabilities

  • OAuth extensions and capability systems express delegated permissions, while the protocol checks them against a versioned organizational authority record and binds commit to a transaction digest and atomic reservation.The passage names OAuth 2.0, Rich Authorization Requests, Token Exchange, GNAP, DPoP, and capability-based approaches -.Source: Authorization, delegation, and… · p. 29

Separation of duties and transaction binding

  • The canonical transaction digest extends dynamic linking beyond amount and payee to every material field and binds approval, policy decision, reservation, execution credential, and lifecycle evidence.The passage describes the “what you see is what you sign” problem and dynamic linking requirements.Source: Separation of duties and transaction… · p. 29

Workload identity, attestation, and zero trust

  • The Agent Subject Profile draws on workload identity, remote attestation, and zero-trust principles rather than trusting network location or prior success.The passage cites SPIFFE, the IETF Remote Attestation Procedures architecture, and zero trust.Source: Workload identity, attestation, and… · p. 29

Identity and delegation for AI agents

  • The protocol resolves agent authority against the same versioned organizational record as human delegation, checks evidence freshness at reliance, and reserves capacity before issuing a single-use execution credential.It treats an agent as one subject class among four.Source: Identity and delegation for AI agents · p. 29

Tamper-evident evidence

  • Append-only lifecycle VDTs and the sealed Valitorum support later verification that recorded history has not been rewritten.The passage relates these controls to tamper-evident logging and Certificate Transparency.Source: Tamper-evident evidence · p. 29

10. Conclusion

The paper frames authority resolution as a cross-subject, transaction-specific control question that is not ordinarily independently answerable outside the systems enforcing authority, approval, and capacity. ChainIT Provable Authority connects those controls to execution and sealed outcome evidence, with an additional workload profile for autonomous agents.

10. Conclusion

  • The control question is whether a person, quorum group, organization, or permitted workload acts under current delegation and applicable evidence, policy, capacity, and transaction approval.The paper says these controls are not ordinarily bound to the instruction that finally reaches the rail, and agents remove the human who might otherwise notice an incorrect answer.Source: §10 · p. 30
  • ChainIT Provable Authority connects identity, organizational authority, evidence, policy, transaction semantics, approval, payment execution, and immutable outcome evidence.The companion Compliance Decision VDT supplies the evidence-and-policy predicate; the Authority Protocol supplies authority resolution, transaction binding, capacity control, approval, execution, and sealed outcome evidence.Source: §10 · p. 30
  • For autonomous workloads, the Agent Subject Profile adds containment controls while keeping AI outside unrestricted private-key and final execution control.It allows agents to propose and coordinate real economic activity without introducing a separate authority concept.Source: §10 · p. 30
Loading 2610.22899v1…