Security & permissions

It cannot do anything you could not do in IFS

Not because we promise it, and not because a prompt tells it not to. Because every call reaches IFS carrying your identity, and IFS decides.

Send us your security questions

NgageChat — a permission refusal IFS Cloud connected

Show me the payroll costs on project P-2041

ifs_read_data PayrollCostSet

IFS returned SE_UNAUTHORIZED. Your permission set does not grant that projection, so I cannot show it — and neither would the Aurena screen.

I can show total labour cost on the project, which your permissions do allow
Projection grants are managed by your IFS administrator

The refusal came from IFS. NgageChat did not decide what you should see.

How does NgageChat handle IFS security and permissions?

With browser sign-in, NgageChat executes every IFS read and write as the individual signed-in user, through that person’s own IFS permission sets and projection grants. It cannot access or change anything they could not access or change in IFS Aurena, because IFS enforces that — not an instruction in a prompt.

Last reviewed 3 August 2026 · NgageChat by EX10

Identity: it acts as you, not as a robot

Users sign in with their own IFS account over OpenID Connect using authorisation-code flow with PKCE. Token exchange and refresh run through stateless server-side proxies, and every IFS call carries that person’s access token — so IFS decides what is allowed, and no prompt can change the answer. This is the mode to specify. Embedded sessions and the simpler password-only login do not carry an individual token today; if either is in scope for you, raise it early because it changes the governance conversation.

Per-user OpenID Connect sign-in in the browser
Tokens exchanged and refreshed against IFS, never minted by us
Access ends when the IFS account is disabled

Authorisation: IFS enforces it, not us

IFS Cloud grants access at the projection level through permission sets. Because NgageChat arrives as the real user, that grant applies to every read and write it attempts. A refused call is refused by IFS and reported back honestly, including the actual error.

Projection-level permissions apply unchanged
Restricted data is never retrieved, so there is nothing to leak
Permission refusals are logged — they are the control working

Change control: nothing writes without a human

Before any create, update, delete or IFS action, the complete payload is rendered as a readable summary — every field, including values resolved from IFS defaults. You approve, amend, or stop. Read requests skip this; only changes require it.

The full field list, not a summary sentence
Amend a value in the conversation rather than starting again
ETag concurrency stops a parallel change being overwritten

Audit: reconstructable, not just logged

Every conversation turn produces a durable record with the prompt, each tool call and its parameters, each result, the model, timings, token usage and any error. The standard for auditability is reconstruction: could you replay what happened from the log alone? That is the design goal.

Prompt, tool calls and results — not just the final answer
Failed and refused attempts recorded too
IFS-side audit intact, attributed to the real person

Deployment: your boundary if you need it

Self-host NgageChat in your own cloud so IFS traffic never leaves your environment, or have EX10 run it. Either way nothing is installed inside IFS — no database connection, no custom entities, no core modification.

Self-hosted or EX10-managed
Per-tenant configuration, including model provider and region
No core modifications, so the upgrade path stays clean

The audit record

Most vendors assert auditability. Here is the schema.

Ask any vendor to show you this. If they describe it rather than showing it, they have logging rather than auditability.

Recorded for every conversation turn

Field	What it captures
`conversation_id`	Groups a session together
`message_index`	Ordering within the conversation
`role`	Whether the turn was the user or the assistant
`content`	The literal text of the message
`tool_invocations`	Every tool called, its parameters and its result
`provider, model`	Which model handled the turn
`has_error, error_summary`	Failure state and cause, including permission refusals
`token_usage, duration_ms`	Cost and latency, per turn
`created_at`	Timestamp

Scroll the table sideways to see every column.

Read more on what an ERP AI audit trail should contain, including what to test during an evaluation.

For your security reviewer

Five questions to ask any vendor — including us

1 Does every ERP call carry the end user’s identity, or a service account’s? Demonstrate it.
2 Where are user tokens stored, and how long do they live?
3 Can a user perform an action through chat that their permission set forbids in Aurena? Show the refusal.
4 What exactly is written to the audit log, and can we query it during the proof of concept?
5 Where does the deployment run, which components see ERP data, and which model provider and region handle prompts?

We would rather answer these badly and honestly than well and vaguely. If something is not in place yet, we will say so and tell you when it will be.

FAQ

Security questions, answered directly

Whose permissions does NgageChat use?

The signed-in user’s. Each person authenticates with their own IFS account over OpenID Connect, and every call to IFS carries that user’s access token. IFS applies its projection-level permission model exactly as it does in Aurena, so NgageChat cannot read or write anything that person could not reach through the normal interface.

Do you use a shared service account?

Not for browser sign-in, which is the mode we recommend and the one this page describes: each person authenticates with their own IFS account and their token is what reaches IFS. Two other modes exist today — embedded sessions opened from another application, and a simpler password-only login — and both currently reach IFS through a configured connection rather than an individual token. Per-user identity for those modes is on the roadmap. Ask us which mode your deployment would use before you assume either way.

Can it write to IFS without a human approving?

No. Every create, update, delete and action is preceded by an on-screen summary of the complete payload, and nothing is sent to IFS until you approve it. You can change any value at that point rather than restating the request.

What is recorded for audit?

Per conversation turn: the conversation identifier and position, whether it was the user or the assistant, the message content, every tool call with its parameters and result, the model used, error state, token usage, duration and a timestamp. IFS keeps its own audit as normal, because calls arrive as the individual user.

Where does NgageChat run, and where does our data go?

It can be self-hosted in your own cloud so IFS traffic stays inside your boundary, or hosted by EX10. Conversations are stored for history and audit in the deployment you choose. Tell us your residency requirements at the first conversation — they shape the deployment and are far cheaper to design for than to retrofit.

Which model handles our data, and is it used for training?

The model provider and region are configured per deployment. Rather than ask you to take our word on training, we will name the exact provider and point you at that provider’s published API terms, so the claim is one you can check yourself. Retention of prompts and logs is set by the deployment you choose, and we will put both in writing before you sign anything.

What happens when someone leaves the organisation?

Disable their IFS account. Without a valid IFS identity there is no token, and without a token there is no access to your data — the same control you already operate for Aurena.

Are you SOC 2 or ISO 27001 certified?

Ask us for the current certification status rather than trusting a badge on a website. We will tell you what is held today, what is in progress and the expected date, and we would rather lose a deal on that answer than win one on a claim we cannot evidence.

Early access

Send the security questionnaire before the demo

We would rather clear the governance conversation first. Send us your questionnaire and we will answer it in writing, including the things we do not have yet.