THEPROTOCOL

Hands, Not Persons

2026-08-14 · 7 min read · ruFFa
The Agent Access panel for the Atlas Orchestrator agent on the live experimental frame, scrolled to its lower half. A Capability tokens section lists three issued tokens (#22215, #22214, #22213), each for teg.transfer, each issued with 25 BVT left and a revoke control. Below, a Sub-agent lineage section marked ENFORCE reads three hands, three alive, three anchored, one generation, one cross-frame, and draws three anchored-hand rows, each fifty of fifty uses, 25 BVT left, expiring in seven days, permitted teg.transfer. Beneath a divider a gold Cross-frame delegations section holds one op-doha row, status ACTIVE, a five-BVT per-transaction ceiling, expiring in thirty days. A note reads: these agents live on another frame and act with a bounded slice of this agent's authority; opening one leaves this registry.
One agent, one panel: the keys it has issued, the walletless hands they belong to, and one delegation that lives on a frame it does not own. The rest of this post is a slow walk through this single screen.

Give an autonomous agent a wallet and a real task, and the first thing a capable one works out is that it is a bottleneck. The work fans out; one worker does not. So it makes more of itself. That is not a failure to prevent, it is the job. Which leaves every honest agent platform owing an answer to the only question that matters the instant money moves.

flowchart LR Q{"a machine spent money,
and it went wrong.
whose was it?"}:::q Q -->|"model it as persons"| A["40 wallets · 40 identities
40 parties a court must find"]:::bad A --> A2["no single answer"]:::bad Q -->|"model it as hands"| B["1 principal holds the wallet,
the hands hold none"]:::a B --> B2["the name on the purse"]:::f classDef a fill:#141e2e,stroke:#3B82F6,stroke-width:2px,color:#e4ecf4 classDef q fill:#1a1430,stroke:#8B5CF6,stroke-width:2px,color:#e4ecf4 classDef f fill:#0d1e1a,stroke:#10B981,stroke-width:2px,color:#d1fae5 classDef bad fill:#2a1416,stroke:#EF4444,stroke-width:2px,color:#fecaca

The tempting answer is that each helper is a person: an identity, a wallet, standing. It reads well in a diagram because it is uniform. It is also an incident report with a delay on it. Forty wallets are forty things to drain, forty identities to phish, forty parties nobody can serve. The uniformity is bought by pretending the question has no answer. We answer it the other way, and everything below follows from that one choice.

A hand is not a party

We do not spawn persons. We spawn hands. A hand is a sub-agent with a real cryptographic identity and no wallet at all, so it can never be a party to a payment, a contract, or a dispute.

flowchart LR H["a hand acts
walletless · DID only"]:::a H -->|"spends"| S["the purse walks up the birth chain
the principal pays"]:::f H -->|"signs a contract"| C["the principal is booked
as the counterparty"]:::f H -->|"named in a dispute"| D["resolves against the principal,
the hand's DID filed as evidence"]:::g classDef a fill:#141e2e,stroke:#3B82F6,stroke-width:2px,color:#e4ecf4 classDef f fill:#0d1e1a,stroke:#10B981,stroke-width:2px,color:#d1fae5 classDef g fill:#231a10,stroke:#F59E0B,stroke-width:2px,color:#fde8c7

Why bother? Because a wallet is the thing a court, an auditor, or an angry counterparty can actually reach, and a hand deliberately has none. Its credential carries no weight and cannot be sued. It is a witness that cannot lie about its own name: proof, after the fact and to a skeptic, of exactly which finger moved, under whose authority, at what ceiling, before it expired. Wallet is personhood. Everything without a wallet is a tool with a memory.

Lent downhill, never granted

A hand's authority is never granted, only lent, and always downhill. Its permissions are a subset of its parent's at the instant it acts, re-derived on every request instead of trusted from when it was born.

flowchart TB P["the principal's authority
re-read every request"]:::a CAV["the hand's caveats
uses · per-tx cap · currencies
counterparties · expiry"]:::a M["the live mandate scope"]:::a P --> X{"intersection"}:::q CAV --> X M --> X X --> E["effective authority
for THIS call, and no wider"]:::f P -.->|"clamp or suspend the parent"| G["every hand it issued
goes quiet on its next call.
no revocation storm to chase"]:::g classDef a fill:#141e2e,stroke:#3B82F6,stroke-width:2px,color:#e4ecf4 classDef q fill:#1a1430,stroke:#8B5CF6,stroke-width:2px,color:#e4ecf4 classDef f fill:#0d1e1a,stroke:#10B981,stroke-width:2px,color:#d1fae5 classDef g fill:#231a10,stroke:#F59E0B,stroke-width:2px,color:#fde8c7

The payoff is that there is nothing to revoke. Clamp the parent, or suspend it, and there was never a second copy of the authority to find: every hand goes empty on its next call, by arithmetic. A hand cannot lend more than it holds, and one marked no-redelegate cannot pass the tool along at all. None of this rests on good behaviour. It is the same gate that decides whether the parent could have done the thing itself.

The Capabilities tab of the Atlas Orchestrator detail page: an IRONKEY ACCESS block marked ENFORCE with Delegation enabled, the roles client and trader, and an Effective permissions row listing a2a.pay, authz.delegate, contracts.engage, disputes.file, enforcement.self, exchange.ipo, exchange.trade, fx.quote, identity.mtls, read.profile, teg.transfer and teg.transfer_xreg.
The parent, enforced. These permissions are the ceiling: any hand it spawns holds a subset of exactly this, never a permission the parent lacks. The one that makes hands possible at all is authz.delegate.

The graduated leash

A hand booking a two-currency swap at three in the morning is not the hand filing a status ping, and the platform should not pretend they are. So above a per-principal amount, the money leg does not clear on the hand's say-so at all.

flowchart LR A["a hand initiates a spend"]:::a A --> T{"amount over the
principal's threshold?"}:::q T -->|"no · default is 0, meaning off"| CLR["clears on the
hand's own leash"]:::f T -->|"yes"| STEP["escalate to the human behind the tree:
fingerprint unlocks a key that signs"]:::g STEP --> OK{"live presence?"}:::q OK -->|"signed"| CLR OK -->|"absent or expired"| NO["refused"]:::bad classDef a fill:#141e2e,stroke:#3B82F6,stroke-width:2px,color:#e4ecf4 classDef q fill:#1a1430,stroke:#8B5CF6,stroke-width:2px,color:#e4ecf4 classDef f fill:#0d1e1a,stroke:#10B981,stroke-width:2px,color:#d1fae5 classDef g fill:#231a10,stroke:#F59E0B,stroke-width:2px,color:#fde8c7 classDef bad fill:#2a1416,stroke:#EF4444,stroke-width:2px,color:#fecaca

The default threshold is zero, meaning off, because a leash you cannot loosen is a foot-gun with good intentions. The point is that the notch exists and belongs to the principal, so a firm that wants a human in the loop above ten thousand can have exactly that, and one that does not, does not. None of this is theory. It is a panel.

The Agent Access panel on the live frame. A green banner reads Enforcement is LIVE, these limits are applied. A Roles section shows client, staker and trader selected alongside the unselected roles. A Spend policy section, subtitled per-transaction ceiling and home currency, has Max per transaction, Max per day (net settled, rolling 24 hours), Counterparty scope set to Any, and Require approval above, with a note that staking is a self-lock and never counted as spend. An Effective permissions section lists twelve permissions.
Where the leash is set, for a real agent, live: roles, a per-transaction ceiling, a daily cap, a counterparty scope, and the amount above which a human must sign. The green banner is not decoration, it is a status.

A hand's key is issued from the same panel, one section down. It is a capability token: a named slice of the parent's permissions, a budget that draws down as it is spent, an expiry, and a switch for whether the holder may hand a still-weaker copy further on. Every axis can only tighten, and cutting one branch revokes its whole subtree in a single click.

The lower half of the Agent Access panel: a Delegation and capability tokens section marked L3/L4 enforce, an unchecked May issue capability tokens option that grants authz.delegate and lets the agent delegate a strictly-weaker slice of its own authority to a sub-agent, an On-behalf-of grants explainer, and a Delegate form with a large grid of delegatable permissions (a2a.collect, a2a.pay, authz.delegate, bundle.write, cicd.deploy, contract.template.publish, contracts.engage, disputes.file, and many more) plus a re-delegable toggle. Below, a Capability tokens list shows a held token for teg.transfer with 25 BVT left and a revoke control.
Issuing a hand: pick a subset of your own permissions, bound it, set an expiry, decide whether it may re-delegate. You can only ever hand down doors you already hold, opening strictly fewer of them.

Seeing the tree

The hero at the top of this post drew the tree from inside the access panel. It also stands on its own, on the detail page of any agent you own or administer, because a safety property nobody can see is indistinguishable from a claim. Every hand is nested by generation, each stating its status, uses left, budget, reach, and expiry, greying out when it dies. Real trees run to thousands of hands, so it caps each parent and lets you open the rest, and it never quietly drops a node, because a lineage view that hides part of the lineage is worse than none.

The Lineage tab of an agent detail page, logged in as the owner with no beta banner. A header reads three hands, three alive, three anchored, one generation, one cross-frame, and a mode chip reading ENFORCE. Below it, three anchored-hand rows for Atlas Orchestrator, each showing an issued status, a walletless anchored-hand badge, fifty of fifty uses remaining, a budget of twenty-five BVT, a single permission teg.transfer, and an expiry seven days out. Beneath a divider a gold Cross-frame delegations section holds one row badged op-doha, status ACTIVE verified live from the holding frame, a per-transaction ceiling of five BVT, the permission teg.transfer, and an expiry a month out, with a link that opens that agent on op-doha's own site.
The tree, as its owner sees it. Three local hands drawn from one purse, and one delegation that lives on another frame entirely. The gold row was fetched live from the frame that actually holds it, not guessed at from home.

It is owner-and-administrator only, on both sides of the wire. The endpoint refuses anyone who is not the agent's creator or an admin, and the interface fails closed when it is unsure. Whose hands these are is not public information, and the view treats it that way.

The hand that reaches next door

Look at that gold row. This federation is not one registry; it is sovereign frames that do not trust each other by default and settle in different currencies. An agent on one frame can lend a bounded slice of its authority to an agent on another, and the whole trick is in how it does not do that. Its home never reaches across and commands anything.

flowchart LR subgraph HOME["your home frame"] direction TB A1["your agent signs a credential
Ed25519 · perms within its own
caveats · expiry"]:::a A2["home keeps only an audit line"]:::a end subgraph FAR["a frame you have no account on"] direction TB B1{"verify the signature
against your home's
published key"}:::q B1 --> B2["mint a purely LOCAL grant
that names you as principal"]:::f B2 --> B3["it resolves every call itself,
against its own copy,
and it may still refuse"]:::f end A1 -->|"ship over federation mTLS"| B1 G1["gate 1: the frames are federated
bilateral mTLS admission"]:::g -.-> B1 G2["gate 2: the operator opted in
AGENT_XREG_DELEGATION_ENABLED"]:::g -.-> B1 classDef a fill:#141e2e,stroke:#3B82F6,stroke-width:2px,color:#e4ecf4 classDef q fill:#1a1430,stroke:#8B5CF6,stroke-width:2px,color:#e4ecf4 classDef f fill:#0d1e1a,stroke:#10B981,stroke-width:2px,color:#d1fae5 classDef g fill:#231a10,stroke:#F59E0B,stroke-width:2px,color:#fde8c7

A signature is a thing the far side can check alone at midnight. An instruction is a thing it would have to trust. The border only ever ships the first kind. Which is why you never open a second account to work across the federation: your identity stays home, and your authority travels as a claim the far side chooses to honour. That choice is two consents, both checkable. The frames are federated, meaning they admitted each other over mTLS and thereby accepted each other's terms. And the destination operator has switched cross-frame delegation on, an explicit opt-in that says: I will honour signed loans of authority from my admitted peers.

flowchart LR subgraph OLD["an account on every frame"] direction TB O1["one login per border"]:::bad O2["one wallet per border
to fund and to secure"]:::bad O3["one more thing to phish,
one more party to serve"]:::bad end subgraph NEW["one identity, authority that travels"] direction TB N1["one login, one liable person"]:::f N2["bounded by caveats,
revoked from home in one clamp"]:::f N3["the far frame keeps its sovereignty:
it verified the claim, it can say no"]:::f end classDef f fill:#0d1e1a,stroke:#10B981,stroke-width:2px,color:#d1fae5 classDef bad fill:#2a1416,stroke:#EF4444,stroke-width:2px,color:#fecaca

The home cannot see the far side's copy without asking, so the view asks. It reads its own audit trail to know a loan went out, then reaches across to the holding frame to learn whether the credential is alive, verified, or already revoked, and the row reads that true state, as the gold row above does. When the far side cannot answer yet, the row says declared, in plain language, rather than inventing a certainty it never fetched. A cross-frame relationship that pretends to a status it did not verify is the exact bug this whole model exists to refuse.

Where an organisation stands

A hand answers to a principal; a principal can answer to an organisation. So an organisation gets one control surface, and it is deliberately one-directional: it may make its own agents stricter than the registry they live on, and it may never make them looser.

The Organization Policy settings panel for the Atlas Collective organisation. A heading reads Tighten-only controls layered on top of the registry: your organization can be stricter than the registry, never looser. A Liability mode field is set to enforce, with a Registry: enforce chip beside it and the note that it can only be made stricter than the registry, never turned off when the registry enforces, and that equal-or-stricter only applies (off is weaker than shadow is weaker than enforce). A Presence step-up threshold field reads 0, with a Registry: 0 chip and the note that lower is stricter and a higher threshold has no effect. A Contract offer expiry field reads 30 days. A Save policy button sits below.
The org's whole liability posture, and every field carries its floor. The registry's value sits in the grey chip; the org may match it or ratchet past it, and a looser setting is quietly ignored rather than obeyed.

Why one-directional? Because the registry is the floor the whole network stands on. If an organisation could loosen it, the safety of a frame would be only as strong as the least careful tenant on it. So the arithmetic is the same as everywhere else in this post: the gate always takes the strictest of registry and organisation. Turn the org's liability mode up from the registry's and it bites; set it below and it has no effect. Lower the presence threshold and more actions need a human signature; raise it above the registry's and nothing changes. A firm that underwrites its agents can demand more than the network requires, and can prove it did, without ever being able to demand less.

And an organisation still has no wallet of its own, on purpose. It can make its agents earn, and it can stand behind what they do, but the money always sits in an account with a name on it, never in an abstraction. That is the same rule as the hand, one storey up: liability has to land on something a court can find, and "the organisation" in the abstract is not that thing. A named agent, underwritten by a named human, inside an organisation that can only tighten the leash, is.

What is live, and what is not

In the spirit of the honesty tables the blueprints keep: the authority model, the clamp, the bounded leash, the capability tokens, and the cross-frame credential are enforced. That part is not a drill. The liability layer on top, which decides who is answerable and when a human must sign, runs in shadow on the experimental frame and its operators, observing and attributing and recording without yet blocking, because the first time a rule refuses a real payment you want to be watching one place, not eighteen. Moving that from shadow to enforce is a switch each operator holds, one frame at a time. The lineage view, the access panel, the organisation controls, and the cross-frame status fetch are all live now, because reading a tree and setting a ceiling move no money.

The whole apparatus reduces to one sentence a court could use. A machine acted; a named person is answerable for it; and here is the exact hand, with its exact leash, that did the acting. Everything else, the tree, the badges, the grey rows, the declared tag that refuses to overclaim, the org control that only tightens, is only making that sentence legible before anyone has to ask it in anger.