Summary. An enterprise AI agent is safe to deploy when four things are true: it is grounded in a description of the business's own data model, its capabilities are a closed and enumerable set of tools, it executes under the identity and permissions of the person asking, and every write is approval-gated and audited. None of those is a prompt instruction — each is enforced by architecture, which is what makes the guarantee hold under adversarial input.
What problem this solves
A model has no knowledge of your entities, your field names, or which of them a given user is allowed to see. Wire it directly to a database and you get an assistant that is confidently wrong about your schema and structurally incapable of respecting your permission model. Wire it to nothing and it cannot help.
The architecture below is the middle path: give the agent a bounded set of capabilities, a way to learn the model at runtime, and the caller's own authority — nothing more.
The architecture
1. Grounding: describe your model, in your model
The agent needs to know that distributors live on an account entity distinguished by a type field, and that credit is held as three separate values. None of that is in the model's weights, and in a configurable platform it differs per tenant.
Fine-tuning is the wrong instrument: the schema changes weekly, it is per-customer, and the difficulty is
not structure but meaning — PartnerAccountId is unambiguous to a database and useless to a
model reasoning about a distributor.
The workable approach is a description layer alongside the metadata — plain-language statements of what each entity, field, action and report is for, plus task cookbooks covering how to answer questions in a domain — retrieved on demand rather than stuffed into every prompt. The agent looks things up the way a competent new joiner does: not by memorising the data dictionary, but by knowing where to look.
2. A closed tool registry is the real boundary
An agent can only do what its tools permit, which is why a single generic "execute" tool destroys the security model: the effective boundary becomes whatever the prompt talks the model out of.
A governed registry is enumerable and reviewable. In xMatix it spans discovery (what entities exist, describe one, inspect relationships), retrieval (query, query related, aggregate, summarise), reporting (list, describe, run, draft), knowledge (search grounding material, read platform docs), extension points (tenant-defined script tools, MCP tools) and vision (analyse a shelf photo).
Against all of that, the write surface is one tool that updates fields on an existing record, plus the ability to publish nudges. No create tool. No delete tool. No arbitrary-action tool.
That asymmetry is deliberate. Update is anchored: the agent must already have found a specific record the user can see, and the change lands on a row with an owner, a history and an audit entry — visible, attributable, reversible. Creation has no such anchor, and deletion destroys the evidence of its own mistake.
3. Runs as the user, not as a service account
Every tool call executes under the identity of the person asking. The agent holds no credentials of its own.
The consequence is that the platform's existing record-access policies and field-level permissions apply unchanged — there is no second permission model to keep synchronised, and therefore no drift to be discovered the wrong way. It also bounds prompt injection: a hostile instruction can at worst make the agent do something the user could already have done, which is the correct ceiling for an assistant.
4. Approval is a control, not a notification
A notification arrives after the fact and is a log. Approval happens before and is a control. Writes propose; a person accepts; the change lands.
Approval only works if the person has enough to decide with. "Set the quantity to 24" is a coin flip. "Set the quantity to 24 — on hand 40, in transit 30, on order 25, committed 40, net 95, reorder point 65" is a judgement someone can make in seconds. Evidence is what converts an approval step from ceremony into control.
5. Budgets before the call, audit after
Model consumption is a real cost that scales with adoption, and the wrong place to discover it is an invoice. Budgets enforced before the model call make consumption a control rather than a surprise.
On the other side, agent activity belongs in the platform's own audit trail — who asked, which tools ran, what changed, under whose permissions — rather than a separate AI log, so an investigation does not have to correlate two systems and trust their clocks.
Where deterministic beats generative
Not every AI feature should be model-driven. Proactive signals in xMatix — the purchase-order line that duplicates inbound stock, the order just below a scheme slab, the overdue receivable — are computed by deterministic code, because alerting at scale against financial documents demands repeatability, auditability and a cost that permits running on everything.
The model's job is downstream: explaining the finding in plain language, answering follow-ups against live data, and carrying the action. Computation deterministic, communication generative — the split is worth making explicitly, because conflating them produces features that are interesting and untrusted.
Questions to ask of any enterprise AI agent
- Under whose identity does it read data, and what happens when a user asks for something outside their permissions?
- Can you enumerate its capabilities? If the answer includes "it has API access", the boundary is undefined.
- Can it create or delete records, and if so what gates that?
- Where is the boundary enforced — in the tool surface, or in the system prompt?
- What is recorded, and is it in the same audit trail as human activity?
- What stops consumption from becoming an unpleasant surprise?
Further reading: AI trust & governance · AI Studio · Rolling out an AI assistant your CISO will sign off