Why authorisation belongs at the tool layer, not the prompt
Most AI deployments I see in regulated firms have one structural flaw: they treat the model as if it were a person with a job description. They write a system prompt that says "you are a helpful assistant, do not approve anything over €10,000" and they call that control. It is not control. It is a polite request to a probabilistic system, and it will fail the first time someone phrases the question cleverly.
The Intelligence Brain takes a different position. The model never holds authority. Authority sits one layer below, at the tool layer, where every action the agent can take is gated by code that runs whether the model is well-behaved or not. The model can read everything it has been granted access to. It can sign nothing.
Read everything, sign nothing — what that actually means
"Read everything" means the agent can pull from your contracts repository, your finance ledger, your CRM, your ticketing system, your internal wiki — whatever the policy says it may see. That breadth is the whole point of an intelligence layer. If you narrow the read surface, the answers get worse.
"Sign nothing" means the agent cannot, on its own:
- commit a payment
- send an external email under a person's name
- change a customer record
- approve a workflow step
- create a contract or counter-sign one
- raise a purchase order
Anything in that second category is a write action against the business of record, and write actions go through a human-in-the-loop step or a pre-authorised, narrow, machine-to-machine path with its own audit trail. The model proposes. A person, or a hard-coded rule, disposes.
Policy as code, not policy as prose
The mistake people make with AI authorisation is writing the rules in English and putting them in the prompt. English is the wrong language for a control. It is ambiguous, it drifts when the prompt is rewritten, and it cannot be audited by anyone who is not reading the prompt that day.
In the Intelligence Brain the rules are expressed as code — a small policy file per tool, per role, per data class. A policy file says things like:
- this role may invoke this tool
- only on records matching this filter
- only between these hours
- only with a maximum value of X
- only after a named human has confirmed
Because the policy is code, three things become possible. First, your compliance team can read it without learning prompt engineering. Second, it goes into version control alongside the rest of the codebase, so a change has an author, a date, and a reviewer. Third, it can be tested. You can run the same query a hundred ways and confirm the gate holds every time. You cannot do that with a paragraph in a system prompt.
How agent permissions are scoped
An agent in the Intelligence Brain inherits permissions from three places, in this order:
- The identity of the human asking the question. If the user cannot see a document in your existing identity system, the agent cannot use that document on their behalf. We do not bypass your existing access controls — we honour them.
- The role of the agent itself. A "finance research" agent and a "HR research" agent are different principals with different tool sets, even if they share a model behind them.
- The policy attached to each individual tool. A tool that reads the ledger has different rules from a tool that drafts a board paper, even if both are available to the same agent.
The effect is that the model's freedom shrinks to exactly the intersection of those three layers. Nothing in the prompt can widen it. A jailbreak that convinces the model it is now a different agent does not get the model new tools, because the tools were never bound to the conversation — they were bound to the authenticated session.
What this looks like in audit
A regulator or an internal auditor does not want to read transcripts. They want a log. The Intelligence Brain produces one row per tool invocation: who asked, which agent ran, which tool was called, with what arguments, against what data, what the policy decision was, and whether it was allowed, denied, or escalated to a human approver. The model's reasoning text is kept separately and is not the system of record for what happened — the tool log is.
This matters under the EU AI Act and under the supervisory expectations the Central Bank has been signalling for high-impact systems in financial services. "The AI did it" is not an acceptable answer. "Here is the deterministic log of every action it took, every gate it passed, and every gate that stopped it" is.
Where the line should sit for your organisation
The harder question, in practice, is not technical. It is governance. Where do you want the cut between "agent decides" and "human signs"? My default for regulated firms is conservative: the agent should never sign anything that a junior staff member would also need a second pair of eyes for. If a graduate analyst cannot send that email without a manager's approval, neither can the agent. Start there. Loosen later, with evidence. Do not start loose and tighten after an incident.
What to do next
If you want to see how the tool layer fits with the rest of the architecture — retrieval, on-premise hosting, the audit trail, the human-in-the-loop console — go back to the Intelligence Brain overview. If you are specifically working on a financial services deployment and want to see how this maps to Central Bank expectations, read the Intelligence Brain for financial services page.
Or write to me directly. I would rather have a thirty-minute call about your actual control environment than send you a deck.