Most security questions asked of an AI product are the wrong ones. Where is it hosted, is the traffic encrypted, is there an audit log: all necessary, all answerable by anybody, and none of them the thing that will actually go wrong.
The question that matters is narrower: whose authorisations does it read with?
The service account and what it quietly replaces
The straightforward way to build an AI over SAP is to give it a technical user with enough rights to answer anything, and then decide in your own application who may ask what.
It works. It demos well. And it has moved the access decision out of SAP.
Your SAP authorisation model is not a configuration detail. It is years of accumulated decisions about who may see which company codes, which plants, which cost centres, which personnel records: argued over, audited, and in many organisations the thing an external auditor actually tests. A service account with broad rights does not breach that model. It bypasses it, and substitutes a second access model that is newer, less reviewed, and maintained by whoever is shipping features this quarter.
The failure is not dramatic. Nobody exfiltrates anything. Somebody in one division asks a reasonable question and gets a figure that includes a division they have never had access to, and either they notice and you have an incident, or they do not and you have a worse one.
Reading as the person asking
The alternative is to make the platform incapable of the mistake: every read happens under the authorisations of the person who asked.
The property that follows is worth stating plainly, because it is the whole claim: it never returns anything the person asking could not have read themselves. Not should not. Could not. There is no widened path, which means there is no configuration in which a permission is granted in a hurry and a boundary quietly moves.
This also means the platform is not a place where access policy lives. It has no view on who should see what; it asks SAP, and SAP already knows. Your role design continues to be the thing that governs, which is convenient for the people who maintain it and, more importantly, means there is nothing new for an auditor to be shown.
The edge is where it gets interesting
Honouring authorisations is the easy half. What the system does when a question runs into them is the half that decides whether the property is worth anything.
A question that spans data the asker can partly see has an obvious bad answer available: compute over the rows they were allowed to read, and return the total. Every part of that is defensible in isolation. The rows were legitimately read, the arithmetic is right, the number renders.
It is also a lower bound wearing a total’s clothes, and we have argued that this is the most dangerous class of answer there is : locally true, globally misleading, and indistinguishable on screen from a correct one.
So the answer at the edge has to be a refusal that says what it is. The question needed data outside what you can read; here is what it covered and what it could not. That is less satisfying than a number, and it is the only version that leaves the reader able to do the right thing next, which is usually to ask somebody with wider access, an action a partial total would have hidden the need for.
Why this is not a feature
A capability you can turn on is a capability somebody can turn off, so it is worth being precise about which of these are properties and which are behaviours.
Reading under the asker’s authorisations is structural. There is no service account with wider rights to fall back to, so there is no switch.
Stopping cleanly at the edge is a behaviour, and behaviours are tested rather than guaranteed. It is also the behaviour most worth probing in an evaluation: ask something that crosses a boundary you know exists in your own roles, with an account you know is restricted, and read what comes back very carefully. A confident number is the answer to be worried about.
What it does not protect you from
It does not narrow anybody’s access either. If someone’s SAP role is wider than their job, this makes that fact more visible and more usable rather than less: the questions they can now ask easily are the questions their authorisations already permitted, which they previously needed a report request to get at.
That is an argument for reviewing your role design. It is not an argument against making the data answerable, and anybody selling you an AI that promises to fix your authorisation model is selling you a second one to maintain.