Can an AI agent be a customer for KYC purposes?

No. Identity obligations attach to legal persons, and software is not one. An agent cannot be identified, hold an account in its own name, or be the subject of a check. The obligations apply to the human or company operating it, which is where the identity relationship sits.

What changes when an agent makes the payment?

Attribution becomes the difficult part. The requirement to know who the customer is has not changed, but demonstrating that a specific autonomous transfer was authorised by a specific principal, within a specific delegation, is something the operator has to design for deliberately.

Does a non-custodial design remove compliance obligations?

It changes who carries them rather than removing them. A provider that never takes possession of funds is in a different position from one that holds them, but obligations may still exist somewhere in the arrangement. The specifics depend on jurisdiction and activity, so take advice rather than inferring.

How do you attribute a payment to a principal?

Give every autonomous spender its own session key registered to its own account, so each transfer carries an onchain signal of which spender made it. Then record the authorisation alongside it: the scope, limits, expiry, and who granted it. Shared keys destroy attribution irrecoverably.

What records should you keep for agent payments?

The authorisation as well as the transaction: what the principal approved, with what limits and expiry, plus which request prompted each payment and what was being bought. Transaction data shows value moving but not why, and later questions are almost always about why.

Does KYC Change When an Agent Pays?

An agent is not a legal person, so identity obligations attach to the human or entity it acts for rather than to the agent. What changes is not who must be identified but how you demonstrate which principal authorised a payment, which makes attribution and record keeping the engineering problem rather than identity checks themselves.

Why the question is usually framed wrongly

Identity requirements attach to legal persons. An agent is software, so it cannot be a customer, hold an account in its own name, or be the subject of an identity check. Whatever obligations apply, apply to the person or company operating it. That answers the literal question and leaves the interesting one untouched.

The interesting question is attribution. If a payment is made by a process acting autonomously, the operator needs to be able to say which principal that process was acting for, under what authority, and with what limits. That is a records and design problem, and it is one the operator creates or solves at build time.

The distinction matters because teams often expect a new category of compliance obligation to appear and instead find an existing one they cannot evidence. The requirement to know who your customer is has not changed. The ability to show that a given transfer was authorised by a specific customer, through a specific delegation, is what autonomous operation puts at risk.

Custodial and non-custodial are not the same position

Where a provider holds funds on behalf of users, that provider is in a position that typically carries obligations, and the details depend heavily on jurisdiction and activity. A non-custodial design, where the user's account holds the funds and a scoped key authorises spending, places the provider differently because it never takes possession. This changes who carries what, not whether obligations exist anywhere, and it is a question for counsel in your jurisdiction rather than one to settle from a design document. CryptoCadet is non-custodial: the account and its funds remain under the owner's control, with session keys providing bounded authority.

What to build so attribution holds

One key per agent, per principal. The single most useful design decision. If every autonomous spender has its own session key registered to its own account, then every transfer carries an onchain signal of which spender made it. Shared keys across agents or across users collapse that, and no amount of application logging fully recovers it, because the chain records the key and not your intent.

Record the authorisation, not just the payment. Store what the principal approved: the limits, the scope, the expiry, when it was granted, and by whom. A payment inside a recorded delegation is explicable. A payment with no corresponding grant is not, regardless of how well the transfer itself is logged.

Keep the delegation chain explicit. Principal authorises an agent with a scope; agent pays within it. Two links. Where an agent delegates further, or where one agent acts for several principals, write down how that is represented before building it, because retrofitting attribution onto a shared spender is close to impossible.

Log the decision, not only the transaction. Which request prompted the payment, which service was being paid, what the agent believed it was buying. Transaction data shows value moving; it does not show why, and why is what any later question will be about.

Retain records for as long as they may be needed. Retention periods for financial records are frequently longer than teams assume, and an agent generating high volumes of small payments generates correspondingly large records. Decide on storage and retention deliberately rather than discovering the volume later.

Expect counterparties to have their own requirements. A service selling to agents may need to know who it is selling to, for its own obligations or its own risk appetite. Being able to present a consistent principal identity is a commercial requirement as much as a regulatory one.

Do not design around avoiding identification. Architectures whose purpose is to obscure who is transacting create legal exposure and make you a poor counterparty. The goal is clean attribution, not absent attribution.

Frequently asked questions

Can an AI agent be a customer for KYC purposes?: No. Identity obligations attach to legal persons, and software is not one. An agent cannot be identified, hold an account in its own name, or be the subject of a check. The obligations apply to the human or company operating it, which is where the identity relationship sits.
What changes when an agent makes the payment?: Attribution becomes the difficult part. The requirement to know who the customer is has not changed, but demonstrating that a specific autonomous transfer was authorised by a specific principal, within a specific delegation, is something the operator has to design for deliberately.
Does a non-custodial design remove compliance obligations?: It changes who carries them rather than removing them. A provider that never takes possession of funds is in a different position from one that holds them, but obligations may still exist somewhere in the arrangement. The specifics depend on jurisdiction and activity, so take advice rather than inferring.
How do you attribute a payment to a principal?: Give every autonomous spender its own session key registered to its own account, so each transfer carries an onchain signal of which spender made it. Then record the authorisation alongside it: the scope, limits, expiry, and who granted it. Shared keys destroy attribution irrecoverably.
What records should you keep for agent payments?: The authorisation as well as the transaction: what the principal approved, with what limits and expiry, plus which request prompted each payment and what was being bought. Transaction data shows value moving but not why, and later questions are almost always about why.