Per-Tool Permissions

What Per-Tool Permissions Are Trying to Control

Per-tool permissions break access down by tool boundary, so an agent or user can only perform the actions that are explicitly needed in each connected system. That matters because a tool is often where “read” becomes “change” or “execute,” which is where blast radius expands.

In agentic AI and NHI governance, the core value is not just limiting access overall, but limiting it at the point where the agent reaches into a specific app, API, or workflow. That makes permissions more precise than broad role grants and easier to reason about when multiple tools are chained together.

Why Tool-Level Scope Matters

Tool-level scope is a control boundary, not a convenience feature. If one tool is overbroad, a single compromised prompt, token, or approval path can expose unrelated data or trigger actions the operator never intended.

This is especially important when the same agent can search, retrieve, update, and submit across different systems. A good per-tool model keeps those abilities separate so that access to one connector does not silently imply access to everything behind it.

Per-tool permissions also reduce confusion during change review. Teams can ask a narrower question, namely what this tool can do, rather than assuming one general agent permission covers every downstream action.

How Per-Tool Permissions Are Commonly Applied

In practice, per-tool permissions are usually paired with task-scoped access, action-level allowlists, and approval gates for higher-risk operations. The exact design varies by platform, but the intent is consistent: keep each connector on a tight leash.

That means differentiating between tools that only read data, tools that can create or modify records, and tools that can trigger external side effects such as sending messages, changing tickets, or rotating secrets. Those distinctions are often the difference between a harmless lookup and an expensive mistake.

They also need to be evaluated alongside the tool's own internal privilege model. A restricted agent can still cause damage if the connected tool itself is mapped to an overpowered account or a broad API key.

Where Per-Tool Permissions Fail

Per-tool permissions fail when the control is defined too broadly, inherited from a default role, or left unchecked after new tools are added. The result is usually hidden privilege creep, where the permission model says “limited” but the actual tool action set is still wide open.

They also fail when organisations treat the agent as trusted once authenticated, instead of continuously checking whether the specific action is appropriate for that tool and context. In that situation, a single compromised or misbehaving agent can move from one benign connector to a high-impact system faster than operators expect.

Risk and Threat Considerations

Per-tool permissions reduce blast radius, but they also create a new governance failure mode if teams assume the boundary is stronger than it really is. The main risk is overconfidence: a narrow-looking permission surface can still permit destructive or exfiltrating actions inside the one tool that was granted too much power.

Failure mechanism: A compromised agent, stolen credential, or abused approval path uses its allowed tool scope to read sensitive data, alter records, or trigger side effects that were never meant to be reachable from that workflow.

Impact: The outcome can include data exposure, unauthorised changes, lateral movement through chained tools, and a much larger incident scope than the original permission model suggested.

Practitioner Guidance

Why practitioners should care: Per-tool permissions are only useful when each connector has its own clearly justified action set. If the same access pattern is reused across tools without review, the model stops being least privilege and becomes shared overreach.

Common misunderstanding: Teams often treat “connected” as if it automatically means “allowed.” The safer assumption is the opposite: every tool should default to the smallest action set that still supports the workflow.

Practitioner takeaway: Review each tool separately for read, write, and execute capability, then tighten the scope again whenever the workflow changes.

Related resources from NHI Mgmt Group

• Guide: AI Agent Tool and Plugin Security Guide
• Why do coding agents need per-tool authorization instead of session-wide permissions?
• What breaks when MCP tool permissions are scoped too broadly?
• What breaks when MCP governance only models tool permissions?
• What breaks when tool permissions are managed only in application code?