AI Guides › Skills & Agents
What "Tool Access" Actually Means When You Grant It To An Agent
By Nigel Guy · 2 min read
Granting an agent access to a tool reads like a single decision — on or
off, allowed or not. Treating it that way skips over the fact that "tool
access" is actually several separate permissions bundled under one
approval, and most of the surprises come from whichever part of that
bundle you didn't think about at grant time.
The rule: "tool access" is never one thing — it's a bundle of what the
tool can read, what it can change, how often it can be called, and what it
can do without asking again — and granting it without unpacking that
bundle means you've agreed to all four without reviewing three of them.
The mechanism: the Access Bundle
Before granting an agent access to any tool, unpack it along these four
lines:
- Read scope. What data can it actually see through this tool? Often
wider than the task needs — a tool granted "to check this one record"
frequently has visibility over the whole table it lives in.
- Write scope. What can it change, create, or delete through this
tool, and is that the same scope as the read access, or narrower? Read
and write scope aren't automatically matched, and assuming they are is
how a "just look it up" grant turns into a "just changed it" surprise.
- Call frequency. Can it call this tool once per task, or
continuously, in a loop, without you seeing each call? A tool that's
perfectly safe used once can behave very differently used two hundred
times in an hour, especially anything rate-limited, costed per call, or
externally visible.
- Standing vs. one-time. Does this grant apply to this one run, or
does it persist — available to this agent, or any agent using this
skill, indefinitely, until someone revokes it? A standing grant is a
different risk profile from a one-time one, even if the tool and scope
are identical.
Write out an answer to all four before approving, not just the first one
that occurred to you when the request came in.
What to skip
Skip approving a tool grant based on its name alone — "calendar access" or
"file access" tells you the category, not the bundle. Skip assuming a
platform's default scope for a tool is the scope you actually want; the
default is usually set to be broadly useful, not narrowly appropriate to
your specific task.
Guardrails
- Some platforms don't let you unpack all four lines separately — the
tool's access is what it is, take-it-or-leave-it. Where that's true, the
decision becomes whether the bundled risk is acceptable as a whole, not
a reason to skip thinking about the four lines.
- Re-check standing grants periodically. A grant that made sense for the
task it was approved for can quietly become inappropriate as the task,
or the agent's use of the tool, changes.
- This is about understanding the grant, not a claim that narrow grants
are risk-free. A narrowly scoped tool used on the wrong input at the
wrong moment can still cause real harm — narrow scope reduces the blast
radius, it doesn't eliminate it.
All 751 AI guides · JulieMango plans from £17/mo