Sign what your agent may do.
Never hand it the spending key.
How software acting for someone else proves what it may do, and what it cannot do at all.
What is typically handed to an agent today
You want software to pay, so you give it the account. Typically, there is one secret, and it both identifies and spends.
An account.
What usually gets handed over is the key, a token or a copied set of credentials — standing access to whatever that account reaches. Nothing inside that secret records who agreed to that, or to what.
The spending key.
There is no separate agent key: the secret that pays is the secret that also identifies. Identity collapses into custody: the same secret works whether it was handed over deliberately, copied by a subprocessor, or taken. A system reading that secret cannot tell those three apart.
A record.
Logs describe what happened. They are signed, if at all, by whoever kept them. Consent that nobody signed at the time cannot be reconstructed afterwards.
Atum cannot authorize an agent alone
Two things travel with an agent’s request: a grant the participant signed, and a credential Atum issued. Both are signatures, and they come from different parties. The grant names the agent and states its bounds — which participant stands behind it, and what that participant agreed it may do. Atum’s credential records that it checked that grant’s signature and registered the agent against it. Neither stands alone, and neither party can produce the other’s.
Authorizing a software agent takes two signatures, and Atum can only produce one of them.
Three rules
Know Your Agent is a specification under review, published as a rule set rather than a feature list. It is for the participant integrating an agent, and for the risk function that has to approve one.
TWO SIGNATURES — Nothing an agent says about itself counts. An agent’s permissions come from two parts:
- A participant-signed grant
- A credential Atum has issued
A request carrying a grant but with no credential is an unregistered agent; a credential is not issued without a grant to check.
ONE LINK — The agent receives the grant from the participant, and the participant receives its credential from Atum. The chain is one link long.
NO SPENDING KEY — An agent only assists with preparation — it does not spend. In the first version of these rules, an agent assembles a payment, but holds no key that can actually spend. The spending signature stays with the participant, per payment.
Under these rules, an agent prepares the payment, presnting both signatures (the participant-signed grant issued to the agent, and the credential Atum issues to the pariticpant) to open a session. The session is not indefinitely held, and the agent’s authority is re-derived every feew minutes.
Once the agent has presented, it may continue with the narrowest of these three things: the bounds it participant granted, what the participant permits, and what the participant may do itself. If the agent asks for more, less is returned, rather than escalating.
A stolen agent key buys the same thing: the grant that names it, nothing wider, until it expires — and no ability to submit a payment.
Both a participant-signed grand and Atum-issued credential have an end date. These rules require one, because there is no revocation to fall back on.
Verification
The verification layer these rules land on is built. One shared step is wired into six perimeters across four services, so there is one verification implementation rather than a dialect per service.
Verification is handled in a single pass, with the following checks:
- The holder’s signature
- That the holder is the party signed to the inner request
- A content hash which maps the presentation to the payment request
- The environment it was issued
- Its validity dates
- Whether the issuer is a recognized one
If a presentation is altered after signing, it is refused, and that refusal is exercised in continuous integration against a running issuer rather than a fixture.
Enforcement
Enforcement of identity checks is staged, environment by environment. A failed check is logged before it refuses: audit, then permissive, then strict. Most partners are not yet on strict.
That is Atum ID — a signed fact about a participant on a payment. It is not proof that software is your agent, and it is not permission to spend.
Know Your Agent is the agent case. The principal signs a grant; Atum signs a credential; neither works alone. That pair is not a self-serve integration today. Onboarding with Atum, or registering an agent, does not make the agent eligible to spend. Today the agent prepares a payment; the principal’s signer completes it. That is the gap these rules address.
What this changes, and what it does not
Name who answers for an agent, once. So that you can stand one signed grant behind an agent instead of provisioning it its own account. The grant opens a session rather than becoming one itself.
Bound it in the act of creating it. So that you can state a ceiling at the moment you delegate, rather than policing it afterwards. An agent cannot widen what you signed, and over-asking narrows it.
Let authority run down on its own. So that it lapses on a date you set rather than through a withdrawal you have to request. Expiry is the only withdrawal path these rules provide, which is why they require one on both the grant and the credential.
- Not a diligence finding. A credential records who signed for an agent, not that the agent is fit to use.
- Not a revocation service. Authority ends at expiry, or by not being re-issued.
- Not proof of what software holds the key. A signature identifies a key and the party behind it, not the code.
- Not autonomy. An agent acts on its participant’s instructions, inside bounds that participant signed.
- Not a participant directory. A participant’s authority is read from what its request presents, not looked up.
Sign what your agent may do.
Never hand it the spending key.
Authorizing a software agent takes two signatures, and Atum can only produce one of them.
