We Are Building Guardrails in the Wrong Places

I have watched a great many agent demos this year, and I have started to notice what they all have in common. They end at the moment of success. The agent parses the request, reasons its way through a few tools, executes, and the room applauds. Fifteen seconds, start to finish, and the thing that gets applauded is capability.

I have not yet seen the other demo. The one where somebody asks the agent to do something it should not do, and something other than the model's own good manners says no.

Key Takeaways

• The three prevailing placements for agent policy produce constraints that are public, constraints that are captive, or constraints that are not constraints at all.
• On-chain policy is real enforcement, but publishing a rule publishes an intent that adversarial agents and markets can optimize against.
• Wallet-level policy works, and quietly converts your risk posture into a property of your vendor's footprint.
• Application-level policy is a suggestion made by the process that has an interest in bypassing it.
• The position worth occupying sits above custody and below the application, evaluating at the moment of the signing decision rather than at the moment of broadcast.
• Identity is becoming portable while policy is not. A portable identity with non-portable constraints is an agent whose credibility outruns its leash.

That demo is harder to build, which is presumably why nobody builds it. But it is also the only demo that matters the moment there is a treasury attached, because the first one is a party trick and the second one is a product. Right now we are largely outsourcing that job to the model's conscience, which is a peculiar thing to do given that we have known better for about seventy years. Asimov wrote three laws directly into the positronic brain and then spent an entire career writing stories about the loopholes, because the loopholes were the interesting part. We appear to have read the stories and adopted the architecture.

The oldest known solution

The literature actually solved this a long time ago, and the solution is worth revisiting because we tend to remember the wrong half of it.

Ulysses wants to hear the sirens. He knows that the version of himself who hears them will not be the version of himself who is currently reasoning about this. So he binds himself to the mast. Everyone remembers the rope.

The rope is not the mechanism. The mechanism is the wax in the crew's ears. Ulysses could scream to be released, and did, and the system could not hear him. The constraint was unreachable by the thing it constrained. That is the entire design, and three thousand years later it is still the specification: rules set by the rational actor, enforced by a layer the compromised actor cannot reach, negotiate with, or reconfigure in the moment of temptation.

Now hold that next to how we are actually building policy for autonomous agents. We have three prevailing answers. I think all three of them put the wax in the wrong place.

Answer one: put the rules on-chain

Let me steelman this properly, because it is where the ideology says policy belongs and the ideology is not stupid.

On-chain enforcement is real enforcement. A contract does not have a bad day. It does not get socially engineered, it does not have a context window, and it does not require you to trust the party running it. If you want a constraint that no operator can quietly relax on a Friday afternoon, this is the strongest primitive we have ever built. I understand the appeal completely.

The problem is that we have already run this experiment, in public, at enormous cost, and we appear to be about to forget the result.

We spent years calling the public mempool transparency. It was a value, it was in the pitch decks, it was the thing that made us better than the incumbents. And then we learned, slowly and expensively, that broadcasting your intent into a room full of faster readers is not transparency. It is a donation. We invented an entire vocabulary for the consequences, we built private orderflow to escape it, and Flashbots exists because the industry eventually conceded that some information is only safe if it is not legible before it settles.

A published policy is a published intent. Read it as a document rather than a rule and see what you have handed over: spending caps, counterparty allowlists, escalation thresholds, the exact boundary below which nothing gets flagged. To a human observer that is disclosure. To an adversarial agent that reads chain state faster than you read your notifications, that is a specification for how to approach you without ever tripping a wire. Every rule you publish is a rule someone else optimizes against, and the optimizer is not tired at 3am.

There is also the unglamorous version of the same objection, which is that no treasury desk on earth wants its internal risk framework permanently legible to its counterparties. The moment the participants are automated, transparency stops being a feature and starts being an attack surface. Same property, different adversary, opposite sign.

I return to this argument at length, and give the on-chain position the defense it deserved, in the chain was never the problem.

Answer two: put the rules at the wallet

This is the answer I have the most sympathy for, because it works, and because the people who built it built it well.

Safe modules did this properly. Session keys under account abstraction do this properly. The custodian holds the key, the custodian evaluates the rule, and the custodian declines to sign what the policy forbids. The enforcement is genuine, the ergonomics are the best available, and the wax is at least in the right vicinity: the caller can ask, and the layer that holds the signing authority can say no.

The trouble is what the rule has quietly become. It is now a property of your vendor.

Your policy is portable exactly as far as that vendor's footprint extends and not one inch further. Change custody arrangements and the rules do not come with you. Move the agent onto a chain the vendor does not support, a rail it does not settle on, a jurisdiction it does not serve, and you are reimplementing your risk posture from memory in a new console, hoping you remember all of it. You purchased enforcement by selling interoperability. Most teams have not noticed the trade yet, for the simple reason that their agent has not left home.

And I would gently point out that the vendor is not incentivized to fix this. A policy engine that travels is a policy engine that makes the vendor swappable. Nobody has to be acting in bad faith for this to bend one way. It is not malice, it is gravity. Every custodian's policy layer will drift toward that custodian's rails eventually, because that is what the org chart rewards.

Answer three: put the rules in the application

This is the most common answer in production today and by a comfortable margin the weakest.

Rules in the application are not enforcement. They are a suggestion made by the same process that has an interest in bypassing them. Same address space, same trust boundary, same author. The agent is not an attacker here, to be clear. It is worse than that: it is an extremely fast, extremely literal optimizer with a plan and a context window full of alternate routes to the objective you gave it. If a rule is a function it can reach, it is a function it can route around, and it will not even experience that as cheating. It will experience that as solving the problem you set.

Ulysses with a knife in his pocket is not bound to anything. He is standing near a mast.

So what have we actually been choosing between

Constraints that are public. Constraints that are captive. And constraints that are not constraints.

That is a genuinely poor menu, and I do not think it is a menu anybody designed on purpose. I think it is what you get when policy is treated as a feature of whatever layer happened to have the key, rather than as a thing with its own architectural requirements.

The fourth position

There is a place none of the three occupies. Above custody. Below the application. Enforcement at the moment of the signing decision rather than at the moment of broadcast.

Let me make that concrete, because I have been defining it mostly by what it is not, and that is a cheap way to argue.

An agent is running a procurement task. It decides to pay a supplier, builds the transaction, and asks for a signature. In the prevailing architecture it asks the custodian, and the custodian is holding both the key and the rules, which is exactly why the rules cease to exist the moment you change custodians.

In the fourth position the agent does not have the custodian's address. It cannot have it. The only route to a signature runs through evaluation, and evaluation happens somewhere the agent cannot call directly, cannot reconfigure, and cannot negotiate with. The request arrives carrying the agent's identity rather than its credentials. The layer resolves what that identity is permitted to do, checks the counterparty against it, checks the amount against it, checks the chain and the rail against it, and only then turns around and requests a signature from whichever custodian happens to hold the key for that particular venue. If the check fails, the custodian is never asked. No signature is produced, because none was ever requested. There is nothing to broadcast, nothing to revert, and nothing sitting in a mempool for anyone to read.

Two things fall out of that sequence that are easy to skim past, and both of them are the point.

The custodian never sees the rules. It sees a signing request that has already been adjudicated, and it does the job it is actually excellent at, which is holding a key well. The chain never sees the rules either. It sees a signed transaction, indistinguishable from any other signed transaction, revealing nothing about the thousand transactions that were declined before it. The policy did its entire work inside the gap between intent and signature, which is the only place in the pipeline where a decision is still reversible and not yet public. That gap is the whole asset. Everything upstream of it is a suggestion and everything downstream of it is a receipt.

Then swap the custodian tomorrow. Add a second one for a chain the first does not serve. Move the agent onto a rail nobody had heard of when you wrote the rules. Nothing about the policy moves, because the policy was never there. The constraints are attached to the agent, and the custodian goes back to being what it should have been all along: a very good key holder, rather than the arbiter of what your treasury is permitted to do.

The properties that fall out of that position are, I think, the ones we actually wanted the whole time.

Rules evaluated before a signature exists, rather than audited after a transaction is visible. This distinction sounds academic until you sit with it. A rule enforced pre-signature is policy. A rule observed post-broadcast is a post-mortem with better tooling. Most of what currently gets sold as agent policy is the second thing wearing the first thing's clothes.

Rules that are opaque to observers and non-negotiable to the caller at the same time. This reads as a contradiction only because we spent a decade coupling transparency and enforceability, and that coupling was a convention, not a law of physics. The wax in the crew's ears was never public. It did not need to be. It needed to be unreachable.

And rules that bind to the agent's identity rather than to the agent's venue. Which is the part I think this ecosystem is most underweighting right now.

Identity is portable. Why isn't policy?

We are doing genuinely good work on portable agent identity. ERC-8004 exists because enough people independently arrived at the conclusion that an agent needs a durable, verifiable sense of who it is that survives leaving any particular room. The reasoning there is sound and the community around it is serious.

But notice the asymmetry we are building into the stack. Identity travels. Policy does not. We are constructing agents that carry their name, their reputation, and their provenance across every chain and rail they touch, and then leaving their constraints behind at the door of whichever venue they started in.

That is half a system. It is arguably the more dangerous half, because a portable identity with non-portable constraints is precisely an agent whose credibility outruns its leash.

Sit with what that means in practice.

Your agent has been running procurement on one chain for eight months. Clean history, every counterparty check passed, and a reputation that is now a genuine balance sheet asset, because it is the thing that makes other people's agents willing to transact size with it without a human anywhere in the loop. Its policy lives at the custodian you started with. This has been fine. It has never gone anywhere.

Then a task takes it to a rail that custodian does not serve.

The identity arrives intact. It has to. That is the entire point of portable identity and the design is correct. The reputation arrives with it, and the reputation is precisely what opens the door, because the counterparty on the other side runs its check, reads eight months of spotless behavior, and extends trust accordingly.

The constraints do not arrive. There was never a mechanism by which they could.

So the agent walks into a venue it has never operated in, at the exact moment of its maximum accrued credibility and its minimum enforced restraint, and every party it meets there is reading its history as a reason to be less careful with it. If it is compromised, or merely mis-specified, or simply executing what you asked in a context where what you asked turns out to be a catastrophe, the resulting transaction is signed by an identity with a flawless record. It clears every check anyone would think to run. The reputation does not flag the failure. The reputation is what funded it.

That is the shape of the thing that actually worries me, and notice that it is not the story we like to tell. The popular version has a rogue agent in it, because a villain is easier to hold in your head. The realistic version is a perfectly obedient agent carrying a laundered credential into a room where nothing it brought with it is able to say no.

The premise of a machine economy is that software transacts across whatever surface the task requires, continuously, without asking permission and without a human in the loop deciding which rail is appropriate this morning. If that premise is right, then any constraint that is a property of a venue is a constraint that evaporates at the venue boundary. You did not build a guardrail. You built a guardrail-shaped object that performs beautifully right up until the first moment it matters.

Constraints have to travel with the agent, not with the agent's infrastructure. If your policy cannot survive a chain migration or a custodian change, you do not have a policy. You have a vendor's preference. Why that is not solved by portable reputation either is the subject of the score travels, the reason it was earned doesn't.

The uncomfortable part

The fourth position only works if whoever occupies it is neutral, and neutrality is not a nice-to-have in this design. It is the load-bearing wall.

A policy layer operated by a custodian is a custodian's policy layer. A policy layer operated by a chain is a chain's policy layer. Both will bend, over a long enough horizon, toward the rails of the entity paying for them. So the position has a strange requirement attached to it: it has to be occupied by somebody who does not benefit from where the transaction ultimately goes.

That is a hard thing to claim and a very easy thing to say, and I am fully aware that a founder writing this paragraph is not a neutral observer of it. This is the problem we are working on at Abstraxn, and it is why we are working on the enforcement position rather than the rule set. Rules are cheap. Anybody can write a policy, and by the end of this year a great many people will be selling you one. Nobody has answered the harder question, which is where a rule can live such that it is portable across chains, portable across custodians, opaque to adversaries, and unreachable by the thing it governs.

I will also say the quiet part, since we are here. Nothing about that position can be asserted. Neutrality is a claim that has to be earned in public, over years, through audits and boring track record and the accumulated absence of self-dealing. Anybody who tells you they have it on day one, very much including me, should be read carefully.

Where I might be wrong

I do not think this question is settled. I think it is the most important unsolved problem in agentic infrastructure, and I think it is currently being treated as a configuration screen in somebody's dashboard.

But I have put the boundary in a specific place, and boundaries drawn by people with an interest in where they land deserve scrutiny. If you think enforcement belongs somewhere else, or that the transparency objection is overstated, or that the vendor gravity problem solves itself through competition, I would like to hear it properly rather than politely.

This is the argument I would most like to be wrong about, and so far nobody has managed it.

FAQ

See policy enforcement bound to agent identity on the Abstraxn dashboard