Read/Write Scope

How it works

Read/write scope splits an agent's access into two capability classes and grants them separately. A read grant lets the agent observe: query a database, fetch a file, list records, call an inspection endpoint. A write grant lets it mutate: create a row, update a record, send a message, delete an object, move money. The boundary is enforced at whatever layer holds the real authority, and usually at several:

1. Credential — the token or key itself is scoped read-only or read-write (for example, a database role with SELECT but no INSERT/UPDATE/DELETE).
2. Tool surface — the harness only exposes read tools for a given task, and withholds the mutating tools entirely.
3. Runtime gate — a write tool is present but every call passes through an approval or policy check before it commits.

The principle is that reading and writing are different risk classes. A wrong read wastes tokens; a wrong write changes the world. So the default posture is read-only, and write is a deliberate, narrow, auditable escalation — not a property the agent carries everywhere it goes. Good harnesses make the two visibly distinct at call time, so a reviewer can see which actions merely looked and which actually changed something.

Why it matters in an agent harness

Models are stochastic, and a mutating call executed on a bad inference is not a retry — it is a side effect. If read and write ride the same credential, every planning step, every exploratory query, and every prompt-injected instruction runs with the full authority to damage live state. Separating the scopes shrinks the blast radius of the entire read-heavy majority of an agent's work to near zero.

It also makes the harness legible. When writes are a distinct capability, you can log them separately, rate-limit them independently, require approval only on them, and reason about reversibility only where it matters. An agent that spent forty tool calls reading and one call writing has one line worth auditing, not forty-one. Scoping this way turns "what did the agent do?" from a forensic reconstruction into a short list of committed mutations.

And it contains prompt injection and tool misuse structurally rather than by hoping the model behaves. Untrusted content the agent reads cannot escalate into a destructive action if the current task was never granted the write tool in the first place. The boundary holds regardless of what the model was convinced to attempt.

Read/write scope vs least privilege

They are often conflated, but they operate at different levels and answer different questions.

Read/write scope is the crude, high-value first move; least privilege is the endpoint where a write grant is narrowed further to specific tables, specific verbs, specific records, and a specific window. If you only do one thing, do the read/write split — it removes the largest category of irreversible mistakes for the least design effort.

The Rifty take

We treat read-only as the resting state and every write as an escalation that has to be requested, scoped, and justified per task — not a standing capability the agent keeps. We accept that this adds a gate and occasionally slows a workflow, because the tradeoff is worth it: the cost of a delayed write is a few seconds, and the cost of an unbounded one is a corrupted production record. The boundary we enforce is that no read-only task ever holds a write credential it does not need.

Implementation checks

• Scope the credential, not just the prompt. A token that can only SELECT cannot be talked into a DELETE, no matter what the model reads.
• Give read-only tasks a read-only tool surface; do not register mutating tools the task will never legitimately use.
• Make every write idempotent where possible, so a retried or duplicated call converges instead of compounding.
• Log reads and writes on separate channels so audit is a short list of mutations, not a full trace.
• Put approval gates on the write path only, and keep the read path fast and ungated.
• Ensure each write has a defined reversal — a rollback, a soft delete, a checkpoint — before you grant the scope.
• Re-scope per task rather than per session; a broad grant that outlives its reason is the failure you are trying to avoid.

Frequently asked questions

Why separate read scope from write scope at all?

Because they are different risk classes. A wrong read wastes tokens and can be discarded; a wrong write changes live state and may be irreversible. Separating them shrinks the blast radius of an agent's read-heavy majority to near zero and confines auditing, approvals, and reversibility to the calls that actually mutate the world.

Where should the read/write boundary be enforced?

At the layer holding real authority, and ideally several. Scope the credential itself (a read-only database role), scope the tool surface so mutating tools are not exposed for read tasks, and gate the write path at runtime with approval or policy. Prompt-level instructions alone are not a boundary; they can be overridden by injection.

How is read/write scope different from least privilege?

Read/write scope is one coarse axis — can this task mutate state or only observe. Least privilege is the broader principle that a task should hold exactly the access it needs and no more. The read/write split is the cheap, high-value first cut; least privilege is the finer discipline that then narrows a write grant to specific verbs, records, and windows.

Does scoping writes stop prompt injection?

It contains a large class of it structurally. If a read-only task was never granted a write tool, untrusted content it ingests cannot escalate into a destructive action, regardless of what the model is convinced to attempt. It does not stop injection that only needs read access, so pair scoping with sandboxing and output review.

How do I safely widen an agent from read-only to read-write?

Escalate per task, not per session. Grant the narrowest write capability the specific task needs, route it through an approval gate, make the operation idempotent, and confirm a defined reversal exists — rollback, soft delete, or checkpoint — before committing. Then let the grant expire so a broad write capability never outlives its reason.