Give the Agent Read Access First. Write Access Is a Later Decision.

If you're wiring up an agent or a tool that can touch real systems, here is the short answer.

Start it with read access. Treat write, delete, send, and spend as a later decision — one you make after you've watched how it fails.

Cleverness is not a reason to grant write. Neither is "it worked in the demo."

Why read first is the default

An agent with read access can look at files, logs, tickets, docs, and dashboards. If it gets something wrong, the worst case is a bad summary or a wasted hour. You still have the originals.

An agent with write access can change those same things. It can edit a config, open a pull request, send a message in your name, move money, or delete a record. Some of those actions reverse cleanly. Some don't. Some reverse only after you've already paid the social cost of the mistake.

Read and write aren't two settings on the same dial. They're different jobs. Read is how you learn what the agent can do. Write is how you let it change the world.

Blast radius is the real question

Before you hand over a capability, ask what happens if the agent uses it wrong once.

If it misreads a log file, you correct it and move on. If it mis-sends an email to a customer, you're apologizing. If it deletes a production row, you're restoring from backup — if you have one that covers that moment. If it spends against an API or a payment rail, the money may already be gone.

That gap between "annoying" and "irreversible" is the blast radius. Read-first keeps the radius small while you're still learning the agent's habits: what it invents, what it skips, where it gets confident without being right.

You can expand the radius later. Expanding it early is hard to undo after the first bad send.

Reversible vs irreversible

Not every write is the same. Sorting them helps.

Usually reversible: drafting a file in a sandbox, opening a branch, leaving a comment on a draft ticket, writing to a scratch database you can wipe.

Sometimes reversible, costly: editing a live config (you can roll back if you logged the old value), updating a ticket status (you can flip it back, but people already saw the wrong state), posting to a private channel (you can delete, after people read it).

Hard or impossible to reverse cleanly: sending email or chat under your name, spending money, deleting without a soft-delete trail, posting in public, granting someone else access.

Put the last group behind a human gate until you have a reason not to. "The model is smart" is not a reason. A reason looks like: you've run it for weeks, you log every action, you have a rollback path, and a person still approves the irreversible step.

Human approval for the sharp edges

Some actions should stay behind a yes from a person, even after the agent has earned broader write access.

Sends. Spend. Deletes that aren't soft. Sharing something outside your own walls. Anything that puts words in your mouth or money out of your account.

That doesn't mean the agent can't prepare the work. It can draft the message, fill the form, stage the change, and show you the diff. The difference is who presses the button that makes it real.

If your tooling can't separate "prepare" from "commit," fix the tooling before you widen permissions. An agent that can only act by doing the irreversible thing is an agent you shouldn't give those keys to yet.

What "read first" looks like in practice

In a real setup, read-first often means something concrete:

• The agent can list and read files in a repo, but can't push, force-push, or merge.
• It can query a database with a read-only role, not a role that can UPDATE or DROP.
• It can draft an email in a drafts folder, not hit send.
• It can propose a calendar hold, not book it.
• It can summarize tickets, not close them or reassign them without you.

When you later add write, add it for one class of action at a time. Let it edit a markdown file in a branch before you let it touch production configs. Let it comment before it closes. Let it stage a purchase before it spends.

Each new permission is its own decision. Bundle them and you learn nothing when something breaks — you only know that "write" was too broad.

Logging is not optional

If you can't see what the agent did, you can't shrink the blast radius after the fact, and you can't argue that it earned more access.

Log the tool calls: what it requested, what it got, what it wrote, who approved the irreversible step. Keep enough context that a person can reconstruct the hour. You don't need a novel. You need a trail.

Logging also teaches you the failure modes. Agents don't only fail by being wrong. They fail by being almost right, by looping, by acting on stale context, by treating a guess as a fact. Those patterns show up in the logs long before they show up as a disaster — if you're looking.

Cleverness is the wrong test

Teams often widen permissions because the agent looked sharp in a demo. It found the bug. It wrote a clean summary. It suggested a good fix.

That's evidence it can read and reason. It is not evidence it should send, spend, or delete.

The test for write is uglier and more useful: what does it do when the tools return garbage, when two sources disagree, when the user is vague, when the safe move is to stop? If you haven't seen those days, you haven't seen the agent. You've seen the highlight reel.

A short checklist

1. Start read-only for any new agent or tool path that touches real systems.
2. Name the irreversible actions up front: send, spend, hard delete, public post, access grants.
3. Require a human yes for those until you have a logged track record and a rollback story.
4. Add write one class at a time, not as a single "full access" switch.
5. Prefer prepare-then-commit: draft, stage, diff — then a person (or a narrow auto-rule you've tested) commits.
6. Log every tool call that matters, including approvals.
7. Revisit permissions on purpose. Expanding access should be a decision with a date, not a side effect of shipping a feature.

The short version

Give the agent eyes before you give it hands.

Read access lets you learn how it thinks without letting it change your world. Write access — especially anything that sends, spends, or erases — is a separate call you make after you've seen the failure modes, not because the demo looked smart.

When I'm not thinking about who gets which keys, I write The Shadows Series, which starts with Shadows of the Forgotten: https://johndclay.com/books