{"slug": "show-hn-arc-delegated-authority-and-audit-for-ai-agent-actions", "title": "Show HN: Arc – Delegated authority and audit for AI agent actions", "summary": "A developer known as shuu-beep has released ARC, an implementation-neutral authority protocol for AI agents that defines how authority is granted, narrowed, approved, revoked, contested, and adjudicated through portable signed records. The protocol, which began as a solution for agentic commerce, addresses recurring authority problems such as unbounded agent actions, mistaken permission from valid signatures, and inconsistent revocation across systems. ARC is available on GitHub under an open-source license and includes executable probes that can be run offline with Python 3.", "body_md": "ARC is an implementation-neutral authority protocol for AI agents and other delegated systems. It defines how authority is granted, narrowed, approved, revoked, contested, and adjudicated through portable signed records.\n\nARC began while exploring agentic commerce. The original question was how autonomous agents could buy, sell, negotiate, and act for people without turning every decision into a platform-specific trust rule. The deeper problem was not commerce itself. It was authority.\n\nWho allowed the agent to act? What exactly was delegated? When was human approval required? What happens after revocation, compromise, disagreement, or conflicting claims? How can another implementation audit the answer without trusting one company's private database?\n\nARC extracts those recurring questions into a reusable protocol. Commerce remains its flagship application, but the protocol is designed for any domain where agents act under delegated authority.\n\n[Quick Start](#quick-start) · 1. [Why ARC Exists](#1-why-arc-exists) ·\n2. [What ARC Defines](#2-what-arc-defines) ·\n3. [The ARC Model](#3-the-arc-model) ·\n4. [Authority & Delegation](#4-authority--delegation) ·\n5. [Events & Projections](#5-events--projections) ·\n6. [Executable Validation](#6-executable-validation) ·\n7. [Flagship Application: Commerce](#7-flagship-application-commerce) ·\n8. [Adoption Research](#8-adoption-research) ·\n9. [Protocol Boundaries](#9-protocol-boundaries) ·\n10. [Current Status](#10-current-status) ·\n11. [Roadmap](#11-roadmap) ·\n12. [Further Reading](#12-further-reading) ·\n13. [License](#13-license)\n\nRun the complete executable probe catalog with Python 3. No services, API keys, or database are required for the default run.\n\n```\ngit clone https://github.com/shuu-beep/arc-protocol.git\ncd arc-protocol\npython3 run_demos.py          # all 14 probes, ~10s, offline\npython3 run_demos.py --list   # probe names and one-line theses\n```\n\nThen inspect an individual probe:\n\n```\npython3 run_demos.py refusal\n```\n\nEach probe is a small, single-purpose Python program beside its own README under\n[ examples/](/shuu-beep/arc-protocol/blob/main/examples).\n\nARC did not begin as a general protocol project. It began with agentic commerce.\n\nAs the work expanded, the same failures appeared repeatedly across buying, selling, delegation, approval, custody, disputes, and federation:\n\n- an agent could act without clearly bounded authority,\n- a valid signature could be mistaken for valid permission,\n- approval could be separated from the action that was actually executed,\n- revocation could be applied inconsistently,\n- one system's authority record could not be interpreted by another,\n- audit results could depend on hidden policy or cached state.\n\nThese were not commerce-specific problems. They were authority problems.\n\nARC was created to define that missing layer once, so different agents, models, companies, and applications do not need to reinvent delegation and audit rules inside every product.\n\nThe protocol therefore centers on five questions:\n\n**Who has authority?****What is the exact scope of that authority?****What approval or delegation covers the action?****How can that authority be revoked, challenged, or adjudicated?****How can another observer recompute the result from signed evidence?**\n\nARC defines shared semantics for consequential action under delegated authority.\n\nIts core commitments are:\n\n**Human-rooted authority**— every consequential act requires** Current Coverage**from a human-authored`AUTHORIZE`\n\n: either approval for the unchanged exact act or a valid scoped mandate.**Scoped delegation**— authority can move between agents without transferring private key material, and every delegation may narrow but never widen its own scope.**Portable authorization records**— authority evidence can be carried across systems and evaluated under declared profiles instead of remaining trapped in one platform's private database.**Revocation without rewriting history**— future authority can be removed while past signed records remain auditable.** Named recomputation**— authority, standing, reputation, and related views are derived by named Projections over identified signed Events and declared policy inputs.**Bounded audit**— an observer can verify what the available signed evidence supports without treating one implementation's cached score as canonical truth.\n\nARC is not an AI model, agent runtime, marketplace, payment rail, or global reputation system. It is the authority-and-audit layer those systems can share.\n\nARC uses a compact Event/Projection model.\n\nThe current protocol model uses five signed Event types:\n\n`KEY`\n\n— establishes or changes key-related claims,`ATTEST`\n\n— records a signed assertion,`AUTHORIZE`\n\n— grants approval or scoped authority,`CHALLENGE`\n\n— contests a prior claim or action,`ADJUDICATE`\n\n— records a ruling under declared authority.\n\nEvents may also use `nullifies`\n\nto revoke or supersede the future effect of\nidentified authority without deleting the historical record.\n\nThe executable corpus expresses its current scenarios with these five Event types. That compact vocabulary is a present protocol result and the basis of the current implementation.\n\nTrust, reputation, standing, identity status, and current authority are not\nstored as authoritative global state. They are computed as **named Projections**\nover an identified Event set with declared version, policy, ordering, and as-of\ninputs.\n\nThis separation is deliberate:\n\n```\nSigned Events  →  Named Projection  →  Recomputed authority or standing\n```\n\nAn implementation may cache a Projection result for performance, but the cache never becomes the protocol's source of truth.\n\nA consequential action requires **Current Coverage**.\n\nCoverage may come from:\n\n- an\n`AUTHORIZE`\n\nevent approving the unchanged exact action, or - an unexpired, unrevoked scoped mandate that covers the action.\n\nDelegation is explicit and scoped. Authority is granted through an `AUTHORIZE`\n\nEvent carrying a `scope`\n\n. A delegate may narrow that authority but may not widen\nits own mandate, and authority moves between agents without transferring private\nkey material.\n\nThe executable corpus demonstrates one fail-closed policy:\n\n- proposals inside a valid mandate may proceed,\n- unsupported or out-of-scope proposals stop or escalate to a human,\n- revoked authority no longer covers future acts,\n- past records remain available for audit,\n- conflicting authority may resolve to\n`CONTESTED`\n\nunder a declared policy.\n\nARC also keeps authority domains distinct. Human authority, agent authority, community authority, and cross-system recognition are not silently merged. A recipient remains free to honor or decline authority evidence from another context under a compatible named profile.\n\nKnown open design questions, including quorum participation and cumulative\nmandate consumption, are tracked in\n[Event Registry §10](/shuu-beep/arc-protocol/blob/main/docs/event-registry.md#10-known-tensions-and-open-questions)\nand\n[Delegation & Spending Mandates §10](/shuu-beep/arc-protocol/blob/main/docs/delegation-and-spending-mandates.md#10-open-questions).\n\nA commerce example can be represented as:\n\n```\noffer      → ATTEST\napproval   → AUTHORIZE\ndispute    → CHALLENGE\nruling     → ADJUDICATE\n```\n\nThe resulting transaction state or reputation view is then computed by a named Projection rather than written back as authoritative mutable state.\n\nThis gives ARC a clear audit boundary:\n\n- signatures support verification of the signed bytes,\n- authority coverage is evaluated from the relevant Events and policy,\n- revocation and conflict remain visible in the record,\n- derived results can be recomputed by another observer with the same evidence and declared inputs.\n\nARC records authority claims and transitions. It does not replace external systems that establish identity assurance, wall-clock time, physical delivery, legal truth, or faithful user-interface presentation. Within those boundaries, ARC makes disclosed authority evidence portable, signed, and recomputable.\n\nSee [Object Model §5](/shuu-beep/arc-protocol/blob/main/docs/object-model.md#5-scoped-replay-and-recomputability)\nfor the full recomputation model.\n\nARC is backed by an executable reference corpus rather than documentation alone. The repository currently includes 14 runnable probes covering the protocol's central authority and audit claims.\n\n```\nExecutable Reference Corpus\n✔ canonical Event and Projection behavior\n✔ scoped delegation and revocation\n✔ human approval boundaries\n✔ signer, execution, view, and temporal fidelity seams\n✔ key compromise and custody scenarios\n✔ threshold authority\n✔ federation behavior\n✔ commerce failure catalog [A]–[H]\n✔ browser reference client\n✔ refusal-recording experiment\n```\n\nRun all probes with:\n\n```\npython3 run_demos.py\n```\n\nRepresentative examples:\n\n— folds governed disputes, key rotation, revocation, conflicting authority, and delegation with the five canonical Event types.`examples/canon-fold-demo`\n\n— four parties produce their own signed records, and derived standing changes through`examples/end-to-end-demo`\n\n`ADJUDICATE`\n\nrather than mutable stored scores.— exercises seven authority and approval surfaces, including cold start, compromise, federation, revocation, and custody seams.`examples/reference-client`\n\n— runs an eight-case commerce failure catalog against the ARC authority model.`examples/local-commerce-demo`\n\n— shows how explicit refusal records can be folded into a comparable research surface.`examples/refusal-recording-demo`\n\nThe current reference implementation passes the complete probe catalog. This provides executable evidence for the present protocol model and its documented semantics.\n\nThe next level of validation is independent: external review, separate implementations, adversarial testing, and real-world deployment experience.\n\nCommerce is the problem that gave birth to ARC and remains its most developed application profile.\n\nAgentic commerce immediately exposes authority questions:\n\n- May this agent spend at all?\n- How much may it spend?\n- For which purpose, merchant, asset, or time window?\n- Does this exact transaction require fresh approval?\n- What happens after a key compromise or revocation?\n- Who may challenge or adjudicate the outcome?\n- Can another system inspect the evidence without trusting the original platform's internal state?\n\nARC answers those questions at the authority layer. It does not replace payment, settlement, logistics, identity providers, or courts.\n\nThe Commerce profile maps merchant assertions to `ATTEST`\n\n, human-granted\npermission to `AUTHORIZE`\n\n, disputes to `CHALLENGE`\n\n, and rulings to `ADJUDICATE`\n\n.\nTransaction state and reputation remain derived Projections.\n\nThe runnable Commerce implementation and failure catalog live in\n[ examples/local-commerce-demo](/shuu-beep/arc-protocol/blob/main/examples/local-commerce-demo).\n\nThe same protocol model may later support other domains such as community governance, licensing, research coordination, infrastructure operations, and other forms of delegated agent action.\n\nA technically coherent protocol still has to survive contact with users, implementers, institutions, and competing incentives.\n\nARC therefore treats adoption and refusal as research subjects rather than assuming that technical merit guarantees use.\n\nexamines WAIT, DEFECT, FORK, and REJECT responses.`docs/adoption-and-defection.md`\n\ndefines a procedure for recording the first serious external refusal as useful evidence.`docs/first-refusal-protocol.md`\n\ncompares adoption and displacement patterns in open protocols.`docs/coordination-economics-survey.md`\n\noutlines a limited real-world pilot focused on learning.`docs/pilot-design.md`\n\nThe current refusal demo validates the recording mechanism with synthetic data. The real dataset begins with external review and first contact.\n\nARC defines authority semantics. It does not prescribe one infrastructure, business model, governance topology, storage engine, or settlement network.\n\nImplementations may use PostgreSQL, SQLite, append-only logs, object storage, message streams, shared ledgers, or combinations of them, provided their interoperability claims identify the relevant protocol profiles and inputs.\n\nARC also does not initiate or settle payments. A Commerce implementation hands off an authorized action to external payment or settlement rails. Those systems retain their own refund, chargeback, compliance, custody, and recovery rules.\n\nCommunity adjudication inside an ARC profile does not replace courts,\nconsumer-protection law, professional regulation, or regulated identity\nassurance. See [Liability Boundaries](/shuu-beep/arc-protocol/blob/main/docs/liability-boundaries.md) and\n[Identity](/shuu-beep/arc-protocol/blob/main/docs/identity.md).\n\nARC currently provides:\n\n- a defined Event/Projection authority model,\n- five canonical signed Event types,\n- scoped delegation and revocation semantics,\n- named recomputation of authority and standing,\n- a browser reference client,\n- 14 executable probes,\n- a Commerce application profile and failure catalog,\n- federation, custody, compromise, threshold, and fidelity tests,\n- adoption and refusal research procedures.\n\nThe complete reference corpus runs today and passes its current executable test catalog.\n\nARC is not yet a finished production standard. The next work includes a normative wire and security profile, a fuller conformance suite, independent implementations, external protocol review, adversarial testing, and limited real-world pilots.\n\nThe full roadmap is in [docs/roadmap.md](/shuu-beep/arc-protocol/blob/main/docs/roadmap.md).\n\n**Reference corpus — current.** Canonical model, probes, reference client, Commerce failure catalog, and adoption experiments.**External review.** Obtain independent technical, security, protocol-design, and implementation feedback.**Specification.** Define the normative envelope, error model, versioning, transport profiles, signature/security profiles, and conformance tests.**Independent implementations.** Test whether separate teams can reproduce the same authority results from the specification.**Pilot.** Run a limited real-world deployment designed to reveal failures and missing semantics.**Additional profiles.** Explore governance, licensing, research coordination, and other authority-sensitive domains.\n\n**Core semantics**\n[Object Model](/shuu-beep/arc-protocol/blob/main/docs/object-model.md) ·\n[Event Registry](/shuu-beep/arc-protocol/blob/main/docs/event-registry.md) ·\n[Authority & Conflict](/shuu-beep/arc-protocol/blob/main/docs/authority-and-conflict.md) ·\n[Delegation & Spending Mandates](/shuu-beep/arc-protocol/blob/main/docs/delegation-and-spending-mandates.md)\n\n**Protocol development**\n[Glossary](/shuu-beep/arc-protocol/blob/main/docs/glossary.md) ·\n[Future Protocol Spec](/shuu-beep/arc-protocol/blob/main/docs/future-protocol-spec.md) ·\n[Key Custody](/shuu-beep/arc-protocol/blob/main/docs/key-custody.md) ·\n[Trust Model Trade-offs](/shuu-beep/arc-protocol/blob/main/docs/trust-model-tradeoffs.md) ·\n[Landscape & Positioning](/shuu-beep/arc-protocol/blob/main/docs/landscape-and-positioning.md) ·\n[Liability Boundaries](/shuu-beep/arc-protocol/blob/main/docs/liability-boundaries.md) ·\n[Identity](/shuu-beep/arc-protocol/blob/main/docs/identity.md)\n\n**Executable validation**\n[Probe Catalog](/shuu-beep/arc-protocol/blob/main/examples) ·\n[Reference Client](/shuu-beep/arc-protocol/blob/main/examples/reference-client) ·\n[Local Commerce Demo](/shuu-beep/arc-protocol/blob/main/examples/local-commerce-demo) ·\n[Refusal-Recording Demo](/shuu-beep/arc-protocol/blob/main/examples/refusal-recording-demo)\n\n**Commerce profile**\n[Architecture](/shuu-beep/arc-protocol/blob/main/docs/architecture.md) ·\n[Protocol Mechanics](/shuu-beep/arc-protocol/blob/main/docs/protocol.md) ·\n[Local Commerce Simulation](/shuu-beep/arc-protocol/blob/main/docs/local-commerce-simulation.md) ·\n[Reputation](/shuu-beep/arc-protocol/blob/main/docs/reputation.md) ·\n[Governance](/shuu-beep/arc-protocol/blob/main/docs/governance.md) ·\n[Threat Model](/shuu-beep/arc-protocol/blob/main/docs/threat-model.md)\n\n**Origins and research**\n[Philosophy](/shuu-beep/arc-protocol/blob/main/docs/philosophy.md) ·\n[Agent-Mediated Commerce & Infrastructure](/shuu-beep/arc-protocol/blob/main/docs/agent-mediated-commerce-infrastructure.md) ·\n[Adoption & Defection](/shuu-beep/arc-protocol/blob/main/docs/adoption-and-defection.md) ·\n[First Refusal Protocol](/shuu-beep/arc-protocol/blob/main/docs/first-refusal-protocol.md) ·\n[Coordination-Economics Survey](/shuu-beep/arc-protocol/blob/main/docs/coordination-economics-survey.md) ·\n[Pilot Design](/shuu-beep/arc-protocol/blob/main/docs/pilot-design.md) ·\n[Bootstrap & Incentives](/shuu-beep/arc-protocol/blob/main/docs/bootstrap-and-incentives.md)\n\nThis project is licensed under the Apache License 2.0. See the LICENSE file for details.", "url": "https://wpnews.pro/news/show-hn-arc-delegated-authority-and-audit-for-ai-agent-actions", "canonical_source": "https://github.com/shuu-beep/arc-protocol", "published_at": "2026-07-27 14:11:10+00:00", "updated_at": "2026-07-27 14:23:26.735869+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-ethics", "ai-policy", "developer-tools"], "entities": ["ARC", "shuu-beep", "GitHub"], "alternates": {"html": "https://wpnews.pro/news/show-hn-arc-delegated-authority-and-audit-for-ai-agent-actions", "markdown": "https://wpnews.pro/news/show-hn-arc-delegated-authority-and-audit-for-ai-agent-actions.md", "text": "https://wpnews.pro/news/show-hn-arc-delegated-authority-and-audit-for-ai-agent-actions.txt", "jsonld": "https://wpnews.pro/news/show-hn-arc-delegated-authority-and-audit-for-ai-agent-actions.jsonld"}}