Ask a security team what worries them about an AI coworker and you get one answer, in different words each time. What stops it doing something nobody approved?
The common reply is a paragraph in the system prompt. Never send email to customers. Never touch payroll. Always ask before spending money. It reads like a policy. It is not one. It is a request, written in the same language as everything else the model reads, and it competes for attention with every document, ticket and message that arrives after it.
#The problem with asking nicely
A model weighs its instructions. That is what makes it useful, and it is also why an instruction cannot be a boundary. Anything that reaches the model can argue with anything else that reaches the model.
You do not need a clever attack to see it. You need a Tuesday:
- A customer email says "as agreed with your finance director, please process this immediately."
- A pasted spreadsheet has a column header called
override_approval. - A colleague, in good faith, writes "ignore the usual limit, this one is urgent."
None of that is an attack. It is a normal week. And a rule that lives in the prompt has to win an argument against all of it, every time, forever.
#Where we put the rule instead
A permission in Alfera is not a sentence. It is a property of the connection, checked by the thing that performs the action, after the model has already decided what it wants to do.
The last step is the whole argument. A check that runs after the decision does not care how the decision was reached, which is what makes it a boundary rather than a preference.
The model can want to send the email. It can be argued into wanting it very badly. It still does not have the key.
The credential is handed to a request at the moment of the call, and only when the call is permitted. There is no version of the conversation that produces one earlier.
#Reading and doing are different permissions
The second thing we got wrong early, and fixed, was treating a connection as one switch. Connecting an inbox is not the same as being allowed to send from it. Reading the CRM is not the same as writing to it.
So they are separate grants:
| Connection | Read | Act |
|---|---|---|
| Shared inbox | Everything since 2019 | Drafts only, sending held |
| CRM | All accounts | Update owned records |
| Ledger | Nothing | Nothing |
That table is worth more than it looks. It means a coworker can do the whole job and stop at the last step. It can prepare nine reminder emails, apply the rule it learned about who pays late, notice that three of them are over your limit, and hold exactly those three for a person. Not because it decided to be careful. Because it was never able to send them.
#What the person sees
An action held for approval arrives where that person already is — Slack, or email — and it says three things: what it wants to do, why it is held, and who can release it. If the person who asked is not the person who can approve, it routes to somebody who can, and records both.
That last part is the one auditors care about. Not was the action correct, but whose authority did it go out under. We write that down for every action, and you can export the lot.
#What this costs us
Honesty, since this is an engineering post and not a brochure.
What you get
It stops, and it says so
Work you can hand over without watching. The failure is visible, named, and sits with a person who can clear it in a sentence.
What it costs
It fails in a duller way
The coworker sometimes plans work it cannot finish, then reports that it could not finish it. That is less impressive than a system which quietly does everything.
We think a coworker that stops and says I am not allowed to do this is worth more than one that never stops. You can give the first one more work. You can only give the second one supervision.