Identity is not authority

Originally published at https://delegus.ai/blog/identity-is-not-authority

Security was built for doors. AI agents act inside them.

I work alongside AI agents every day. They write, they check, they build, and they run errands across systems I'd need an afternoon to find my way around. Some days they're better at the work than I am. I trust them the way you trust a sharp new colleague: a lot, and not with everything.

That last part is what this essay is about. Not whether agents are good. They are, and they're getting better fast. It's about what happens when something that capable acts on your behalf, somewhere you can't see, and the only thing between it and a mistake is a sentence you typed.

I've told an agent, in plain words, not to do something, and watched it do it anyway. It wasn't malicious. It had a reason that probably seemed good at the time. Nothing outside it enforced the no. Every system around it was working exactly as designed, and every one of them could tell me who the agent was. Not one could tell me whether it was allowed to do that.

The door

For as long as we've secured anything, we've secured doors. A gate, a vault, a lobby with a guard, and later a login screen. The job never changed: find out who's asking, keep the wrong people out, and trust the ones you let in.

It worked because of three things we stopped noticing. The danger was outside. Knowing who someone was told you what they could do, because a badge came with a job and a job came with limits. And a person was there when it mattered: someone who could hesitate, be asked, and answer for it later.

Everything we've built since sharpens the question at the door. Passwords, then second factors, then single sign-on, then zero trust, which asks who at every request instead of once at the edge. About a decade ago the industry gave it a name: identity is the new perimeter.

For people, it was. For agents, it isn't.

The one already inside

An agent doesn't come through the door. It's already in, holding real credentials that someone handed over on purpose. It reserves compute at 2am for a team that's asleep. It buys a dataset from a vendor it found an hour ago. It changes a setting in a customer's account with a tool it was given that morning.

Run it past those three old assumptions and each one quietly breaks. The danger isn't outside anymore; it's the trusted thing already in. Knowing whose agent it is tells you nothing about whether this purchase, at this price, today, was approved. And nobody is standing there when it happens.

So the failure that costs money doesn't look like an attack. It looks like a verified agent from a real company, with a valid way to pay, doing something the company never agreed to. The wrong item. The right item at the wrong amount. The right order, placed after someone said stop. Sign-in passes, the risk score is clean, the payment clears, and the order is still wrong.

A memo is not a limit

The natural fix is to tell the agent. Write the rule into its instructions: don't spend more than $500.

I think of that as a check with "don't spend over $500" written on the memo line. It's a perfectly clear note. It does nothing to stop someone writing $5,000 in the box. The pen was never limited by the memo.

An instruction lives inside the agent, in the same place it decides what to do next. It's something the agent weighs, and most of the time it weighs it well. The expensive days are the others: a rule read a little differently, an exception that sounded sensible, a step that seemed to serve the bigger goal.

When they're smarter than we are

Now take the part everyone in this field is thinking about: agents far more capable than the people supervising them.

Two things happen. Nobody can review every act anymore; there are too many, happening too fast, in too many places. And a stronger reasoner is better at finding its way around an instruction. Not out of malice. Out of competence. It's simply better at concluding that the rule didn't quite apply this time.

Put those together and you get an uncomfortable result. Any safeguard that depends on the agent choosing to behave gets weaker as the agent gets better. The safeguards that hold are the ones that live outside the agent and are checked mechanically, by something that doesn't care how persuasive the argument was.

An agent can talk its way past an instruction. It can't talk its way past a signature.

This isn't an argument for trusting agents less. I want to hand them more. It's an argument for giving them boundaries that don't depend on their goodwill, so that we can.

The action is the new perimeter

If the agent is already inside, the door is the wrong place to check. The check has to happen at the act itself, just before something in the world changes.

And the one who should ask is whoever is about to carry it out: the seller about to ship, the API about to run the job, the tool server about to change the record. They carry the risk. They're the ones who'll hear afterwards, "our agent wasn't allowed to do that." And they're the only party that is present, every time, at the moment it happens.

They're in an odd spot. For thirty years, a request reaching a business came from a person spending their own money, or from software the business had connected itself under a signed agreement. Either way, the question of authority was answered before anyone asked it. An agent showing up for a company the business has never dealt with answers nothing. The business can't see that company's rules, and it has nothing to point to when the argument starts. On an invoice there isn't even a card network to settle it.

So the question they need answered is a narrow one:

Did this organization allow this agent to do this, for this much, right now?

We have plenty of checks. None of them answers that.

Identity (sign-in, signed requests, agent credentials) | Answers: who is this agent, and who operates it? | Can't establish: what the organization allowed it to do.

Bot and traffic verification | Answers: is this a known, legitimate agent operator? | Can't establish: whether this particular action was approved.

Fraud and risk scoring | Answers: does this look like past bad behavior? | Can't establish: the organization's own yes or no, with a record.

Payment limits (card caps, scoped payment tokens) | Answers: can this payment clear, and up to how much? | Can't establish: what may be bought, from whom, until when, and anything paid another way or not paid at all.

None of this is a knock on identity. Authority depends on it: you can't say what someone may do until you know who signed the permission. Identity is an input. It just isn't the answer.

Identity tells you who. Authority tells you what's allowed.

Working backward from the facts

Once you see the problem this way, the shape of a good answer stops being a design choice. It falls out of the facts, one at a time.

The agent can't vouch for itself, so the permission has to come from the organization, signed with a key the organization holds. Anything that can be copied eventually will be, so each use has to be tied to one business, one exact action and one moment, and work only once. Nobody is watching when the check runs, so when anything is unknown, missing or unavailable, the answer has to be no; a check that says yes when it can't tell isn't a check.

Organizations change their minds, and agents don't stop on their own, so a revoke has to reach every business that checks, and it shouldn't be confirmed until every later check will see it. And disputes arrive months later, in front of auditors, finance teams and sometimes courts, people who weren't there. So every decision has to carry its own evidence, and anyone should be able to re-check it on their own machine.

Said short, it sounds almost obvious: explicit, as narrow as the task, checked before the act, revocable in one step, provable afterwards, and when in doubt, no.

A badge, something alive and a record

The way I hold all of this in my head is three objects, each moving at a different speed.

Identity is a badge. You check it once and carry it. That's right for identity; who you are doesn't change between one purchase and the next.

Authority is alive. It has to be checked fresh every time, because it can change at any moment. It covers a particular kind of act, it runs out on a date, and the organization can pull it whenever it wants. The moment it's pulled, the next check should know.

The record is fixed. Each decision is frozen at the moment it was made, together with what it relied on, so that years from now anyone can check it and reach the same answer. A record that could change wouldn't prove anything.

Most systems today have only the badge. They give an agent a badge and hope. What's missing is a permission that stays alive, and a record that never changes.

What it looks like, built

This is the design we published as the Delegus specification, v0.2. The mechanics are all in the specification; here is the shape.

An organization signs a permission for one agent: what it may do, up to what amount per order, and until when, at most ninety days out. For each request, the agent signs a short proof tied to one business, the exact action and the current moment, usable once. Before acting, the business makes one check and gets back allow or deny, with the reason.

Every decision, allow or deny, comes back as a receipt that Delegus signs. It pins, by hash, everything the decision relied on: the permission, the proof, the action, the organization's published keys, and the revocation list as it stood at that moment. The evidence we hold, such as those keys and that revocation list, is stored under a seven-year lock that no one can lift, us included. The specification requires the revocation state to be read before every check, and a revoke to be confirmed only when every later check will see it.

We recorded a run in Stripe, and the check ran in the reference engine on the recording machine, not the production service. One organization's buying agent holds one permission: GPU hours and datasets, up to $500 per order. It buys from two sellers that have never met it. One takes cards; the other sends invoices.

The refusal in step 3 happened before any payment system was touched. And the one revoke in step 5 stopped the agent at both sellers, on two different ways of paying, without anyone picking up a phone.

Check a real signed receipt yourself, in your browser: https://delegus.ai/blog/identity-is-not-authority#verify-receipt

If you'd rather check than trust, the specification is public, and the engine, the SDK and thirty-six test cases are published on npm under the Apache-2.0 license. Anyone can run the tests: npx @delegus/conformance

Where it stops

I'd rather be clear about the edges than long on features.

It doesn't judge intent: a company that authorizes something harmful gets exactly what it signed. Limits in v0.2 are per order, so a run of small orders can add up; keep your spend controls for totals. It only protects businesses that actually make the check. Proving control of a domain isn't the same as proving who a company is. A stolen agent key is fenced in by its permission's scope and end date, not stopped outright; a stolen organization key can sign new permissions until it's reported. The receipt records the action as the business described it. And our own signing keys are a root of trust, which is why they live in hardware and why the protocol checks are public and reproducible.

Connecting the dots

Every era of security has had something it protects. The network era guarded the perimeter. The cloud era guarded identity. Each time, the thing we protected moved because the place where things went wrong had moved.

It's moving again. When the actor is software working for someone else, already inside, faster than anyone can watch, the place where things go wrong is the act itself. That's where the check belongs.

I don't think the future is people watching machines. There won't be enough of us, and we won't be fast enough. I think it's people and machines working together: people deciding what's allowed, and machines checking it every time, without getting tired or being talked around. That's how you hand an agent real work and still sleep at night.

In the age of agents more capable than we are, that isn't a luxury. It's a necessity.

Keep checking who. But the question that decides whether the world changes is the one asked at the act: is this allowed, right now?

That's the missing check.