Skip to main content

Overview

On Atum, Know Your Agent (KYA) has one job: establish who is answerable when software spends on your behalf. The agent is the software — a tool, a scheduled job, a service. The principal is the person or company it represents. The agent acts because that principal signed a grant for it. The agent has not become the principal.
Agent on this page is not the settlement software a liquidity provider runs to fulfill payments.
If you already run Know Your Customer (KYC) programs, the parallel is the shape of the question, not the check. KYC asks who a person is. KYA on Atum asks who is answerable when software acts, and what it is allowed to do. Identity on a payment, and permission to move funds, are separate questions — see What is Atum ID? and Authorization and counterparties. This page is the agent case.

How this differs from an API key

If you have wired software into a card platform or a bank API, the pattern is familiar: you give the agent an API key, complete an OAuth flow, or let it use the company’s login. The platform stores a record that this agent may act. Later, if someone asks whether the company authorized a payment, the evidence is that platform’s logs. On Atum, that record is not the authority. Onboarding with Atum, or registering an agent, does not make the agent eligible to spend. The principal signs a grant that says what the agent may do. Anyone holding the payment can check that grant; they do not have to take Atum’s word for it.

KYA is not KYC

KYA on Atum does not replace KYC. Customer onboarding stays yours. Atum applies the same ideas — a binding statement, a check of origin, a record you can audit — to software acting for someone.

Two signed grants

An authorized agent on Atum carries two grants, signed by two different parties. Neither works without the other. The principal’s grant is meant to look like any other approval a treasury team already signs — same envelope, same policy engine. Atum cannot sign as the principal. The principal cannot skip Atum’s recognition check. You need both grants before the agent is authorized.
Two signed grants are how KYA works on Atum. They are not a self-serve integration today.

A session is not a payment

Most payment APIs treat a logged-in session as permission to spend. On Atum, they are separate. An agent may present its grants once and receive a short-lived token. Atum uses that token to throttle requests. The token is not permission to move money. On Atum today, an agent can only prepare a payment: it assembles the request; the principal’s signer completes it. When agents can later submit signed payments, each one still carries a signature over that request, produced by a signer the agent never holds. A compromised agent with a live token can ask for a signature. It cannot manufacture one.

What the grants do not prove

A grant establishes who is answerable. It does not say what the agent is. Whoever holds the agent’s key can act as that agent — the same way anyone holding an API key can call an API — until the grant is revoked. KYC has the same gap and handles it in layers: the customer declares who they are, documents are checked, and sometimes a live face is matched against those documents. KYA on Atum uses the same three levels: A stronger check on the software can raise what the agent is allowed to do — higher limits, more sensitive work. You do not need those extra checks for the agent to exist. If the person or company signed “this software may act for me,” that is enough. Most tools you would actually wire up cannot run inside a secure chip, and Atum does not require them to.

What this does not cover yet

What is Atum ID?

Identity on a payment, not a login

Credentials

Known to Atum and third-party credentials

Authorization and counterparties

Identity vs whether a payment may proceed

Agentic payouts

Call Atum as a payment tool from an agent