Reads everything, writes almost nothing

The security question people ask about an enterprise AI assistant is usually "can it see things it shouldn't?" The question they should also ask is "what can it do?" — because a system that reads widely and writes freely is a much larger risk than one that reads widely and writes narrowly.

Sense is deliberately asymmetric. Its read surface is broad. Its write surface is one tool, approval gated, and incapable of creating or deleting anything.

The tool registry is the boundary

An agent can only do what its tools permit. That sounds obvious, and it is routinely undermined in practice by a single generic "execute" tool that can run arbitrary operations — at which point the real boundary is whatever the prompt talks the model out of, which is not a boundary at all.

Our built-in tool registry is closed and enumerable. It covers discovery (what entities exist, describe one, inspect relationships), retrieval (query records, query related records, aggregate, summarise), reporting (list, describe and run existing reports, draft new reports and dashboards), knowledge (search grounding material, read platform documentation), extension points (tenant-defined script tools, MCP tools), and vision (analyse a shelf photo).

Against all of that, the write surface is: update an existing record's fields, and publish nudges. There is no create tool. There is no delete tool. There is no run-arbitrary-action tool.

Why "no create, no delete" is a deliberate line

Update is bounded in a way creation is not. To update, 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 trail — a wrong update is visible, attributable and reversible.

Creation has no such anchor. An agent that can create can generate documents that look legitimate, enter approval workflows, and consume budgets, with no prior record to reconcile against. Deletion is worse still: the evidence of the mistake is the thing being destroyed.

This does cost capability. Sense cannot raise the purchase order it just recommended. We think that is the right trade for now — and the honest framing is that expanding the write surface is a decision to be made deliberately, per action, with approval semantics designed in, rather than a general capability switched on because it demos well.

Runs as you, not as a service account

Every tool call executes under the identity of the person asking. The agent does not hold its own credentials or a privileged service account.

The consequence is that the platform's existing two-layer security — record access policies and field-level permissions — applies unchanged. If a regional manager cannot see another region's accounts, the agent cannot retrieve them for that manager. There is no separate AI permission model to keep in sync with the real one, which matters because two permission models inevitably drift, and the drift is only discovered when someone sees something they shouldn't.

It also means prompt injection has a much smaller blast radius. A cleverly worded instruction can, at worst, make the agent do something the user could already have done themselves — which is the correct ceiling for an assistant.

Approval as a gate, not a notification

Writes are approval-gated: the agent proposes, a person accepts, and only then does the change land. The distinction worth drawing is between approval and notification. A notification tells you what happened and is a log. Approval happens before, and is a control.

Approval is also where the evidence earns its keep. Accepting "set the quantity to 24" is a coin flip. Accepting "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 actually make in a few seconds. Approval only works when the person approving has enough to decide with.

What is recorded

Agent activity lands in the same audit trail as human activity — who asked, which tools ran, what was changed, and under whose permissions. Not a separate AI log, but the platform's own trail, so an investigation does not have to correlate two systems and hope the clocks agree.

Budgets sit alongside, enforced before a model call rather than reconciled after, so consumption is a control rather than an invoice surprise.

What we would tell another team

Write your agent's capability list as a sentence and read it aloud to whoever owns risk. "It can read anything the user can read, update fields on records they can already edit with their approval, and nothing else" is a sentence a CISO can evaluate. "It has access to the API" is not.

Then check where that boundary is enforced. If the answer is "the system prompt tells it not to", it is not enforced. Ours is enforced by the absence of the tool — the model cannot be persuaded into an operation that does not exist.