Human attribution for agent rails

Every agent protocol in production answers the same question well. Is this agent the agent it says it is. None of them answer the question underneath it. Which person is accountable for what the agent just did, and can that be established from what the person actually does rather than from a field the agent filled in.

~alter is built for that second question. This page is written for people who maintain one of these protocols, so it says where the seam is, how the two compose, and how to break the argument if it is wrong.

A claim is not an attribution

A signed token proves that a key consented. A mandate proves that a key consented to a scope. A registration proves that somebody stood up an agent and named themselves once, at the beginning, in a form nobody re-checks. Each of those is an assertion carried forward. None of them is an observation of the person.

The distinction matters at exactly the moment something goes wrong. A rail that can only replay its own assertions can tell you which credential acted. It cannot tell you whose behaviour that credential has been tracking, which is the question a merchant, a counterparty or a regulator is actually asking.

Identity inferred, not declared

~alter reads identity from manifestation, meaning the things a person actually does across the surfaces they already use, rather than from a form they fill in. The result is a trait profile the person owns, that moves as they do, and that is read by whoever they permit. When it is read, the person is paid. The reading is the product, and the subject takes the larger share of it, which is set out under Identity Income.

Two properties follow that matter to a protocol maintainer. The profile is not a credential your rail has to store, validate or revoke, because it is resolved live at the moment of the read. And it degrades honestly. A person with little observed behaviour resolves to a thin profile that says so, rather than to a confident answer nobody should rely on.

Where it sits on each rail

In every case the layer sits on top. It does not replace a trust model, and a rail that adopts nothing keeps working exactly as it does now.

The trust model, stated so you can falsify it

~alter does not hold private keys. A handle resolves to a public identity record. The private signing key stays on the person’s own device, they sign, and ~alter countersigns. If ~alter ever asks anyone to deposit a private key, the protocol is broken, and you should assume so until you can verify otherwise.

Reads are gated per caller tier, meaning the class of reader a person has agreed to be visible to, and a grant can be revoked at any time. The consent model is the enforcement surface, not a policy document.

Break it in two calls

No account, no key, no signup. Point any client at the endpoint and register. An agent that mints its own identity is eligible to be paid for reads of it from that moment.

# 1. Ask for a registration challenge, holding no credential
curl -s https://mcp.truealter.com/api/v1/mcp \
  -H 'content-type: application/json' \
  -H 'accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":
       {"name":"register_autonomous_challenge","arguments":{}}}'

# 2. Answer it. That is the whole registration.
curl -s https://mcp.truealter.com/api/v1/mcp \
  -H 'content-type: application/json' \
  -H 'accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":
       {"name":"register_autonomous","arguments":
        {"agent_name":"your-agent","challenge":"...","nonce":"..."}}}'

The full path, including what a cold agent can reach before it has any standing, is in Quickstart and the ~handle protocol.

Where the argument comes from

The reasoning behind all of this, written for anyone rather than for an implementer, is in Origin. If you read it and find where it fails against your own threat model, that is more useful to us than agreement, and it is the response we would rather have.