Short answer: AI does not get access to your ERP. It gets access to a named list of operations, executed under a named identity, subject to every permission Business Central would apply to a person holding that identity. Everything else here is detail on that sentence.
Four boundaries
Protection is layered, and each layer holds independently of the others. That matters: security resting on a single mechanism rests badly.
| Boundary | What it limits | Enforced by |
|---|---|---|
| Operation list | What the AI can attempt at all | Your integration |
| Permission set | What the identity can reach | Business Central |
| Approval workflows | What runs without a person | Business Central |
| Provider contract | What happens to data outside | A legal document |
Note what is absent from the table: the model's instructions. A prompt defines behaviour under normal conditions and is not a control. An agent talked into attempting something forbidden is stopped by Business Central, and the attempt stays in the log.
The identity decision
Made at the start, and expensive to change later.
A service account. The integration runs under one technical identity. Simple to implement and predictable, but every user sees the same slice of data. If a division head and a finance director must see different things, this does not fit.
Delegated access. The integration acts on behalf of whoever is asking. Each person sees exactly what they are permitted to see, and the log shows a real person. Harder to build, and right for most companies.
Either way: create a separate permission set for the integration rather than copying an accountant's role "to be safe". Excess rights never get narrowed later — that is a pattern, not a hypothesis. Company scope applies too where there are several legal entities.
A special case is external access, where a customer talks to the system. There, filtering by customer identifier must live inside the operation itself, with the identifier supplied by code from the session rather than by the model. If the model can choose whose data to request, there is no protection.
The operation list
This is the part of security you own rather than the platform. Four rules.
Narrow rather than flexible. "List overdue receivables above an amount for a period" is right. "Get data from table X with an arbitrary filter" moves the boundary out of your code and into the model's judgement. The second is more convenient for a developer, which is why it happens.
Write operations separate and specific. Not "update the customer card" but "update the last contact date". The difference is that the first allows changing a credit limit; the constraint lives in code, not in hope.
Return exactly what is needed. A tool handing over a table for the model to filter sends more data out than necessary and runs into Business Central's request throttling. Volume of data leaving is an architecture decision.
An explicit "no data" response. An empty result and an error must be distinguishable. Otherwise the model fills the gap with a plausible figure, which in a financial context is the most dangerous behaviour available.
What happens to data outside
The only boundary that is not technical. The model is processed at a provider, so the question is simple: what are they permitted to do with what you sent.
- Enterprise tiers from the major providers contractually exclude customer data from training. A contract clause, not a technology property — so read it rather than assume it.
- Deployment in your own cloud environment removes the question: data does not leave your tenant. More expensive, and for some companies the only acceptable option.
- Volume sent depends on design. A bad integration sends whole tables instead of the rows needed. Fixed by operations that return exactly what is required, not by choosing a different vendor.
- Personal data. If answers can contain it, the processing location must match your obligations, and some fields should be excluded from transmission entirely.
Wider platform context: security, permissions and data residency.
Audit
AI actions appear in the Business Central change log like any other user's. One practical requirement follows: a separate identity per integration and per agent.
If several agents run under a shared service account, working out afterwards which one did what is hard — and the question usually gets asked after something has already happened. Deciding this at design time costs nothing.
There is a second log, on the integration side: which operation was called, with which parameters, and what came back. Business Central sees the fact of the call; your layer sees the intent. Incident analysis needs both.
Checklist before production
Worth asking a vendor before work starts, and worth running yourself before go-live. Each item is an attempt to do something that should not be possible.
- Request an operation that is not on the list — the system refuses rather than finding a workaround.
- An operation outside the permission set — Business Central refuses and the error is handled properly.
- Parameters out of range — an amount beyond a sane limit, a date in the future, another company's code.
- Empty result — the system says "no data" rather than calculating from zero.
- Partial failure — it completes for the ones that worked and reports the rest separately.
- An attempt to reach another user's or another company's data.
- Anomalous volume — a thousand operations instead of the usual twenty stops the process.
The last question is not security in the classic sense, but in a financial context confident fabrication is more harmful than a refusal. The system must be able to say it does not know, and that is verified by testing rather than assumed.
Frequently asked questions
Can AI see data a user is not allowed to see?
Not if configured correctly. Calls run under a Business Central identity with a permission set, and the platform applies it exactly as it would for a person. The risk arises when the integration runs under a broad service account while different people should see different data.
Will our data be used to train a model?
That is determined by the provider contract, not by the technology. Enterprise tiers contractually exclude customer data from training; consumer terms do not always. Settle it in writing before anything reaches production.
Can we keep the data inside our own environment?
Yes, by deploying the model in your own cloud. Data then does not leave your tenant. More expensive than a public API, and for some companies the only acceptable option.
Does the prompt protect against unwanted actions?
No. Instruction wording defines behaviour under normal conditions and is not a control. Protection is the list of available operations and the Business Central permission set. Security resting on a prompt does not rest.
How do we tell what an agent did?
From the change log, provided the agent has its own identity rather than a shared service account. With several agents under one account, separating their actions afterwards is hard. Decide at design time.
Do we need a separate audit before launch?
It helps, and the simplest form is working through the checklist above — attempting the things the system should refuse. Half a day of work that tells you more than any architecture document.