Why AI cannot grant itself permission

Imagine a retail chain that needs to send a promotional email on Friday evening. Not long ago, that took a marketer to prepare the list, a designer to make the artwork, and an engineer to press send. Today an AI assistant can do all three in a few minutes. Things move faster, but one question matters more than ever: who said it could press send?

Our answer is simple. AI can do a lot, but "may it?" is not a question it gets to answer for itself. That is not because AI isn't smart enough. Permission is a kind of promise. Letting a system decide what it is allowed to do is like letting a new colleague approve their own expense claims. Even the most honest person shouldn't be put in that position.

This post explains how we take "may it?" out of the AI's hands, give it to a separate governance layer, and leave the final decision with people.

Every request passes six gates

When an AI wants to do something, whether that's reading a document, changing a field or sending an email to the outside world, the request passes through six gates in order. The order is fixed. If any gate says no, the request stops there, and the reason is recorded.

• Identity: first, establish who is asking: which AI, on behalf of which person, inside which piece of work. A request that can't say who it is doesn't get in.
• Permission: deny by default. Anything not explicitly allowed is treated as not allowed. "Nobody said no" doesn't count as yes.
• Confirmation card: any action that changes the outside world is first turned into a card for a person to confirm. It goes ahead only after they agree.
• Execute with a lock: only one executor can work on a given task at a time, so two AIs can't edit the same list at once and overwrite each other.
• Append-only record: what was done, who approved it and what happened are written to an event log that is only ever added to.
• Rate limit: even if every step is allowed, the same thing can't be repeated too many times in a short window. One small mistake can't turn into a thousand.

None of these gates is a new invention. Banks, hospitals and airlines have long managed high-risk operations in similar ways. All we do is apply that common sense fully to AI, with no back door.

External actions have only three outcomes

Inside the company, if editing a document fails, you can just try again. But sending an email, placing an order or creating a record in someone else's system can't be taken back once it happens. Worse, the network sometimes drops halfway: you sent the request but never got a reply.

So we sort the result of every external action into three outcomes, not just success or failure:

• Done: the other side clearly confirmed it received and processed the request.
• Not done: the other side clearly said it did not process the request, or the request never went out.
• Uncertain: the request was sent, but no clear answer came back.

The third is the dangerous one. The instinct is to send again, but if the first attempt actually worked, customers get the same promotional email twice. So the rule is: when uncertain, reconcile before you decide whether to retry. That means checking the real state of the other system to confirm whether the action actually happened.

The second safeguard is an idempotency key. Every external action carries a unique number from its first attempt, and a retry reuses that same number. When the other system sees it, it knows this is the same request and doesn't act on it a second time. Reconciliation plus an idempotency key turns a retry from a leap of faith into something you can do with confidence.

Some things are never handed to AI

A short list of things is never delegated to AI, however well it performs and however good its reasons:

• Payments and any movement of money.
• Deleting data, especially deletions that can't be undone.
• Changing permissions, including granting permissions to itself or to another AI.
• Entering or holding passwords and other sign-in credentials.

What these have in common is that mistakes are costly and hard to undo. AI can help prepare, for example by listing what needs paying or which files are up for deletion. But the person who presses the final button is always a person.

AI can pave the road to the door, but it doesn't hold the key.

Changing permissions deserves a special mention. If an AI could grant itself permissions, the six gates would mean nothing. So permission settings themselves sit where AI can't touch them.

AI proposes, a person decides in one line

Keeping decisions with people sounds as if it would slow things down. If someone had to read every small matter word by word, it would. So we reduce what a person has to do to its simplest form: a numbered decision card.

The AI first finishes everything it can do on its own. Then it gathers only the questions that truly need a person, numbers them one by one and adds its recommendation. The person doesn't need to rewrite anything. They reply with one line, such as "1 yes, 2 hold", and the AI carries it out and records the decision in the event log.

Take the promotional email. The card might say: item one, send to this season's members at 8 p.m. on Friday; item two, leave out customers who bought something in the last 30 days. The marketing lead reads it and replies "1 yes, 2 yes", and the work moves on. The whole thing takes under a minute, yet every step has someone's approval and a record you can check.

With this design, people spend their time on judgement, not typing. The AI organises and executes, and the person says "yes" or "not yet". The roles stay clear, and governance doesn't cost much speed.

When a gate says no

A blocked request isn't a failure; it's a signal. Say the AI wants to add a batch of new customers to the promotional email list, but the permission gate finds this piece of work is only allowed to read the list, not change it. The request stops, and the event log records which gate refused it and why.

The AI doesn't then look for a way around. It turns the situation into a decision card: "Allow this work to modify the member list?" A person decides whether to allow it and how far. Every widening of permission is then agreed by someone and on record, instead of happening quietly in the middle of a run.

In short

• Permission is a promise, so the AI can't grant it to itself. A separate governance layer answers "may it?".
• Every request passes six gates in order, denied by default, and it stops the moment any gate says no.
• External actions are done, uncertain or not done. When uncertain, reconcile first, and reuse the same idempotency key to retry.
• Payment, deletion, permission changes and passwords always stay with people. AI proposes, and a person decides in one line on a numbered card.