Rolling out an AI assistant over business data is not a model decision. The model is the most replaceable part of the stack. What determines whether your security team signs off — and whether they should — is the control plane around the model: identity, permissions, approvals, audit, data routing, budgets, and scope.
This is the checklist we would put in front of any vendor, including ourselves. Seven controls, each with the questions worth asking and the answer xMatix gives for Sense.
1. Identity and permission inheritance
Ask any vendor: What identity does the assistant use when it reads data? If the answer is a service account or "integration user," ask how row-level and field-level restrictions are enforced — and whether the enforcement is a system prompt or a data-layer control. Ask what happens when a user asks about a record they cannot open in the UI.
How xMatix answers it: Sense executes under the calling user's identity. Every tool call inherits that user's row-level and field-level permissions, enforced by the same layer that governs the application itself — not by prompt instructions. A user cannot obtain data through chat that they could not obtain through a screen, because the query Sense runs on their behalf never returns it. The same holds for Sense Control, the admin copilot: it configures the system as the signed-in administrator through the existing tenant APIs, with no privileged tool gateway behind it. When a question is routed to a specialist agent, the agent must be within the user's audience, and the execution identity is re-resolved for the routed agent before anything runs.
2. Approval gates on writes
Ask any vendor: Can the assistant modify data, and if so, what stands between the model's intent and the write? Is the approval a UI convention or an enforcement point? Can tenant configuration weaken it?
How xMatix answers it: Writes are capability-gated and approval-gated. Agents only hold tools they were explicitly granted, so a query agent has no write tools to misuse. Where writes exist, they pause on an in-chat approval: report and dashboard drafts land as approvals rather than silent writes, and in Sense Control, deletes, activations, publishes, imports, and bulk writes all stop on an explicit dialog. Changes are previewed first — records materialize without persisting, rules run in memory, integration flows dry-run with side effects off. Critically, the approval-required tool set is union-only: tenant configuration can add approval requirements but can never remove a platform one. Misconfiguration can only make the system stricter.
3. Audit trails
Ask any vendor: When the assistant reads a record or takes an action, what lands in the audit log, and against whom? Can you produce, for a given user and date, every AI-driven access and every approval decision — including denials?
How xMatix answers it: Because Sense acts through the platform's own APIs under a real user identity, its activity generates first-class audit evidence: tool calls, approvals, and actions recorded against the person who asked. Denials are recorded alongside approvals. And beyond per-action logging, transcripts feed a continuous review pipeline, so assistant behavior is itself inspected and improved over time rather than assumed correct.
4. Data-to-model policy
Ask any vendor: Which model endpoints can see your data, who decides, and what happens when the primary endpoint fails? Is the failover path subject to the same policy as the primary? Can the assistant reach the public web, and who controls that?
How xMatix answers it: Model connectivity is explicit tenant configuration, not a hidden default. Tenants see exactly which models are available, can pin models per agent, and can order providers into a failover chain — failover switches before the first token, and only among endpoints the tenant configured, so a degraded primary never silently reroutes data somewhere unapproved. Escalation to a stronger model for complex questions targets a model the tenant designated for that purpose. Grounding works the same way: document retrieval and knowledge search run over the tenant's own ingested content, scoped by permissions. External reach is governed too — outbound web tools are off by default and require deliberate enablement.
5. Budget controls
Ask any vendor: Is spend enforced or merely reported? Concretely: if a tenant's allocation is exhausted, does the next model call fail before it is made, or does it succeed and appear on next month's invoice? Can you cap individual users? Is the consumption record immutable?
How xMatix answers it: Sense is licensed and metered by design: user seats gate access, and credit allocations cap consumption per calendar period, with optional per-user caps. Every model carries a rate card — credits per thousand tokens, or credits per request for machine-learning models — and quota is checked before the model call. Exhausted allocation means the request never reaches a provider; the user gets a clear message, not a bill. Every deduction is appended to an immutable credit ledger attributing spend to tenant, user, and agent, surfaced on a usage and credits admin page. Daily token and cost budgets add a second brake, and long-running agent workflows carry step caps, timeouts, and concurrency limits of their own.
6. Off-topic guardrails
Ask any vendor: What keeps the assistant on the job it was deployed for? If an employee asks it for general-purpose content, legal opinions, or anything outside the business domain, what happens — and is that behavior enforced at the boundary or left to the model's mood?
How xMatix answers it: Every turn passes a scope classifier at the boundary before execution: business questions proceed, setup and administration questions are redirected to the right surface, and off-topic requests are declined outright. The guard applies on both entry paths — directly pinned conversations and routed ones — so there is no side door that skips it. It is also operable: kill switches let the platform adjust guard behavior without a redeploy if it ever misfires. An assistant that knows what it is not for is easier to defend than one that answers everything.
7. Model governance and BYO keys
Ask any vendor: Who can add or alter model endpoints? Can a tenant user repoint the assistant at an arbitrary endpoint? If you bring your own model keys, how are they stored, and do your models inherit the same controls?
How xMatix answers it: Model definitions are governed in two tiers. Platform-provided models are defined centrally and are read-only per tenant — connection details and rate cards cannot be edited from tenant setup. Tenant-created models are bring-your-own-key: the tenant supplies its own credentials, stored encrypted, with connectivity validated at creation, and the endpoint slots into the same failover, metering, ledger, and pre-call quota machinery as everything else. Tool access is governed the same way: capabilities are named bundles of tools granted per agent, so an agent's reach is a reviewable configuration artifact, not an emergent property of its prompt.
The short version
If you keep one page from this guide, keep the checklist:
- Identity: the assistant runs as the asking user, permissions enforced at the data layer.
- Writes: capability-gated, preview-first, approval-gated — and approvals can only be added, never removed.
- Audit: every tool call, approval, and denial attributed to a person.
- Data routing: explicit model configuration, policy-honoring failover, web access off by default.
- Budgets: quota enforced before the call, append-only ledger after it.
- Scope: off-topic declined at the boundary, on every path.
- Models: platform models locked, tenant models BYO-key and encrypted, tools granted per agent.
Put these questions to any vendor, in writing, and ask for the mechanism behind each answer — not the policy, the mechanism. A vendor with real controls will enjoy the conversation. That is, in the end, the simplest test of all.