If this sounds familiar
Say you run a small online store and want to hand an AI agent a job like "find out why sales dropped last week." The first question you hit is this one.
How much access should the agent get?
The payment dashboard, the ad account, web analytics, server logs. Open everything and the agent will probably do the job well, but it feels risky. Open nothing and it can't do the job at all. So most people settle on "give it broad access and tell it to be careful."
This note argues for the opposite. Don't grant access up front. Open it one piece at a time, based on records of where the agent got stuck.
What goes wrong with broad access
Broad access brings two problems with it.
- Doors you don't need are open. Analyzing sales doesn't require the power to issue refunds. But if that power is there, some day the agent may decide "this order looks odd, let me clean it up." Most accidents happen simply because something could be done.
- You never learn what was actually needed. With everything open, nothing records what the agent relied on. When you later try to trim its access, you have no basis for deciding what to keep.
Go too narrow, though, and a stuck agent fills the gap with guesses. You get a plausible conclusion like "probably because ad spend went down." That is the most dangerous outcome of all. A plausible wrong answer survives far longer than an obviously wrong one.
Do this instead
Teach the agent two things together.
- When stuck, stop. Don't fill what you can't see with guesses. Write down "I don't know."
- Record exactly why you got stuck. Not "no permission," but what you needed to see, and why.
Here is the difference between a bad record and a good one.
| Bad record | Good record |
|---|---|
| Couldn't see ad data, so the analysis is incomplete | To tell whether the sales drop came from ads, I need the ad account's spend and clicks for the past two weeks, but I have no read access to the ad account |
| Need access | Needed: read-only access to the ad account (spend, clicks). Write access is not needed |
A good record holds three things: what it tried to see, why it needed to see it, and the least it would need. With those three, a person can open exactly that one permission without a second thought.
Lines to put in your instructions
You can drop the following straight into the agent's instructions (its system prompt or working rules).
If you need to see X to answer and you can't, stop there and write it down.
- What you tried to see
- Why the answer depends on it
- The least access that would do (read or write, and what scope)
Don't fill the gap with guesses or conclude "it's probably this."
And set one rule for the people, too.
Open access only when there is a stuck record, and only as far as that record asks.
What changes when you do this
- Access grows with the work. At first the agent can barely do anything, but after a few weeks only the places it actually gets stuck are open. Doors it doesn't need were never opened.
- You can trust its conclusions. An agent that writes "unknown" for what it couldn't see is one whose written conclusions come from things it actually saw.
- Every permission has a reason. "When and for what job was this opened?" stays on record, which gives you a basis for cleaning up later.
Common mistakes
- Writing only "tell me if you lack access." The agent then reports that it got stuck but leaves out why, and a person has to ask again. Spell it out in a sentence: what, why, and how little would do.
- Opening broadly every time it gets stuck. "This is tedious, just give it admin" puts you back at square one. If the record asked for read access, open read access only.
- Treating a stop as a failure. A session that stopped because it got stuck is not a failure. Its record is the most precise guide to what to open next. Blame the stopped session, and next time the agent will fill the gap with guesses.
What actually happened
While analyzing traffic for one of our services, our agent ran into an analytics property it had no access to. Instead of guessing, it wrote "I have no read access to this property, so I couldn't see any data" and stopped. We opened just that one read permission, as the record asked, and the next session picked the analysis right back up. Over ten days, 7 of the 10 records that piled up were this kind — "stuck because a tool was missing" — and every permission we opened was one those records asked for.
