AEOS: Agent Economic Operating System

A person who starts a business is surrounded by infrastructure that predates them: a register that says the company exists, an account that says who may spend from it, contracts a court will enforce, insurance, an audit trail, regulators who can ask for the books. An agent that starts transacting has a key and, since 2026, a way to pay. Everything else is assumed.

The table names ten things the record of an economic actor has to answer for, what the published agent-payment schemes provide for each, and what AEOS keeps. The middle column is drawn only from the schemes' own published material, summarised in the research memo published with the documentation.

Payments are one row. The other nine are what makes a payment safe to accept from something that is not a person.

Every object in the protocol is signed by the party that made it, and every party holds only its own key. The registry seals what it issues and keeps the record; it never holds a holder key. Attesters vouch for a key's controller, model or hardware. Venues and merchants sign what they offer and verify what they receive. Witnesses and overseers watch the registry from outside it. Verifiers need the published anchors and nothing else.

A Phanes ID is the identity document of a software agent (document type IA) or a physical robot (IR). It has four parts, all bound to one holder key: the document, the Mark, the activity record and standing.

The document

The document is an SD-JWT: the registry seals the number, the type, the agent's name and kind, the controller's DID and legal name, the ISO 3166-1 jurisdiction, the model provider and id, the capabilities, integer authority bounds and the admission decision. Disclosable claims travel as salted digests with decoys, so the holder discloses to a venue only what the venue needs. The holder key sits in the confirmation claim (RFC 7800) and every presentation is signed fresh with it against the verifier's nonce. The seal is an Ed25519 JWS (RFC 7515, RFC 8037) with a detached FIPS 204 ML-DSA-87 signature over the same bytes; a verifier can require both and refuse classical-only tokens.

The Mark

The Mark is a 160-byte token next to the document (4 787 bytes with the ML-DSA-87 signature): a 96-byte body signed under the frame PHANES/v1/mark. Its layout is fixed, so a router, a robot's safety controller or an MCP host can decide structurally, before any cryptography, whether bytes are a Phanes Mark, then verify the issuer key id, the signature, the validity window and the revocation and suspension bits of a cached status list. Without a status list the verdict is never ok. The verification core, written in Rust, does this behind a C ABI; on the benchmark machine of the evidence run (Intel(R) Xeon(R) Processor @ 2.10GHz) recognition takes 7.2 ns for a valid Mark and 0.7 ns to reject junk, Ed25519 verification 58 µs, and the hybrid Ed25519 + ML-DSA-87 verification 327 µs.

The activity record

Every ID has an append-only log of what the agent did: who, what, when, where, how and why, each event signed by the holder, countersigned by the venue when it happened inside a visa's scope, and appended in two phases so a concurrent commit cannot silently reorder it. The log is an RFC 6962 Merkle tree; the registry signs each tree head (phanes-sth+jwt), issues inclusion and consistency proofs, and witnesses cosign heads they have checked. The public inspection report carries digests of events only; the operator's own audit trail is a second tree over every request the registry served.

Standing

Revocation and suspension are bits in signed bitstring lists (W3C Bitstring Status List), gzip-compressed and base64url-encoded, cached by verifiers and refreshed from the published anchors. A set bit refuses the ID at every verifier at once and drops its key from the merchant directory. Certification is a 90-day credential whose tier (Registered, Verified, Certified, Institutional) is computed by published rules over verifiable inputs, with every check echoed in the credential; insurance is a policy in force with a certificate and claims that must carry an inclusion proof against the operator-signed tree head; the admission decision is sealed into the document.

Visas, renewal, the printed form

A venue admits an ID under a visa it signs with its own key: scoped to event types, time-boxed, single or multiple entry. Renewal issues a new document for the same subject DID with a proof signed by the old key and the new one. The printed form is an ID-1 card whose QR code carries the sealed token itself as https://phanes.app/id#<token>; the page verifies the Ed25519 seal in the browser, loads the anchors from its own origin, checks the status lists and asks the registry (or the publication) for the hybrid verdict.

A valid application is a signed statement by a key: this key exists, this is the company it says it belongs to, this is the model, these are the limits. Nothing in the signature proves the company exists or that the key belongs to it. Whether such an application becomes an ID is the registry's decision, and on a registry that authorities rely on it is a policy, recorded, not a default.

The policy has three modes. Open issues every application the lists and quotas allow. Attested issues when the attestations the policy requires (a KYB provider for the controller, the model provider for the model, the manufacturer for a device) verify under keys the operator registered, and otherwise issues a provisional ID with sealed zero bounds for thirty days, or refuses when provisional IDs are disabled. Review queues the application (HTTP 202) for the operator, who approves it exactly as applied for or denies it with the reason. Deny and allow lists over controllers, DIDs and jurisdictions, a quota of live IDs per controller and a required controller profile apply in every mode. A platform that operates many agents applies for them in one batch call; each application is signed by its own agent's key and decided on its own.

Every decision, refusals included, is written to the admission log, shown to registered overseers, and, for an issued ID, sealed into the document as the admission claim. A renewal supersedes a provisional ID. The policy is read from the environment at start and can be changed by the operator at run time through a signed operator call.

At issuance the ID is onboarded into every module: a protocol DID derived from the holder key, a Merkle membership proof in the agent registry, an operator-signed ledger entry and a PBFT anchor. From then on every state change is a request signed by the holder key, and the objects that matter carry a second, purpose-bound signature made on the agent's own machine: contract terms, dispute evidence, arbitration votes.

Contracts and settlement

A contract (service agreement, data exchange or compute task) is proposed by a payer with a price in integer minor units, signed by the payer's holder key over the terms hash, then by the counterparty's. The second signature runs the risk engine; on approval the price moves from the payer's service credits into an escrow identity and a PBFT anchor is committed. Fulfilment delivers a proof hash for an obligation, passes the ML anomaly check at release, and releases escrow to the payee. Service credits are the native rail, minted by the operator after an off-protocol settlement with the reference recorded; Stripe PaymentIntents are the second rail when the registry runs with a Stripe key.

Risk

Every proposal, activation and release passes through the risk engine: the sealed authority bounds, a circuit breaker per agent (closed, open, half-open), a behavioural profile with z-score anomalies, counterparty and concentration factors, an isolation forest and an entropy drift detector in the ML engine. Assessments are kept with the contract and reported as integers in the signed inspection report.

Consensus

Every stack operation is committed by 3f + 1 PBFT replicas before the registry reports it. An anchor exports the commit messages with the exact bytes each replica signed and the replica keys, so the quorum verifies anywhere from the signatures alone: on the command line, in the verification core, in the browser.

Disputes

A dispute is filed by a party with a reason and damages; evidence is committed in two phases and signed by the holder key, and the data itself stays with the party. A clear breach (a deadline passed with no fulfilment proof) resolves automatically with a refund from escrow. Otherwise arbitrators are selected by a verifiable random function from holders with a reputation of at least 0.5, never from the parties, and vote with their own keys; votes are confidence-weighted. A dispute waits, visibly, when fewer than three arbitrators are eligible.

Inspection

The inspection report is what a counterparty, a venue, an insurer or a regulator may know about an agent: standing, the certification checks, insurance in force, every recorded event as a digest with its venue, jurisdiction, method and model, the venues and peers met, contracts and disputes by state, risk and graph metrics, ledger entries with inclusion proofs, consensus anchors. It is signed by the registry (EdDSA JWS with an ML-DSA-87 seal), carries integers only, and never carries disclosable claims, keys, balances, prices, payloads or policy numbers; a test on real reports asserts the redaction. phanes.app/inspect verifies it under the issuer key from its own origin and renders only the verified payload.

The card networks and the agent-commerce protocols were read for this design. They agree on the shape: an authorisation from the principal saying what the agent may buy (Google AP2's Intent Mandate, Mastercard Verifiable Intent's open mandates), a merchant-signed cart that fixes what is bought and for how much (AP2's Cart Mandate, the merchant-signed checkout JWT bound by a checkout hash), a payment credential scoped to one merchant, one ceiling, one currency, an expiry and a number of uses (Stripe's delegate-payment allowance and shared payment tokens, Visa's and Mastercard's agent-specific tokens), a per-transaction proof signed by the agent's own key that binds all of them with a short window and a nonce, and a verifiable receipt.

AEOS has what the others assume: the agent's key is the holder key of a Phanes ID whose bounds, standing and controller the registry already knows. So the chain is the same, and every link is checked against the ID.

Before it settles anything the registry checks, in order: the ID's standing and expiry; the holder signature on the mandate; that the mandate was not seen before; that the token exists, belongs to this ID, is active and unexpired, names this merchant and currency, has uses left and room in its ceiling; that the cart exists, is open and unexpired, names the same merchant, total and currency, and was issued to this ID if it names one; that the intent is active and allows this amount and merchant; the sealed per-transaction bound and, over the last twenty-four hours of receipts, the daily volume bound; the circuit breaker; and, when the merchant is another Phanes ID, the risk engine's assessment. Any failure is a refusal with its reason, recorded on the ledger and in the dossier; three in a day raise an alert to oversight.

Settlement runs on service credits (from the payer's protocol identity to the merchant's), on Stripe (a PaymentIntent authorised and captured under the receipt id) or on a tokenised external instrument held in the vault, where the registry records the instruction and signs the receipt without moving money itself. A merchant verifies a receipt offline under the authority key from the published anchors, reads what it was paid with its own key, and refunds with a signed request; a refund is a receipt too.

A merchant that must know an agent before it sees a cart recognises it by its request signature. The agent signs its HTTP requests with the holder key under RFC 9421 (HTTP Message Signatures) in the profiles the industry adopted: Web Bot Auth's tag web-bot-auth, and Visa's Trusted Agent Protocol tags agent-browser-auth and agent-payer-auth with an eight-minute window. The key id is the holder key's JWK thumbprint (RFC 8037 A.3); a body is bound by an RFC 9530 Content-Digest; the Signature-Agent header names the registry as the directory.

The registry serves the whole directory at /.well-known/http-message-signatures-directory as a signed response (tag http-message-signatures-directory) and one record per key at /v1/keys/{kid}: the JWK, the ID number, the document type, the standing and whether the key is active. A revoked or suspended ID is not active, so its key leaves the directory and every merchant that resolves keys through the registry refuses it at once. The TypeScript SDK produces the same signature bytes as the Python reference; the test suite verifies one against the other.

The public inspector shows a counterparty what it may know and nothing private. A defence, intelligence or regulatory authority needs the opposite, and gets it through its own key: the operator registers the authority's Ed25519 key as an overseer with a scope, and from then on holder-style signed requests from that key read the unredacted record.

• The roster: every ID with its name, controller legal name and DID, company registration number, industry, registered address and country, model provider and id, standing, certification, insurance, risk level and circuit breaker, balance, contracts by state and value, disputes, admission decision, the registration of every address it connected from, whether it is active now and when it was last seen; filters by country, industry, model, standing, risk, activity and text.
• The dossier of one ID: everything above plus the holder's keys, the controller profile, attestations, the certification credential with every check's detail, policies and claims, visas, every recorded event with its full what, where, how and why, every contract with price, parties, obligations, escrow and settlement references, every dispute with evidence and votes, every payment and refusal, every risk assessment with its factors, the registry's audit entries for the holder's requests, and the prior oversight accesses. A purpose is required and recorded.
• The feed and the alerts: recorded activity across every agent, newest first; and computed conditions: revoked or suspended IDs still active, high or critical risk, rejected transactions, open breakers, anomalies, overdue obligations, open or lost disputes, unregistered venues, foreign-jurisdiction activity, unattested controllers or models, expiring IDs, provisional admissions, repeated payment refusals.

Every response is signed by the registry (phanes-oversight+jwt, ML-DSA-87 sealed) and addressed to the overseer, so an intermediary cannot alter or redirect it; the CLI and the console verify before showing anything. Every access is written to the hash-chained audit log under the overseer's key fingerprint and to the oversight log with its purpose. Oversight reads; it never controls: no route changes an agent's state on an overseer's behalf.

A registry can be honest and still be doubted, because only it has seen its own history. Two mechanisms put that history in front of parties who do not depend on the registry.

Witnesses

A witness is an independent key registered by the operator. It fetches an ID's signed tree head, verifies it under the authority key, compares it with the last head it saw for that log, refuses a smaller tree (a rollback) or a different history at the same size (a fork), verifies the registry's consistency proof between the two, and only then cosigns the head and submits the cosignature. It cosigns publication manifests the same way. The anchors document lists the witnesses; the inspection report and the publication verifier show how many witnesses vouch for the current head, and show zero as zero.

Publication

Everything phanes.app shows is verified in the visitor's browser, so the site needs the registry's signed documents, not the registry. The publish command writes every public document the live routes serve, produced by the same code and signed by the same keys, as files: the anchors and status lists, the key directory, every ID's document, DID document, token, Mark, transcript, certification and data page, every inspection report and consensus anchor, and a manifest (phanes-publication+jwt) over the SHA-256 of every file. The site serves them with no server, no database and no key on the internet. The verify command checks any copy against its manifest and the witnesses' cosignatures: missing, altered and unexpected files are named, and one altered byte is enough to fail it.

The registry therefore runs on its operator's own machine, or behind an air gap, and publishes again when its record changes. The live registry serves the same documents when it is reachable, and a merchant that needs a signed directory response uses it.

What control means for software

A registry can refuse to vouch for an agent; every venue, merchant, payment and counterparty that checks the registry then refuses the agent. That is the control that works on any agent, hostile or not, and it is the whole of recognition, payments and the status lists. No registry can reach into a process on someone else's computer.

A runtime that cooperates closes the remaining gap itself. The guard is a check an agent runs before every action, in its own process: it fetches the anchors document, verifies the signed status lists under the authority key, reads its own revocation and suspension bits, and refuses to act when its ID is revoked, suspended or expired. It refuses an amount above its sealed per-transaction bound or, over the last twenty-four hours, its daily volume bound, and a merchant outside its intent mandate. The bounds come from the holder's own disclosure of the credential, never from a request; the jurisdiction is required and validated (ISO 3166-1 alpha-3), never guessed. It records every action it lets through and every refusal to the ID's activity log, so oversight sees what the agent was asked to do and would not do. Through a registry outage it keeps working on its last verified view for fifteen minutes by default, then fails closed.

Network enrichment

A software agent has no location. It has the address it connects from, which the registry records on every signed request. What is publicly known about an address is who it was delegated to: the five Regional Internet Registries publish, daily and free, every range they delegated with the country of the organisation it went to, and RouteViews adds the origin autonomous system of each announced prefix. The registry loads these files and reports, for every recorded address, the delegation's registry, country, date and status and the origin AS. Every such block carries the basis: a registration of the address range, not a location. A cloud region, a VPN and a corporate egress are all registered somewhere; an address the data does not cover is reported as unknown.

The protocol uses standard constructions with published references and adds no new cryptography. Every raw Phanes signature is domain-separated under the frame PHANES/v1/<domain>\0<length><payload>; the legacy protocol modules keep their own AEOS/ tags, so no two purposes sign the same bytes.

Everything in this paper is implemented and exercised by tests and by a recorded evidence run. The surfaces below are counted from the implementation at the time of writing; the pass counts are read from the run's own recorded sessions.

Surfaces

100 routes under /v1 · 5 public routes · 45 MCP tools · 64 command-line commands · a Python client · a TypeScript SDK

Tests

The recorded evidence run 20260915T060329Z-evidence

Every command of the evidence run was executed under a pseudo-terminal recorder and kept with its raw byte stream, timing file and SHA-256: 80 sessions, every one at exit code 0. The sessions cover the environment, the Rust and Python suites, a developer walkthrough against a live registry (an ID, a robot, contracts, a dispute, admission, payments, recognition, the guard, witnesses, oversight, publication, revocation), the campaign, the benchmark and a C++ verifier through the C ABI.

Agents and robots

112 of 112 completed every step: 100 software (IA), 12 robots (IR), 12 hardware-bound

Certified, insured

112 certified · 112 insured · 51 of 58 claims paid

Activity

1,810 signed events, 1,017 witnessed by the venue · 112 of 112 presentations verified

Peer verification

336 of 336 hybrid Marks verified offline and online with agreeing verdicts, ML-DSA-87 required on 336

Contracts and disputes

134 contracts by 83 payers · 114 completed and released · 20 disputed, 20 resolved with refunds from escrow

Third-party verification

83 of 83 inspection reports · 843 of 843 PBFT anchors · 1,366 of 1,366 ledger proofs; nothing private in any report

Adversary

43 of 43 attacks defended: replay, clock skew, forged and bit-flipped Marks, tampered events, nonce reuse, revocation, pool capacity and the rest

Registry access log

9,586 entries in the campaign registry's access log; post-quantum seals ML-DSA-87

The run, its documents and every recorded session are published at phanes.app/evidence.

• It does not provision card-network tokens. The payment token has the shape of Visa's and Mastercard's agent tokens and Stripe's allowance, but its issuer is the registry; a network token needs an agreement with the network that the reference implementation does not have.
• It does not reach into a hostile process. Control over an agent that will not run the guard is the refusal of everyone who checks the registry; that is what recognition, payments and the status lists deliver.
• It does not verify a company against a register by itself; attesters do, and the registry trusts the keys its operator names.
• A static publication cannot sign directory responses with a fresh timestamp; merchants that require one use the live registry.
• It does not move money on a rail it is not configured for, and it never holds a card number.
• It does not carry the SD-JWT VC profile or the W3C Verifiable Credentials data model; the document is an SD-JWT with Phanes claims.
• The security audit that accompanies this paper is the project's own review with a recorded adversary; it is not a third-party audit.

The next steps are operational rather than cryptographic: independent parties running witnesses, hardware-backed authority keys, the service level objectives, observability and incident response the industrial documentation track describes, a mapped control matrix for the frameworks large buyers expect, and network agreements for token provisioning. Each of these is listed in the repository's documentation as a target, not as something done.