Know Your Agent: Who Authorized the Bot That Moved a Security Token

An AI agent moves a tokenized security. The transfer settles. The compliance layer writes down a movement from one verified holder to another verified holder, and every word of that record is true.

It is also missing the only fact anyone will ask about afterwards: which human told the agent to do it.

I wrote that sentence in public on 30 March 2026, in the Ethereum Magicians thread for a proposal called ERC-8118. My exact words, typos and all: "8118 handles the “what can this agent do” side well. theres a complementary gap tho: who authorized this agent?" Thirteen days later, ERC-8226 was created to answer exactly that.

This article is a status report on whether it did.

ERC-3643 already has an Agent. It is not this one.

One word has to be pulled apart first, because getting this wrong invalidates the whole article. ERC-3643 already has an Agent. It has had one since 2021. It defines the role in an interface called IAgentRole, and the standard is explicit that "it is the owner role, as defined by ERC-173, that has the responsibility of appointing and removing agents."

That Agent is an issuer-side operator. The token owner appoints it, and it can mint, burn, freeze wallets and force transfers. It is a compliance officer with a private key. It is not an investor’s delegate, it has no principal, no scope, no spending cap and no expiry.

It gets better, and stranger. The Rationale of ERC-3643 already anticipated automation: "We envision scenarios where the agent role is fulfilled by automated systems or smart contracts, capable of programmatically executing operational functions like minting, burning, and freezing in response to specified criteria or regulatory triggers."

So in 2021 we had already imagined bots holding privileged roles on a regulated token. We imagined them on the issuer’s side of the table. The gap this article is about is on the investor’s side, and nothing in the standard was ever pointed there.

// ERC-3643 (Final since 2023-12-12). The Agent role, verbatim.
// Read the doc comment carefully: this is an ISSUER-side operator.
// It is NOT an investor's delegate, and it is NOT an AI agent.
interface IAgentRole {
  function addAgent(address _agent) external;
  function removeAgent(address _agent) external;
  function isAgent(address _agent) external view returns (bool);
}

// "it is the owner role, as defined by ERC-173, that has the
//  responsibility of appointing and removing agents."
//
// No principal. No scope. No spending cap. No expiry.

For the rest of this piece, "the ERC-3643 Agent role" always means the issuer-side operator above. "AI agent" and "the investor’s agent" always mean the software acting for a token holder. Anyone who tells you ERC-3643 has no concept of an agent has not read it, and anyone who tells you it already solves agent mandates has read the wrong half.

What the compliance layer actually sees

Now the mechanism. ERC-3643 states the conditions for a transfer as a normative MUST-list, and that list is the cleanest thing to quote because it is short and it is binding.

Two of those six are hooks into other contracts, and the difference between them matters.

isVerified lives on the Identity Registry. The standard describes it as checking "the receiver", in both the MUST-list and the section that defines it. Worth being precise here, because writers overstate it constantly: the sender’s identity is not re-verified at transfer time. Only their frozen status and free balance are. The sender was verified when they were registered.

canTransfer lives on the Compliance contract. That one is the socket, and it is the reason this article exists.

Here is the interface, verbatim. I am quoting this rather than the illustrative transfer implementation the EIP also ships, because that example has inconsistent variable names and would not compile as printed. The interface is normative. The example is not.

// ERC-3643 (Final since 2023-12-12). The compliance hook, verbatim.
// ICompliance is a SEPARATE CONTRACT that the token calls into.
interface ICompliance {
    function canTransfer(address _from, address _to, uint256 _amount) external view returns (bool);
    function transferred(address _from, address _to, uint256 _amount) external;
    function created(address _to, uint256 _amount) external;
    function destroyed(address _from, uint256 _amount) external;
}

// How the token reaches it, from the EIP's own example:
//   require(_tokenCompliance.canTransfer(from, to, amount), "ERC-3643: Compliance failure");
//
// Three values arrive. The caller is not one of them.
// Inside ICompliance, msg.sender is the TOKEN address, never the agent.

That is the load-bearing finding, and it comes from the normative interfaces rather than from anybody’s opinion. ICompliance is a separate contract. The token calls into it. canTransfer receives exactly three values, no caller and no calldata. transferred, created and destroyed receive the initiator no more than canTransfer does.

So when an agent moves a security token through transferFrom, the ERC-3643 compliance layer is structurally incapable of noticing that an agent was involved.

And the ERC-20 allowance that authorized the agent in the first place is invisible to it. approve and allowance are inherited from ERC-20 and never appear in any compliance interface or requirement in the standard. The one place the whole regulated stack cares about authority is the one place authority was never routed.

Five agent standards are merged. None is Final.

The obvious answer is that a newer standard should close this. Several are trying, and none of them has finished. Here is the status snapshot, all of it read from the raw EIP frontmatter and the ethereum/ERCs git history on 2026-08-05.

Both token standards these proposals must plug into are Final: ERC-3643 since 2023-12-12, and ERC-7943 (uRWA) since May 2026. Five agent-related ERCs are merged into the repo, ERC-8004 Trustless Agents, ERC-8183 Agentic Commerce, ERC-8217 Agent NFT Identity Bindings, ERC-8226 Regulated Agent Mandate and ERC-8273 Attestation-Gated Agentic Actions. All five are Draft.

Five merged, zero Final. That is the number to hold onto.

Two of those rows need a correction, because the internet has them wrong. ERC-8118 is not a standard. eips.ethereum.org returns a 404 for it, and PR #1450 has been open and unmerged since 2026-01-06, last touched on 2026-01-25. It is a proposal that has been sitting for over six months. Its mechanism is also the opposite of what most people assume: the signer is the agent, not the principal, and the reason given is anti-squatting rather than compliance. The proposer put it plainly in the thread: without the agent’s signature, anyone could claim an address as their agent and block it, which is a denial-of-service vector. The principal is authenticated by being msg.sender, which authenticates that somebody called, not who they are.

ACTA is a research post on ethresear.ch, published 2026-05-05, not an EIP and not a proposal to the ERCs repo. It is a privacy layer above ERC-8004 and it does discuss personhood credentials. I have seen it attributed to the Ethereum Foundation. I could not verify that, so I am not repeating it.

And ERC-7943, the newest Final standard in this space, contains the words agent, delegate, principal and operator exactly zero times across its entire text. It is not that uRWA answered the question badly. It never asked it.

ERC-8226 is the one that seriously tries

ERC-8226, Regulated Agent Mandate, is written specifically to close this gap, and I want to be fair to it before I am hard on it, because it is a serious piece of work.

It specifies a real mandate. Not a hand-wave, not a registry of good intentions. Two interfaces: IComplianceProvider, which grants, revokes and checks a principal and returns a tuple of eligibility, a reason code and an expiry; and IAgentMandate, the registry itself, with storage keyed by the pair of agent and principal and at most one active mandate per pair. The reason codes are the ones a compliance team would actually write down, including KYC_EXPIRED, AML_FLAG, NOT_ACCREDITED, NOT_QUALIFIED and JURISDICTION_BLOCKED. Granting a mandate MUST revert if no compliance provider is set.

It was created on 2026-04-12, merged into the ERCs repo as a Draft on 2026-05-12, and got a reference implementation and a spec refinement merged on 2026-06-29.

One piece of provenance, stated neutrally because it is provenance and not misconduct. All four authors of ERC-8226 use brickken.com addresses, and one of them also co-authored Final ERC-7943. Single-company authorship is normal in EIP-land. It matters here for exactly one narrow reason, which I will get to two sections from now.

The rest of this article is about the questions the standard has not answered. It is a Draft with no spec activity since 2026-06-29, which is roughly five weeks of silence at the time of writing, so none of what follows is a complaint about slowness. It is a list of what would still be open if it shipped tomorrow.

A valid mandate never says where the tokens go

Start with the strongest one, because it comes straight out of the interface.

A mandate under ERC-8226 constrains the asset, the action label, the amount and the time window. It does not constrain who receives the tokens. The spec says as much in prose elsewhere, noting that it caps the quantity transferred rather than specific token identifiers. But you do not need the prose. The signature tells you.

// ERC-8226 "Regulated Agent Mandate" (Draft, created 2026-04-12).
// The authorization check, verbatim. Read the parameter list twice.
function canExecute(
    address agent,
    address principal,
    address asset,
    bytes32 action,   // WHAT may be done
    uint256 amount    // HOW MUCH may move
) external view returns (bool);

function recordExecution(
    address agent,
    address principal,
    bytes32 action,
    uint256 amount
) external;

// Missing from both: any parameter naming WHERE the tokens end up.

Five parameters go into the authorization check and four into the execution record, and none of the nine is a destination. A valid mandate can say "this agent may move up to one million of this asset by transferFrom for the next thirty days" and remain completely silent about where those tokens go. That is the custody question, and it is proven here from the normative interface rather than from anyone’s reading of the forum.

This is not a gotcha. The authors listed it as open on day one. In the April 2026 announcement, under a heading literally titled "Open topics", they asked who the registered owner is when an agent acquires tokens on behalf of a principal, laid out both models, and said they were seeking input on whether the standard should prescribe a default or stay agnostic. Then, after building the reference implementation, they declined to answer. On 2026-06-29, in what is still the most recent post in that thread, the lead author wrote that the current PR keeps the spec custody-agnostic, that prescribing a default would constrain adoption across use cases with materially different operational needs, and that they will revisit the position once there are production deployments to learn from.

There is a tension in the thread worth naming without over-reading. In June another author wrote that the mandate lets the agent act against the principal’s wallet and never take custody. But the April post offers agent-custodied as a supported model, and the June update says the reference implementation demonstrates that path. Those are reconcilable: a mandate does not move custody of holdings you already have, and the open question is where newly acquired tokens land. The thread never reconciles them in writing, so I will not pretend it did.

Here is why it is the centre of gravity for anyone on a permissioned token. ERC-3643 requires isVerified on the receiver. If the agent custodies, the agent’s wallet is a registered investor and the compliance layer records the agent as the holder. Whether an agent can be the holder of record, and what a transfer agent maintaining the securities register does with that, is a live legal question. I am an engineer and I am not going to answer it here. I will only state what the engineering makes true: on an ERC-3643 token, whoever receives is whoever the register knows.

The same open topic has a twin nobody came back to. The April post also flagged receive-side compliance, noting that the spec covers agent-initiated outbound transfers and that for inbound transfers the token must decide whether to apply investor eligibility to the agent or to the principal. No later post in the thread addresses it, and the June update list does not mention it. The interface agrees: canExecute has no receiver either. As a small aside, that April passage names a token hook called canTransact, which exists in none of the standards involved. ERC-7943 has canSend, canReceive and canTransfer; ERC-3643 has isVerified and canTransfer. I quote it as written rather than silently correcting it.

The pattern it publishes cannot reach ERC-3643

Now the part I have not seen anyone else make, which is also the part I am most confident about, because it follows from two interfaces I can point at.

ERC-8226 says it works with any regulated token standard, naming ERC-7943 and ERC-3643, and it lists ERC-3643 in its layer table. Its integration rule is stated as one sentence: the regulated token integrates the mandate check inside its existing pre-transfer hook, the principal is the holder, the agent is the caller as msg.sender, and a transfer where the caller is not the holder is agent-initiated and MUST satisfy the mandate for that pair. That rule has a hard requirement buried in it. The hook must be able to see msg.sender as the agent.

Notice the asymmetry in the same sentence, too. For ERC-7943 it names the exact function, canTransfer. For ERC-3643 it says only "transfer restrictions", with no function named. And the only worked code in the entire EIP targets ERC-7943.

// ERC-8226's ONLY worked integration example, verbatim from the EIP.
// Note the target: ERC-7943, not ERC-3643.
// Pseudocode: canTransfer for RAMS-aware ERC-7943 tokens.
function canTransfer(address from, address to, uint256 amount) public view returns (bool) {
    require(canSend(from), ERC7943CannotTransfer(from, to, amount));
    require(canReceive(to), ERC7943CannotTransfer(from, to, amount));
    if (msg.sender == from) return true;
    if (ramsRegistry.getMandate(msg.sender, from).principal == address(0)) return true; // plain allowance, no mandate
    bytes32 action = bytes32(IERC20.transferFrom.selector);
    return ramsRegistry.canExecute(msg.sender, from, address(this), action, amount);
}

// This works because ERC-7943 declares canTransfer ON THE TOKEN,
// so msg.sender inside it really is the agent.
// ERC-3643 declares canTransfer on ICompliance, a different contract,
// where msg.sender is the token. The pattern does not port.

That pseudocode is correct for the standard it targets. ERC-7943 declares canTransfer on the token itself, so msg.sender inside it genuinely is the agent and the check has everything it needs. ERC-3643 declares canTransfer on ICompliance, a different contract, so msg.sender inside it is the token. The published pattern cannot see the agent there. It is not that it works badly. It cannot run.

So what would integrating a mandate layer with ERC-3643 actually take? The check has to live in the token’s own transferFrom override, before the call out to compliance, because that is the last place the caller still exists. The EIP never says this. Its reference implementation ships an ERC-7943 asset integration, an executor and a compliance provider, and no ERC-3643 path at all.

I do not think anyone hid this. I think it is what happens when a composition story gets tested against the standard the authors already knew well. That is the one narrow place the shared authorship matters: the integration is best-tested against ERC-7943 and least-tested against ERC-3643, which is the more widely deployed of the two.

Nobody in the thread has raised it. It is not an unanswered question in the corpus, it is an unexamined assumption, and I am raising it here as somebody who has to live with the socket rather than as somebody scoring a point.

The regulator tiers that were announced and never shipped

One more thing changed between the announcement and the merged spec, and it is the one a regulated business should care about most.

The April 2026 forum announcement made two regulatory promises. Neither survived into the standard.

The second row is the interesting one, and it is not a criticism of the reversal. The one-principal rule was dropped for a good reason: a reader asked in June how multi-client portfolio managers would work, and the answer, that one mandate per pair permits many principals per agent, is plainly the better design. But the justification went out with the rule. The original design was defended by naming three regulatory frameworks and their account-segregation requirements. The rule changed, nobody asked what satisfies segregation now, and those three names appear nowhere in the standard.

I am not going to tell you what those regulations require. I am not a lawyer, and this article stays on the engineering side of that line. The engineering question is the one nobody in the thread asked, and I can ask it from the position of somebody who has had to answer it inside a regulated business: if a rule existed because of a segregation obligation, and the rule is gone, what carries the obligation now? "The interface is agnostic" has never once been an acceptable answer to that question, because at the end of it somebody signs.

The third row deserves a sentence of its own. The mandate can point at the power of attorney, and the standard forbids you from relying on the pointer. The chain holds a reference to the legal document and no integrator is allowed to make an enforcement decision from it. That is honest engineering. It is also exactly the seam where an auditor will ask you what you did instead.

Can your token verify this agent?

A word on the phrase in the title, because it already has a commercial owner. Sumsub launched an AI Agent Verification product called Know Your Agent on 2026-01-29, binding AI agents to verified human identities so that every action is linked to the person responsible, with a liveness test in high-risk cases.

I checked that announcement for exactly one thing: whether any of it lands on-chain. It does not mention blockchain anywhere. That is not a criticism of the product, which solves a real problem. It is the whole problem in one sentence. The leading commercial Know Your Agent check is entirely off-chain, and a permissioned token making a decision inside a transfer cannot consume it.

So here is the honest answer for anyone shipping in the next twelve months.

What I would ship while the standards argue

Three moves, none of which needs a Final agent standard, and all of which get harder the longer you leave them.

What that evidence actually has to look like when somebody asks for it is a whole subject on its own, and I wrote an episode on proving an agent's work to an auditor about exactly that.

The containment side of the same problem, scoping what an agent may do before it does it, is in least privilege for agents that move money, and the payment rail underneath all of this is in the previous episode.

Back to March. I proposed four functions in that forum post: authorize, revoke, principalOf and getAuthority, with the idea that principalOf would return the input unchanged for non-agents so integration would be one line with no branching. The lead author of ERC-8226 replied to me directly, said the gap was real and well articulated, and then explained why four functions were not enough. He was right, and I would rather quote him than dodge him.

What I still think is true is narrower than what I posted in March, and harder. Resolving the principal is the easy half. The half nobody has closed is that the compliance layer of the most widely deployed permissioned token standard, the thing that actually decides yes or no, cannot see the caller at all. Five merged proposals, zero Final, one Draft that tries, and a socket that takes three arguments.

That is the state of it on 5 August 2026. I will update this when the count changes.

FAQ