Why AI agents need permission systems

Someone read Noesia's architecture and asked me the only question that mattered: what stops the agent from buying something stupid? I had an answer for the happy path and nothing for that one. It took me a week to find the honest version, and the honest version is not a settings screen.

Here is what I found. AI agent permissions are usually described as a limit: a maximum amount, a merchant allowlist, a monthly ceiling. Limits are necessary and they are not a permission system. A limit tells the agent where the wall is. It does not tell anyone who allowed the action, under which rule, or what happens when the rule turns out to be wrong.

Three ways people handle agent spending today

• The shared card. The agent uses a company card with no boundary. Finance finds out from the statement, and nobody can reconstruct why the purchase happened.
• The confirmation button. The agent proposes, a human approves every single time. It is safe, and it turns the agent into an assistant that sends you invoices.
• Declared autonomy. The product executes and puts the outcome on the user. It is the most common position in this category, and it is the easiest one to write down.

None of the three is stupid. The first two are what people actually do today, and the third is a legitimate position I disagree with. What all three share is a missing record: in all three, the question who authorised this, and under which boundary has no answer that survives an argument.

What a permission system actually is

A permission system has four parts, and a limit is only one of them.

• A mandate. The outcome you asked for, in your own words, written before the agent starts. Not an interface guessing what you will allow.
• A perimeter. Amount, period, payees, categories. What the mandate does not cover, the agent cannot do, even when doing it would be a good idea.
• A decision. Deterministic, explainable, replayable. The same input produces the same answer, and a human who was not in the room can read it.
• A record. Who acted, for which task, under which rule, with what evidence.

In Noesia's authorization engine the decision path has no model in it. It is a policy engine written in Go, and the ledger it appends to is hash-chained. That is not a detail about our stack. It is the only thing that makes the fourth part worth anything: a record nobody can quietly edit is the difference between an audit and a story.

The property I care about most is boring to write down and hard to get right: idempotency under concurrent retries. The authorization core is tested with 100 parallel identical requests, and exactly one decision comes out. That test exists because an agent that retries is normal, and an agent that charges twice because it retried is a bug with a bank account attached. I wrote about the idempotent version of this problem before the buyer was an agent.

The difference between an instruction and a permission

An instruction describes intent. A permission describes authority. The distinction looks academic until you put an agent in front of a web page, because an agent that reads can be told things. If the authority to spend came from the conversation, then whoever can write into the conversation can spend. That is not a hypothetical attack, it is the normal way the web works.

A mandate written before the conversation changes what a prompt injection can do. The injected text can still change what the agent tries. It cannot change what the agent is allowed to do, because the authority was never in the conversation. This is why I think the mandate has to be a document you sign rather than a form you fill in the moment the agent asks.

The part we do not have yet

I would rather write this than have it found later. Agent identity and liability is the row of our own capability table marked as not answered. If an agent buys the wrong thing while doing exactly what it was told, who answers? Every platform in this category states a position. We do not have the final one, and it is not a paragraph to write: it is a product and a legal decision that has to survive a real dispute.

What we do have is the piece that makes the question answerable later: a stop. Pausing an agent and cancelling its pending requests from your device is designed and not shipped. The closest thing verified today lives in the prototype: an order came back at 163.00 euro as a request to confirm, and it left at 137.00. One number from a prototype run is worth more than the adjective I would otherwise have used in this paragraph, and it is why the prototype is labelled as one on every page that shows it.

What I would tell someone shipping an agent this month

• Write the boundary before the agent runs, not after it fails. A boundary added later has no record of what already happened.
• Key the retry on the intent, not on the request. Two identical requests are one intention, and one charge.
• Make the decision readable by someone who was not there. If explaining a spend needs the conversation that produced it, you do not have an audit trail.
• Decide what happens when the agent is wrong before you decide how fast it can buy. The second number is easier to change.

The reason I keep coming back to permissions is that they are the only part of this that has to be decided before the money moves. Everything else can be added later. An authorization layer cannot be retrofitted onto a system that already spends, because by then the evidence of what it did is gone.

Agents do not need a bigger allowance. They need a boundary that can be read out loud, and a receipt that survives being questioned. I have been building this problem into Noesia, the authorization layer for agents, and the money layer argument is where it started. If you are building an agent that spends, I would rather hear where this breaks than where it works.