Why this exists
We kept being asked the same question, and the honest answer was no.
This studio has spent ten years building the planning and reporting systems where a company's numbers actually live. In 2026 a different kind of question started arriving from the people we had built them for, and it was always a version of the same one: can we let an assistant read this?
The answer was no. Not because it was hard to connect. Because nobody in the room could say who would be accountable for what came out.
The question behind the question
Nobody was asking whether the model was clever.
Every conversation looked like an AI question and turned out to be a permission question. Three of them came up every time, and none of them is answered by connecting anything.
Who decided this?
Not which team rolled the assistant out. Which named person decided that this named person could read that system, and where is that decision written down.
What happens when she leaves?
If access is a credential somebody configured, removing one person means changing it for everybody, and nobody does that on a Friday.
What would we say in an audit?
Not what the assistant answered. What it was asked, what it was allowed to reach, and what it was refused, a year later, from a record nobody can quietly edit.
What a yes would need
So we stopped answering and wrote down what a yes would actually require.
It was meant to be a page. It became the product, and the test we set ourselves was never can it answer. It was: can you see what it refused, a year later, without asking us.
-
01
Access is a row about a person, not a property of an installation
One person, one environment, one set of tools, written by an administrator at the client. There is no second route to a tool somebody does not hold, and no override that widens it while they are asking.
Enforced in one function, and it is the only path to a database. -
02
Every check may only subtract
Four of them run in turn, and not one can hand back what another refused. That property is what makes the order of the checks irrelevant, which in turn is what makes the outcome something you can reason about rather than something you have to test for.
The gates are described in full on Permission gates. -
03
The refusals are recorded, not just the answers
Anybody can log what a system did. The row that matters in a review is the one where it said no, and why, in a name that will still mean the same thing in three years rather than a log line written for whoever was debugging that afternoon.
Seventeen reason codes, frozen by a test so they cannot quietly drift. -
04
Nothing is copied here to make it faster
The read happens against the client's own system, on their own credential, at the moment somebody asks. That is slower than an index and it is the whole point: there is no second copy of the numbers to re-permission, drift, or leak.
What is held and what is never held is listed on What it cannot do.
What we got wrong
The list got longer every time we tested it, and one gate exists only because we were caught.
There were three checks for most of the build, and everything the tests were asked about passed. Then somebody connected to a running server the way a client would, instead of reading the code, and found it offering eleven tools of which several could not answer at all.
Why nothing caught it
- All three checks said yes, correctly. The person held the grant, the tools were theirs to use, and the administrator had switched them on.
- Not one of them was asking whether there was a system connected on the other end to answer with.
- The health endpoint said the server was fine, and by its own definition it was. A tool that reports its own health is a feature, and it needs testing like any other.
What changed because of it
- A fourth gate, which asks whether the system a tool reads is actually connected, and removes the tool from the list when it is not.
- An ordering decision: the client-fixable reason wins, so your administrator has not switched this on is said before nothing is connected.
- A rule about our own confidence: a green test suite is evidence about the pieces you wired together, not about the thing you deployed.
Why this is on a website. Because the alternative is a page that says the design was right from the start, and the reviewer reading it has met that page before.
What did not change
The four things we refused to make easier.
Each of these has been asked for, each would shorten a sales conversation, and each is a property of the design rather than an item waiting on a roadmap.
Refused on purpose
- An empty tool list grants nothing. Not everything, not a sensible default. Nothing.
- No standing access. Revoking somebody takes effect on their next question, because the token carries no permissions of its own to go stale.
Still refused
- Writes are off everywhere. This reads. A write is a separate decision nobody has asked us to make yet.
- We run no model. The assistant stays the client's, the bill for it stays theirs, and swapping it changes nothing in this layer.
The same question, with an answer this time.
If your people are already asking assistants about your data, the useful question is not whether it works. It is whether anybody can tell you what it refused last week. Start with the review pack, not the demo.