Should an AI agent start with read-only access?
Short answer
Start read-only where an agent can wreck real data, then widen fast. One AI-assisted job wrote 725,000 rows into production because test and live weren't separated. But after three months of agents, the bigger problem has been agents blocked from obvious work. My rule: they can draft and edit almost anything; only a human hits publish.
As usual, everything with AI is about permissions. Logins and permissions. If that were solved, we'd be going so much faster. But when we moved fast without boundaries, it cost us.
My answer has two halves. Start read-only on anything that can damage real data. Then widen access much faster than feels comfortable, because a blocked agent is the more common failure.
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.
That's the case for read-only first. The damage came from a missing wall between test and live, so the first fix was the wall.
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.
Is too much access or too little the bigger risk?
Too little, by a lot. After about three months of setting up agents, the pattern was obvious. Over and over, an agent couldn't do something it clearly should have been able to do. Agents doing things they weren't supposed to? Near zero.
"The biggest problem is finding out all the things they're limited on. That is the problem, not protecting secrets that we don't have."
So I lean toward more access, more value over control and protection. When I set up my assistant agent, the list of what I wanted it to touch was long: lightbreak, greetform, my Meta ads, Beehiiv (including creating things there), the tools we've built, and our CRM. I also gave it Google Drive, because long-term memory matters that much.
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 and quickly.
An integration layer helps. I use Composio so I'm not connecting each app with its own individual API key.
Where do I draw the hard line?
At the publish button. Agents can do everything except hit publish.
My editor agent, for example, should be able to read a batch of articles on the site and edit them right on the page. Then it sends me the link: here's what I changed, read the new version, and here's where to hit publish if you like it. Drafting, editing and creating are fine. Going live is mine.
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?
- Separate production from staging before any agent touches a database.
- Give a new agent read access first.
- Give each agent its own identity instead of borrowing a person's logins.
- Write the publish line and the three ask-first exceptions into its instruction files.
- Ask the AI what the agent is still blocked from, and widen access one system at a time.
Answered by TJ Larkin. From team calls, internal agent security notes and my own AI chats in 2026. Last updated .