Start agents read-only and widen access on purpose

The first week with a new agent is when you know least about how it behaves on your data, your tools and your team's habits. It is also when many teams hand it the broadest access, because setup is easier that way and nothing has gone wrong yet. Reverse that. Give new agent access its narrowest useful form, which is usually reading, and widen it in steps you choose, each one backed by what you saw in the step before.

What starting read-only buys you

A read-only agent can still do most of the valuable work: research, summaries, comparisons, extraction, drafts. What changes is the cost of its mistakes. A wrong summary is caught in review; a wrong write may be caught by a customer. Read-only also gives you something you cannot get any other way: a record of what the agent would have done. Its drafts, its proposed changes and the requests it could not carry out show you its judgment before that judgment touches anything.

It also shortens the conversation about trust. Instead of debating whether the agent is ready to write to the CRM, you look at a stretch of drafts it prepared for the CRM and decide on evidence.

Read-only is narrower than it sounds

“Read-only” is a property you have to check, not a label you can trust. A few places where it leaks:

• Reads with side effects. Some APIs mark a message as read, start a paid lookup or log an access event when you only fetch data. Check what each read endpoint does, not what it is called.
• Reading can still move data. An agent that can read a customer folder and send a summary anywhere has an export path, even if it cannot write a single file. That is why sending and exporting pause as action classes of their own.
• Reading too much. Read access to every system is still broad access. Start with one project and the documents the work actually needs.
• Read content can carry instructions. A document or page can contain text written to steer the agent. Read-only limits what that text can make the agent do, which is one more reason to start there.

Where you can, enforce read-only in the system being read, with a view-only role or a token scoped to reading, rather than relying on the agent's instructions to behave.

A credential is not a permission

The most common way access widens by accident is through credentials. Someone connects an account so the agent can read a calendar, and the token they granted also allows creating events. Nothing in the setup is wrong, yet the agent can now write.

Separate what the agent can do from what it may do. In GoCux, a granted credential does not by itself authorise writing without a person, and registering a connector does not mean every task may use it; credentials are kept on the server as references instead of living in the browser. The same holds for skills: a reusable instruction that explains how to update a record is not permission to update it. Connect tools without widening authority goes deeper on connectors, and for MCP servers the MCP quickstart recommends starting read-only for the same reason.

A staged rollout

Widen access in stages, each with a clear exit condition. The stages below are a starting point; rename or merge them to fit your team.

1. Drafting only. The agent works only with what it is given and makes no tool calls. Useful for testing instructions and output format. Move on when its drafts need only light edits.
2. Reading within one project. The agent reads the project's documents and the sources the work needs. Move on when its research holds up in review and it stays inside scope.
3. The agent proposes writes, a person applies them. The agent prepares the email, the record update or the change set; a person sends or applies it. Move on when proposals are routinely applied as written.
4. Gated writes. The agent may write, and every consequential action, such as sending, exporting, deleting or scheduling, pauses for a decision. Move on class by class, when decisions become routine and the pauses are being read rather than clicked through.
5. Bounded autonomy for low-risk writes. Routine, reversible writes run without a pause, inside the work order's limits on scope, time, tool calls and spend. The consequential classes still pause.

Not every agent needs to reach the last stage. Many useful agents should stay at the second or third for good.

What to look at before widening

Each step up should be a decision made on the record, not a setting someone flipped. Before widening, review:

• What the agent read, and whether any of it fell outside the scope you intended.
• What it proposed, and how often proposals were changed before being applied.
• What it tried and could not do. Refusals and blocked calls show where it is pushing against its limits.
• Whether anything it read tried to instruct it, and how it responded.

The audit trail is where those answers live. If it cannot answer them, fix the trail before you widen anything.

Checklist for a new agent

• Access starts with one project and read-only scope, enforced in the systems being read.
• Every credential has been checked for what it actually allows, not only for what it was meant to do.
• Connectors and skills are enabled per task, not assumed for every task.
• Sending and exporting are gated even at the read-only stage, since reading can still move data.
• Each widening step is written down, with who decided it and what evidence they looked at.
• Narrowing access again is as easy as widening it.

When you reach the gated stage, the seven action classes describe what should keep pausing, and the security page covers how GoCux handles credentials and boundaries.