Most AI assistants attached to business software share a design flaw so common it has become invisible: they run as a service account. A privileged integration user sits behind the chat window, holding read access to everything so the assistant can answer anything. The user types a question, the bot queries the database as itself, and the permission model your team spent months configuring is quietly bypassed on every turn.
We built xMatix Sense the other way around. Sense executes under the identity of the person asking. Every tool call it makes — every query, every lookup, every draft — runs as you, with your row-level and field-level permissions applied by the same enforcement layer that governs the rest of the platform. There is no privileged backdoor, because there is no separate identity to privilege.
The service-account problem
A bolt-on chatbot needs data access, and the fastest way to get it is a service account with broad read scope. That decision has consequences that surface later, usually in a security review:
- The assistant knows more than the user. A field rep who cannot open the margin column in a report can simply ask the bot what the margin is. The permission model still exists — the AI just isn't subject to it.
- Guardrails become prompt engineering. When access control isn't enforced at the data layer, the vendor's answer is a system prompt asking the model to please not reveal restricted data. Prompts are instructions, not enforcement. They can be worked around; permissions cannot.
- Audit trails point at the wrong actor. Every query the bot runs is logged against the integration user. When an auditor asks who accessed a record, the honest answer is "the chatbot, on behalf of someone."
- One credential becomes the crown jewels. A service account with tenant-wide read access is a single compromise away from a tenant-wide data leak.
None of this is hypothetical malice. It is what happens when AI is added to a system instead of built into one.
How runs-as-you works
Sense is metadata-native: it operates on the same entities, fields, and APIs as the rest of xMatix, so it inherits the same security machinery instead of routing around it.
The mechanics, concretely:
- Execution identity is the calling user. When you ask Sense a question, the resulting tool calls carry your identity. The data layer applies your record-access policies, sharing rules, and field-level permissions exactly as if you had opened a list view and filtered it yourself.
- Row-level security shapes every answer. Ask for overdue receivables and Sense queries the receivables you are entitled to see. A colleague with a different territory asking the identical question gets a different — correctly different — answer.
- Field-level security shapes it too. If a field is hidden from your profile, it is hidden from Sense when Sense works for you. The assistant cannot summarize, aggregate, or "accidentally mention" data your profile blocks, because the query it runs never returns that data.
- Routing respects visibility. Tenants can build multiple agents in AI Studio and scope each one to an audience. When Sense routes your question to a specialist agent, it can only pick from agents you are allowed to use — and after routing, the execution identity is resolved again for that specific turn. Nothing slips through on a technicality.
The same principle extends to administration. Sense Control, the copilot that configures entities, forms, rules, and integrations through conversation, runs every one of its actions as the signed-in administrator, through the same APIs, validation, and permission checks the setup screens use. An admin who cannot delete an entity from the UI cannot delete it by asking nicely in chat.
Writes are a different class of action
Reading with your permissions is necessary but not sufficient. Writes get two additional controls.
First, capability gating. Tools are bundled into named capabilities, and each agent is granted an explicit set. An agent built to answer questions holds query capabilities and nothing else — write tools are not in its toolbox, so it cannot use them no matter what the conversation contains.
Second, approval gates. Actions that change your data pause and present what they are about to do; you approve or deny in the chat. When Sense drafts a report or a dashboard from a plain-language ask, the draft lands as an approval, never a silent write. When Sense Control builds a change, it previews first — records materialize without persisting, rules run in memory, integration flows dry-run with side effects off — and destructive steps like deletes, activations, publishes, and bulk imports stop on an explicit approval dialog.
One design detail matters more than it looks: the approval-required tool list is union-only. Tenant configuration can add approval requirements on top of the platform's set. It can never remove one. A misconfigured tenant can make Sense more cautious, but not less.
Everything leaves a trail
Because Sense works through the platform's own APIs under a real user identity, it produces the same audit evidence as any other actor in the system. Every tool call, every approval, every denial is recorded against the person who asked. When your auditor wants to know who read a record or who authorized a change, the answer is a name, not a bot.
xMatix also ships "explain why this user sees this record" diagnostics for administrators. That tooling works for Sense interactions the same way it works for screen access, because it is the same access.
Why we chose this design
Runs-as-you is harder to build than a service account. We chose it for three reasons.
- It survives a security review. The first question any serious reviewer asks about an AI assistant is "what can it access?" Our answer is a sentence: exactly what the asking user can access, enforced by the same layer that enforces it everywhere else. There is no second permission model to audit, and no gap between the two.
- There is no second path to the data to reason about. A prompt injection, a cleverly phrased question, a confused model — none of these can surface data the user is not entitled to, because the tools the model calls physically cannot return it. We do not have to trust the model's judgment about confidentiality. We removed the decision from the model.
- Trust is what makes AI usable. Teams only lean on an assistant when nobody has to wonder whether it will overshare. When permissions are inherited, the CISO can approve the rollout without carving out exceptions, and users can ask real questions about real data on day one.
The same rule at the edges
The boundary holds even when the AI is not ours. xMatix exposes a standards-compliant MCP server, so external AI clients your team already uses can query tenant data and search knowledge — authenticated, tenant-isolated, and scoped by the same permissions and audit as everything above. Whatever the client, whoever the model, the rule is the same: the AI acts as the person behind it, or it does not act at all.
That is the whole design. Not a smarter prompt, not a longer policy document — an assistant that structurally cannot exceed the person it serves.