The read-only assistant that could still change things

A security engineer at a mid-market company told me about a mismatch between what everyone said and what was true. The team described their assistant as read-only. It answered questions, it summarized, it retrieved. In every conversation it was referred to as safe because it only read. Then the engineer traced what its tools actually did and found that one of them called into a workflow that, several steps down, wrote to a downstream system. The assistant could not write directly. It could trigger something that wrote. Read-only was the intent, and it had become the label, but it was not an accurate description of what the assistant could cause to happen.

This gap shows up constantly. A feature gets a reassuring label based on what it is supposed to do, and the label sticks, and people reason about safety using the label instead of the actual capabilities. Read-only, sandboxed, isolated, low-risk. These words describe intent. What matters for security is capability, which is the full set of things the feature can cause, including everything reachable through the tools it calls.

The label describes intent, capability describes risk

When you call an assistant read-only, you are describing the job you had in mind. That is fine as a description of purpose. It becomes dangerous when it stands in for an analysis of what the assistant can actually do, because a tool that reads can call something that writes, and a chain of read-only-looking steps can end in a change to a real system.

Capability is the honest measure. It is the transitive closure of everything the feature can reach, not just its direct actions but everything those actions can trigger. A tool that kicks off a workflow inherits whatever that workflow can do. A retrieval step that can invoke a function inherits whatever that function touches. The assistant’s real power is the sum of all of it, and it is usually larger than the label suggests.

The reason this matters for security is that people size their defenses to the label. A read-only assistant gets treated as low-risk, so it gets less scrutiny, looser tool access, and fewer guardrails. Meanwhile its actual capability includes a path to a write, and that path is now protected as if it did not exist.

Verify capability, not the label

The fix is to stop trusting the description and trace what the feature can actually reach.

In practice:

Follow every tool to its end. For each tool the assistant can call, map what that tool can do, including anything it triggers downstream, until you reach the real effects.
Treat triggered writes as writes. If any path leads to a change in a system, the assistant is not read-only, regardless of what it is called.
Match guardrails to real capability. Size your confirmations, scopes, and monitoring to what the feature can actually cause, not to its reassuring label.
Re-check when tools change. Adding a tool or extending a workflow can turn a genuinely read-only feature into one that can write, so revisit the capability map when the tool set changes.

The teams that get this right earn their labels. If they call a feature read-only, they have verified that no path through its tools reaches a write, and they re-verify it when things change. The label becomes a conclusion, not an assumption.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week, $2,500 engagement, we trace what a feature can actually do rather than trusting how it is described. We follow each tool to its real effects, and we flag the read-only features that can, through some path, cause a write. It is a common and quietly serious gap, because everyone has been reasoning about the feature using a label that was never checked.

Read-only is a description of intent, and intent does not bound risk. Trace what the assistant can actually cause, and let the label follow the facts.