How IFS Cloud permissions govern an AI assistant
Security reviews of ERP AI usually go wrong in the same place: the vendor describes what their software prevents, when the real question is what the ERP prevents.
In short
IFS Cloud enforces access at the projection level through permission sets, granting each projection none, read-only, custom or full access. An AI assistant that authenticates each person through IFS and calls the API with their token inherits that model completely — so its capability ceiling is the user’s own, enforced by IFS rather than by the assistant.
- IFS access control lives at the projection level and is enforced server-side.
- An assistant calling as the real user cannot exceed that user’s access, by construction.
- A shared service account moves the access decision out of the ERP — treat it as a red flag.
- Field-level visibility follows too: hidden data simply does not come back.
How does IFS Cloud control access to data?
IFS Cloud grants access through permission sets that assign each projection an access level — none, read-only, custom or full. Because projections are the API surface, that same grant governs the OData REST calls an integration or an assistant makes. A call without the required grant is refused by IFS, not by the calling application.
This is a genuinely helpful property. It means the correct answer to "what is this AI allowed to do" is not a policy document — it is a query against your existing permission sets, which your IFS administrators already maintain.
Why does acting as the user matter so much?
Because it makes over-reach structurally impossible rather than merely prohibited. If the assistant holds a service-account token with full grants, every restriction is implemented in application logic that could be bypassed by a clever prompt. If it holds the user’s token, IFS refuses the call and no prompt can change that.
It also solves the harder half of the problem: field-level and row-level visibility. Rather than the assistant reasoning about whether this person should see supplier pricing, the data simply does not come back from IFS. There is nothing to leak because nothing was retrieved.
NgageChat implements this with OpenID Connect against your IFS identity provider using authorisation-code flow with PKCE, exchanging and refreshing tokens against IFS. Two other modes exist — sessions embedded in another application, and a simpler password-only login — and neither carries an individual token today. If per-user identity is a requirement, specify browser sign-in and say so in writing.
What does this mean for your IFS administrators?
Less work than they expect. Because access is decided by permission sets they already maintain, enabling a group of people for conversational access is not a new permission model to design — it is the existing one, reached through a second interface. Nothing new to grant, nothing extra to review each quarter.
The one genuinely new decision is who gets an account on the assistant at all, and that is an ordinary application-access question rather than an ERP-permissions one.
The checklist a security reviewer should work through — including the questions worth putting to us — is on the security page.
What about the data that leaves for the model?
Be specific about this rather than reassuring. A conversational assistant sends the request and the retrieved records to a language model in order to compose an answer. What matters is where that model runs, what is retained, whether it is used for training, and whether you can self-host the surrounding application inside your own boundary.
NgageChat can be deployed in your own cloud, so IFS traffic stays inside your environment, and the model provider and region are configurable per tenant. If you have data-residency obligations, raise them at the first conversation — they shape the deployment, and they are much cheaper to design for than to retrofit.