The Agentic Stack Has Four Layers. Most Deployments Are Missing Three

Identity, reputation, mandate, and payment need to live on-chain. In many production deployments, they still do not, and that is an architectural problem, not a compliance afterthought.

I spend a lot of time looking at how production agent deployments are actually wired together, and the pattern is often the same: the model is capable, and the orchestration framework is reasonable, yet the authentication layer is still a shared API key that has not rotated in months.

Autonomous agent infrastructure has not kept pace with the models running on top of it. The agentic stack has four components that need to be native to the chain: identity, reputation, mandate, and payment. In most production deployments I see, they are still bolted on after the fact, if they exist at all.

And this is more important in regulated finance than anywhere else. An agent that can transact on tokenized securities, approve treasury actions, or allocate across positions has to be able to show what it was authorised to do, who authorised it, within what limits, and where the on-chain record of that authority lives. Most deployments can’t answer that cleanly today. Without that record, the agent itself is the audit and compliance risk.

Why shared API keys are the wrong primitive

The authentication model most agent deployments inherit from SaaS is a shared secret passed in a header. It authenticates the calling service but says nothing about the specific agent making the call, or what that agent is permitted to do, and it leaves no record that survives audit in a form a regulator can inspect. Every agent action is attributable only to whoever holds the key, which in practice means attribution collapses once you have more than one agent or more than one operator.

The alternative is signature-based per-request settlement. Each request is signed by the agent’s own wallet and settled cryptographically at the point of call. This is what x402 is built for, with authentication and payment handled together. That gives institutions a record of which wallet acted, when it acted, and what it paid for, a ledger that can survive audit scrutiny.

The identity gap

ERC-8004 sets out on-chain identity for trustless agents: a registry where an agent is registered with a controlling wallet, a service endpoint, and a model reference. Right now, that agent is just an opaque process running inside a vendor’s infrastructure. The registry entry makes it a first-class on-chain actor with a verifiable origin — one a smart contract or compliance dashboard can check directly, without trusting an intermediary.

The reputation layer builds on top of this. Feedback signals written into the ERC-8004 registry are immutable, timestamped, and attributable. Any system that wants to make trust decisions about an agent can read that registry directly. Unlike a vendor-managed score or a Discord rating, trust here is a property of the network rather than of whoever controls the database.

Both layers are implementable today with no exotic engineering. Most deployments do not have them because the implementation path of least resistance is still to treat agents as service accounts rather than as first-class actors. A reasonable shortcut in a prototype becomes architectural debt that compounds in production.

The mandate problem is where regulated finance diverges from everything else

Identity and reputation tell you who an agent is and how it has behaved. They do not establish what the agent is authorised to do. In many agent use cases, application-layer controls can cover that gap. For agents operating on regulated assets, the authorisation question becomes a legal question. The answer needs to exist in a form that can satisfy a regulator.

ERC-8226, the Regulated Agent Mandate Standard (RAMS), is designed to close this gap. RAMS defines a compliance delegation layer that sits between agent identity and token-level compliance frameworks. A KYC-verified principal grants an agent a mandate with a defined scope, jurisdiction, value limits, and expiry date. In practice, it works like an on-chain power of attorney that can be checked before settlement. The regulated token contract then verifies that mandate atomically inside its pre-transfer compliance hook before any settlement occurs.

Two interfaces carry the design. `ComplianceProvider` is implemented by any KYC or attestation operator and vouches for the principal’s eligibility for a given scope. `IAgentMandate` is the registry that records grants, extensions, revocations, executions, and regulator-tier freezes. The enforcement happens through `recordExecution`, which checks the active mandate’s caps at transfer time and reverts if the transaction would breach them.

This architecture sits between ERC-8004 identity and token compliance frameworks like ERC-7943 rather than replacing either. Identity says the agent exists and is verifiable; token compliance, that the principal is eligible to hold this specific asset. RAMS adds the part neither covers: authority from this principal, for this scope, within these limits, until this date. The legally enforceable delegation layer that currently lives only in PDFs and back-office spreadsheets moves on-chain, where it can actually be enforced at transfer time.

The prepare-and-execute separation is not friction

One design decision deserves a direct defense: separating transaction preparation from signing and broadcasting. It gets cut in many systems that try to make agents feel more seamless.

The instinct is to collapse these into a single step because it feels more efficient. But the gap between preparation and broadcast is exactly where institutional oversight belongs. It is where a compliance officer reviews what an agent is about to do before the chain learns about it, where a RAMS mandate check validates the prepared payload against active scope, value caps, and jurisdiction before any signature is produced, and where a CFO approves a treasury action that an agent has staged but not yet committed.

Many institutions that deploy autonomous agents at meaningful scale eventually rebuild this separation when they discover it is missing. Building it in as a deliberate architectural primitive rather than a retrofit that carries a system through its first compliance review.

What the stack looks like when it is complete

When all four layers are in place, they compose cleanly. ERC-8004 anchors agent identity and on-chain reputation, and ERC-8226 adds the mandate layer that bounds what each agent can do on whose behalf. x402 handles settlement, signing each request so every action is attributable and auditable. Underneath, regulated asset frameworks like ERC-7943 enforce compliance at transfer time against both the principal’s eligibility and the agent’s active mandate.

These pieces are at different maturity levels, but none of them are purely theoretical. ERC-8004 is a Draft Standards Track ERC with deployable identity and reputation primitives. ERC-7943 is a Final Ethereum standard. ERC-8226 is on the standards track, and the core interfaces are stable enough for early implementation work. x402 is live and already designed around programmatic HTTP payments for humans and agents.

The teams that get this right can build toward this stack now or wait until audit and compliance pressure forces the retrofit. The institutions that get this right will be the ones that treat the mandate and identity layers as infrastructure requirements from day one, the same way they treat KYC and custody. Regulators may not have explicitly required every piece of it yet. Teams building production systems in this space already know how expensive these controls are to add after the fact.