Ask what it can read before you ask what it can do
Before anyone points an assistant at a production SAP system, someone has to answer a plain question in writing. Which records can it retrieve, for which user, and under whose authority. I have sat in programmes that spent months on prompt design and licensing without putting that boundary on paper, and the boundary is the part that turns up later in an audit finding.
The answer is harder in SAP than in most of the systems the same team has connected before. A service desk or a CRM usually resolves access to a record list that a person either can see or cannot. SAP resolves access per action, against a structure of permitted values, and the same transaction can succeed for one company code and refuse for the next one over.
Which grounding sources you can use, and how each one authenticates, depends on the modules you have licensed and the release you are running. Confirm that against your own system rather than the pattern you saw in a demo tenant. The architecture underneath moves far more slowly than the feature list.
Why SAP access is harder to reason about
A user's access in SAP comes from roles, but the role is packaging. Inside it sit authorisation objects, each carrying a small set of fields, and each field carrying the values that user is permitted for. The system evaluates those objects at the moment of the action, so the answer depends on what is being done and on which organisational values the data carries.
An accounts payable clerk can display vendor invoices for three company codes and get nothing at all for the fourth, with the same transaction and the same role. A cost centre manager can read their own cost centres and nothing above them in the hierarchy. The activity field decides whether the object permits display, change or posting, which is why display access and change access are different questions rather than degrees of one.
This granularity is why SAP authorisation is expensive to design and painful to maintain, and it is also why it is worth having. It encodes organisational boundaries the business argued about for years. Anyone who has worked through a segregation of duties review where one person wears four hats knows how much thinking sits inside those value ranges.
Inherit the check, or approximate it
An assistant that executes retrieval under the requesting user's own authorisations returns what that person could have pulled themselves through a transaction or a report. That position is defensible in a review, because the assistant changes how fast someone gets an answer and not what they are allowed to reach. When the check refuses, the assistant has nothing to summarise.
The other pattern retrieves through a technical or service account holding broad read access, gets everything back, then removes rows the requester should not see before composing the answer. The data has already been read by then. What remains is a presentation choice made by application code, and application code has bugs, gets refactored, and can be talked into summarising material it already holds.
The second pattern is the one to look for in a design review, and the one most likely to arrive by accident, because a single well-provisioned connection is the fastest way to make a pilot work. Ask which identity executes the retrieval, then ask to see the connection rather than the diagram. The same question lands on every platform grounding assistants in business data, from shared service account identity to the permission question under Oracle's assistant.
A correct row check does not make a correct total
Even a clean per-record check leaves something unresolved at the aggregate level. A user permitted to open each of two hundred purchase orders one at a time may not be permitted to know the total committed spend with that supplier. A total computed across permitted records can produce a number that no report in that person's menu would have returned.
Summarisation across documents does something similar. Ten individually unremarkable records can assemble into the outline of a restructuring, a pricing exception granted to one distributor, or a claim nobody has announced yet. The assistant broke no single check to build that picture, which is why the picture is easy to miss during testing.
There is no answer here that fits every organisation. Some accept aggregation on the grounds that every underlying record was permitted, which is coherent if someone senior signs it. Others stop the assistant aggregating across organisational units, or send aggregate questions to reporting that carries its own row-level restrictions. Make that choice deliberately, because the default behaviour of a retrieval layer is the permissive one.
A copy of the data is a second authorisation problem
Grounding usually involves a copy somewhere. Content gets extracted, indexed and stored outside the transactional system so that search performs well. The moment data leaves the system that evaluates authorisation objects, the evaluation does not travel with it. The index has its own access model, and that model is almost always simpler than the one you left behind.
Both ways out of this cost something. Keeping retrieval inside the system of record means the checks run where they were designed to run, and you accept slower responses and weaker search. Copying into an index means rebuilding organisational-level filtering in a store never built to express company codes and plants, then keeping it in step with every role change and reorganisation.
Ask early what happens to the index when someone transfers from one plant to another. The role change lands in the source system immediately, and the copy may carry yesterday's access until the next rebuild. That reconciliation problem sits at the middle of the SAP Business Data Cloud warehouse question.
Attachments rarely carry the authorisation of the transaction
Structured data gets the attention in these discussions. The exposures I have had to clean up came from the unstructured side. A contract attached to a purchase order, a scanned invoice, a note on a customer master record. Access to those files is frequently governed by the document store rather than by the authorisation objects protecting the transaction they hang off.
An assistant that can search attachments alongside transactions is more useful and carries more exposure, and both are true at once. Ask whether the repository holding those documents can express plant or company code restrictions at all. If it cannot, the honest options are to leave unstructured sources out of scope at launch, or to fix the document permissions first and accept the delay.
Then the audit question, which people defer and regret. After the fact, can you establish what was retrieved, under which identity, and on what basis it was allowed. A log of prompts and answers does not cover it. You want a retrieval record showing which objects were read, for whom, and which authorisation decision permitted it. Without that you cannot answer a regulator or investigate a complaint that the assistant showed someone a colleague's salary band.
Test as someone with narrow access, not as yourself
Testing performed by administrators proves almost nothing about the boundary. Someone with wide authorisation gets a correct answer to every question they try, which confirms retrieval works and says nothing about whether it refuses. Build a standing set of restricted test users instead. A buyer scoped to one plant, a payroll clerk for a single country, a cost centre manager with no access to the level above.
Write those tests as expected refusals rather than expected answers. For each restricted user, list the questions where the correct behaviour is an empty result, then read the whole response, because an assistant can decline in its first sentence and quote the number in its third. Run the set again after every role redesign and every new grounding source, which fits into an agent readiness check.
Before production access is granted, establish one artefact and hold the go-live to it. A list of every grounding source, and beside each one the identity that executes retrieval against it, plus the refusal test a restricted user passed on that source. Where a line reads as a technical account with broad read access and filtering applied afterwards, you have found your design decision while it is still cheap to make.
