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.