← All posts

Visibility

Tool visibility: don't show an agent what it can't use

There is a quiet assumption in a lot of agent setups: that listing a tool is harmless, because the agent will only call it when appropriate. Models are not that disciplined. If a tool is in the list, it is on the table — for the right task, the wrong task, and anything an injected instruction can talk the model into.

Discovery is permission's first gate

The cheapest way to prevent a misuse is to make the tool invisible to workers whose role does not need it. A sales-ops agent that never sees github.git_push_repo cannot be tricked into calling it. Visibility filtering shrinks the agent's action space to its job before any reasoning happens.

Why "the prompt will handle it" fails

  • Prompts are advisory; tool lists are operative. The model can ignore the former and still reach the latter.
  • Long tool lists degrade tool selection — more options means more wrong picks, even without malice.
  • Every visible tool is attack surface for prompt injection carried in fetched content.
The safest tool is the one the agent never knew existed.

Role-scoped catalogs

Define what each role can see, and let the permission layer assemble the tool list per worker at connection time. The agent code does not change — it just receives a smaller, safer menu. Grantry filters tools by role before the agent sees them, so overexposure stops being a thing you hope the prompt prevents.


Grantry

Show each worker only the tools its role allows.

Start for free

Questions first? Email [email protected].