Should an AI agent start with read-only access?

As usual, everything with AI is about permissions. Logins and permissions. If that were solved, we'd be going so much faster. But the one time we moved fast without boundaries, it cost us.

What went wrong without boundaries?

In August 2026, an AI-assisted database operation wrote 725,000 rows into greetform's production database. Production and staging weren't separated.

What access did my agent start with?

• Code: read access to GitHub, prioritized first
• Work email: read-only
• CRM and broad write access: deferred until later

One more rule from that: a teammate's supervised access shouldn't be inherited by an unattended automation.

Doesn't read-only make agents useless?

For a while, it limits them, and that's the tradeoff. By late September 2026 my view was that the chief-of-staff agent should have maximum access, not less than the other agents. The way I square the two: start read-only, separate test from production, then widen access deliberately.

An integration layer helps. I use Composio so I'm not connecting each app with its own individual API key.

What should the agent never do without asking?

When I gave my system a standing go to build, review, merge and verify without asking, I kept three exceptions: deleting data, messaging people outside the company, and anything involving money. Those still need a yes from me.

How do I set this up on Monday?

1. Separate production from staging before any agent touches a database.
2. Give a new agent read access first.
3. Give each agent its own identity instead of borrowing a person's logins.
4. Write the three ask-first exceptions into its instruction files.
5. Widen access one system at a time as it proves itself.