Security & governance
An AI that can change your ERP
is only useful if it cannot do it quietly
Governance in AnrilX is structural rather than instructional. The platform does not ask a model to behave; it removes the ability to misbehave, and then records everything that happened anyway.
Fail-closed policy
Every governed call is authorised before it leaves the platform. If the policy engine is unreachable or cannot answer, the call does not happen. “Could not determine” is never treated as permission.
Human approval on writes
A change is compiled, validated against SAP's own contract, and then shown to a person as the exact payload and the exact call. The object approved is the object sent, not a summary of it, and not regenerated afterwards.
Your SAP authorisations
AnrilX does not invent an access model. A person reaches exactly what their own SAP account permits, and a question about data they cannot see returns nothing rather than a leak.
On-premise
Deployed inside your landscape. Your SAP data, your uploaded documents and your policy sit in your own environment; there is no shared multi-customer store.
No bulk copy of your ERP
Reads are row-capped and made at question time. The platform indexes your SAP service catalogue (the shape of your system), not the transactions inside it.
Complete audit trail
Every tool call, model call and SAP read is recorded: what was asked, what came back, what was refused and why. A refused call is as visible as a successful one.
Failure behaviour
What happens when something goes wrong
Most of the risk in an AI system is not in what it does when everything works. It is in what it reports when something has failed.
A policy denial
The call is refused before it reaches SAP, and the refusal is shown to the user rather than silently swallowed.
A rejected write
The reason travels back into the conversation and the identical call is blocked for the rest of the run.
An unreachable system
Reported as an outage, explicitly, never as a rejected request, which would invite someone to rephrase a question that was never the problem.
A renamed SAP field
A saved dashboard or report errors rather than rendering a plausible number from the wrong column.
What personalisation can and cannot change
Admin · personalisation
These shape the style of the answer, never the data. Every SAP figure still comes from a live query, whatever is set here.
Source: Preferences are applied after the query returns. None of them is an input to the query.
The separation is stated in the product at the point somebody is about to change a setting, which is where it matters rather than in a policy nobody opens.
Your rules
Governed by your own documents
Upload the standards you already have (reporting policy, close procedure, pricing guidelines) and AnrilX works out which figures each one governs. A rule about order counts is then structurally unable to land on a currency figure.
When a rule applies, the answer says so and names the document. When the raw number is reported alongside it, it is marked: clearly, and in the answer itself rather than in a footnote nobody reads.
Admin · knowledge scope
Upload the standards you already have and AnrilX works out which figures each one governs. Blueprint SD-RPT-047 defines how sales order value is reported here, and the right-hand column is the part worth checking, because a rule that could reach anything would be worth nothing.
Governs
- ZA_SalesOrder · TotalNetAmount
- ZA_SalesOrder · rejection handling
- reporting period basis
Never touches
- I_PurchaseOrderHistory · any field
- billing document values
- anything outside SD
Documents read
SD-RPT-047 Sales Order Reporting Basis §1, §5, §7
net order value · rejection handling · period basis
SD-PRC-009 Pricing and Discount Guidelines §6.1 – §6.4
which condition types count as a discount, via ZSDT_DISC_TYPE
FI-CLS-012 Month-End Close Procedure §3, §4
which postings a closed period includes, via ZFI_PERIOD_MAP
MM-PRC-021 Price Comparison Standard §2
effective unit cost, including freight conditions
SD-RPT-051 Regional Sales Reporting (draft) not mapped
escalated: “region” resolves two ways and the document does not say which
Your tables it resolves through
ZSDT_DISC_TYPE Condition types the blueprint treats as a discount
18 rows · read-only · maintained by the pricing team
ZSD_ORD_EXCL Order types excluded from revenue reporting
4 rows · free-of-charge and returns
ZFI_PERIOD_MAP Fiscal period to calendar month
your year starts in April, so “last quarter” is not a calendar quarter
ZMM_SUPP_GRP Supplier groupings used in spend reporting
present in no standard hierarchy
Source: Business Blueprint SD-RPT-047: Sales Order Reporting Basis · sections 1, 5 and 7
A rule about order counts is structurally unable to land on a currency figure. The scope is derived from the document, then shown, rather than configured by hand. Where a definition resolves through one of your own tables rather than a standard field, the table is named above and read at query time: a blueprint that says “discount means what is in ZSDT_DISC_TYPE” is applied by reading ZSDT_DISC_TYPE, not by copying its contents into a setting that then goes stale. A document that grounds onto nothing is listed unmapped and escalated; it is never applied approximately.
Being straight about it
What these controls do not cover
A control is worth what its boundary is, so here is where each of these stops.
-
It does not widen anybody's access. A person reaches exactly what their own SAP authorisations already permit, and a question about data they cannot see returns nothing rather than a partial answer.
-
There is no unattended write. No confidence threshold, no allow-list of "safe" changes, no setting that turns approval off; every write stops for a named person.
-
The audit record is append-only within the platform, and it lives in your infrastructure. Retention, export and who can reach that store are your controls, because we cannot promise the safety of something we do not host.
-
Token budgets are enforced before a run starts. A run that begins within its limits can still overshoot them, and that gap is stated rather than hidden.
-
It is not a compliance certification. It is an architecture you can audit: the controls are real and the evidence is in the record, but the attestation is your programme's, not ours.
Questions people ask us
Can AnrilX change data in SAP without a person?
No. Every write pauses for explicit human approval showing the exact field values and the exact call. There is no confidence level at which it proceeds alone and no setting that disables the gate; the two operations are structurally separate, and the one that executes carries a reference rather than a payload.
Does our SAP data leave our environment?
AnrilX is deployed on-premise inside your own landscape. Your SAP data, your uploaded documents and your policy configuration stay there, and there is no shared multi-customer store. Reads are made at question time and row-capped; the platform does not maintain a copy of your transactional data.
How does it handle access control?
It does not invent an access model. Calls are made under your existing SAP authorisations, so a person sees precisely what their own SAP account permits. A question about data outside that returns nothing rather than a leak.
What is recorded, and for how long?
Every model call, tool call and SAP read: the prompt as sent, the response as received, the arguments, the result, the duration, and the reason for anything refused. A refused call is as visible as a successful one. Retention is configurable and pruned on a schedule you set.
What happens if the policy engine is unavailable?
The call does not happen. The gate is fail-closed; "could not determine" is never treated as permission. This is deliberately the opposite of how the knowledge lookup behaves, where an unreachable store means answering as the system did before any document was uploaded rather than refusing every figure in the product.
Can we see what it did before we trust it with writes?
Yes, and we would suggest it. Reads are the whole product for most users; writes are per-app capability that can stay switched off entirely. An app without the write capability is not given the write tools at all, rather than being instructed not to use them.
Read next
Capability
Governed writes
What the approval actually shows, and why preparing and executing are separate operations.
ReadArchitecture
How it works
The four things a model here is structurally unable to say, and the five layers between a question and a figure.
ReadInsight
What it says when it fails
Messages that were locally true and globally misleading, and what we changed.
ReadBring your security team to the demo
The governance model is the part worth pressure-testing. We would rather they asked the hard questions on the first call than the fifth.