Arc——AI 智能体行动的授权委托与审计

shuu-beep

/

arc-protocol

Public

Notifications You must be signed in to change notification settings

Fork 1

Star 0

main

Branches Tags

Go to file

Code Open more actions menu

Latest commit

History

178 Commits

178 Commits

Folders and files

Name Name Last commit message

Last commit date

apps

apps

assets

assets

diagrams

diagrams

docs

docs

examples

examples

packages

packages

.gitignore

.gitignore

CONTRIBUTING.md

CONTRIBUTING.md

LICENSE

LICENSE

README.md

README.md

run_demos.py

run_demos.py

View all files

Repository files navigation

ARC is a research protocol and executable reference for signed, recomputable authority and standing evidence when independent principals act through Agents.

What happens when your Agent meets another Agent and negotiates on your behalf?

Principal A Principal B | | | bounded delegation | bounded delegation v v Buyer Agent <--- propose / counter / refuse / accept ---> Seller Agent | | +---------- transaction and outcome evidence -------+ | withdrawal / conflict / challenge / adjudication | Current Coverage and Current Standing recomputation

For example, a person may authorize a Buyer Agent to purchase one meal for no more than KRW 20,000 when declared quality and delivery conditions are met. A Seller Agent may offer only available items within its own application and principal constraints. Either Agent can refuse, counter, or escalate a term outside its authority. If authority expires or is withdrawn, an offer changes, or claims become contested, the parties need more than a transport message or a current policy Boolean to explain what evidence supports the current result.

ARC studies that signed semantic layer: delegation, narrowing, attributable claims, exact approval, expiry, causal withdrawal, unresolved conflict, challenge, authorized adjudication, and recomputation from the same declared Event set, profile, ordering context, and as_of value.

ARC is not a payment rail, Agent transport, marketplace, checkout protocol, universal identity system, universal reputation score, production gateway, or real dispute tribunal.

Why ARC? gives the falsifiable comparison. Landscape and Positioning compares the model with current Agent, commerce, payment, credential, and authorization standards.

Table of Contents

Quick Start ·

The Multi-Principal Problem ·

What ARC Defines ·

Events and Recomputation ·

Commerce Reference Profile ·

Executable Evidence ·

Protocol, Core, and Gate ·

Overlap and Material Gap ·

Boundaries ·

Maturity and Adoption ·

Further Reading ·

License

Quick Start

Run the complete offline probe catalog with Python 3. No service, API key, or database is required.

git clone https://github.com/shuu-beep/arc-protocol.git cd arc-protocol python3 rundemos.py # all 14 probes, ~10s, offline python3 rundemos.py --list # names and one-line theses

Run one probe and inspect its neighboring README:

python3 run_demos.py commerce

1. The Multi-Principal Problem

Agent runtimes already provide useful sandbox, permission, approval, and hook controls. IAM, OAuth, policy engines, API gateways, credential brokers, and payment systems already control many consequential actions. ARC does not try to replace them.

Those controls are usually strongest inside one runtime, vendor, organization, or transaction system. The original ARC question is broader: how can Agents representing different principals exchange and inspect authority-relevant evidence without assuming one private database is the complete shared truth?

The recurring questions are:

Which principal authorized which Agent or delegate?

What scope, amount, counterparty, resource, and time interval were covered?

Did a later delegation narrow rather than widen that scope?

Which exact offer or action did a principal approve?

What changes after expiry, withdrawal, key lifecycle evidence, or conflict?

Which challenge or adjudication is recognized under the selected profile?

Can another observer recompute the same current result from the same inputs?

ARC treats authority, standing, and reputation readings as named computations over signed evidence—not as globally authoritative mutable labels.

1. What ARC Defines

ARC proposes shared semantics for:

bilateral principal/Agent applicability across independent counterparties;

bounded delegation and narrowing without sharing private key material;

exact approval bound to unchanged reviewable action material;

causal withdrawal that does not erase the historical record;

explicit CONTESTED results when supplied evidence does not justify a unique current answer;

challenge and authorized adjudication records without inventing a universal tribunal; and

Event-set/profile/as-of recomputation of Current Coverage and Current Standing.

These are evidence semantics. A receiving application chooses which profile, trust roots, Event set, and external systems it accepts.

ARC does not define discovery, network transport, product ontology, inventory, checkout, payment credentials, settlement, delivery, legal identity, real-world truth, or enforcement. Those layers remain external.

1. Events and Recomputation

ARC's Canon contains five signed Event types:

KEY — key registration, rotation, revocation, and provenance claims;

ATTEST — attributable evidence such as an offer or outcome claim;

AUTHORIZE — exact approval or scoped delegated authority;

CHALLENGE — a signed contest of a claim, action, or ruling; and

ADJUDICATE — a decision by an authority recognized under a named profile.

Withdrawal and key revocation are not extra Event types. They use the existing types, predicates, causal references, and nullifies field under declared profile rules.

Declared signed Events + profile and version + ordering context + verification/completeness boundary + as_of | v Named Projection | v Current Coverage / Current Standing / contextual reputation view

Different Event sets or profiles may legitimately yield different results. ARC therefore identifies the computation rather than claiming one invisible global history or universal authority of last resort.

See Object Model , Event Registry , and Authority and Conflict .

1. Commerce Reference Profile

Commerce is the motivating and most developed application profile.

external discovery -> offer request / proposal / counteroffer / refusal -> attributable offer evidence -> mandate coverage or exact principal approval -> optional application Gate decision -> external checkout/payment/fulfillment -> outcome evidence -> challenge / adjudication -> recomputed authority or standing

Proposal, counteroffer, refusal, acceptance, checkout, and fulfillment messages are application or external-protocol messages. They are not additional ARC Event types. An application may record an attributable offer as ATTEST , an approval as AUTHORIZE , a dispute as CHALLENGE , and a recognized ruling as ADJUDICATE .

The current fixtures can evaluate Buyer-side authority against an exact action and supplied counterparty evidence. They do not prove a Seller Agent's complete internal delegation chain, inventory truth, payment, delivery, or legal outcome.

See the Commerce application profile , Architecture , and discovery topology choices .

1. Executable Evidence

The repository contains 14 runnable, offline probes:

✔ five-type Canon folds and deterministic authored scenarios ✔ delegated authority, narrowing, expiry, and withdrawal ✔ exact approval and escalation seams ✔ causal conflict and policy-relative resolution ✔ key rotation, revocation, compromise, and custody boundaries ✔ stale/cache, temporal, execution, signer, and view fidelity ✔ threshold and federation ambiguity ✔ eight-case Commerce failure catalog ✔ refusal-recording experiment

Representative paths:

examples/canon-fold-demo — Canon sufficiency, delegation, withdrawal, conflict, and illustrative resolution policies.

examples/end-to-end-demo — independently authored records folded into standing under a named policy.

examples/reference-client — browser reference artifact and authority/custody fixtures.

examples/local-commerce-demo — the Commerce application failure catalog.

Passing fixtures prove the authored behavior and boundaries they exercise. They do not prove independent interoperability, complete evidence, production security, external truth, or market adoption.

1. Protocol, Core, and Gate

ARC Protocol signed Event and Projection semantics; application profiles; 14 probes | v ARC Reference Core minimum executable authority/evidence validation and Projection reference | v ARC Execution Gate optional application policy and simulated pre-dispatch enforcement examples | v external target / payment / deployment / fulfillment

ARC Protocol owns the proposed semantic model and the broader multi-principal research question.

ARC Reference Core is a non-normative executable reference for a bounded subset of authority and evidence semantics. It does not return application ALLOW / DENY decisions.

ARC Execution Gate demonstrates how an application may combine a current Core result with local policy before a simulated dispatch. It is not ARC as a whole or a production gateway.

The current baselines are 14 Protocol probes, 93 Core tests, and 69 Gate tests.

1. Overlap and Material Gap

Current standards already cover much of the operational flow:

A2A and FIPA provide Agent discovery/interaction and negotiation patterns;

ACP and UCP provide checkout, order, and fulfillment state;

AP2 provides important buyer mandate, exact transaction binding, expiry, verifier checking, receipts, and autonomous-use controls;

OAuth/RFC 8693, IAM, and policy engines provide delegation and enforcement;

verifiable credentials, OpenID4VP, UCP profiles, and payment-network Agent trust mechanisms provide identity and transaction evidence.

ARC must not claim those capabilities as generally unique.

The current comparison nevertheless finds a material semantic gap . The reviewed stack does not natively provide one common model combining:

signed bilateral authority and counterparty history;

symmetric applicability to independently represented principals;

unresolved causal CONTESTED state;

causal withdrawal, challenge, and authorized adjudication; and

reproducible Current Coverage/Standing from an identified Event set, profile, ordering context, and as_of value.

An application can build those properties itself, but doing so is custom state/Event/recomputation work rather than use of an already equivalent standard. See Landscape and Positioning .

1. Boundaries

ARC signatures and Projections do not establish:

complete or globally available evidence;

legal identity, beneficial ownership, or Agent independence;

truthful offers, inventory, fulfillment, or transaction outcomes;

legitimate governance institutions or legal jurisdiction;

signing-key or downstream-credential custody;

an independent approval channel or enforcement point;

direct-path closure, durable atomic consumption, target idempotency, reconciliation, availability, or operations.

A production deployment must assign those responsibilities to identity, credential, application, payment, IAM, gateway, target, and institutional systems. See Key Custody , Threat Model , and Liability Boundaries .

1. Maturity and Adoption

ARC currently provides a coherent documentation model, 14 executable Protocol probes, a Reference Core alpha, and simulated Execution Gate examples. The multi-principal Commerce semantics are a real executable reference, not merely historical speculation.

Independent wire/profile interoperability, production enforcement, and broad Agent-to-Agent commerce adoption are not yet proved. The market is pre-market / not yet testable for broad necessity claims.

That market status limits claims of inevitability, commercial necessity, production readiness, or adoption. It

... (truncated at the site's per-page length limit; see the source link below for the full text.)