Tool permissions

Expanded Definition

Tool permissions are the policy layer that constrains which tools an LLM or agent can call, which operations it can invoke, and which parameters it can submit. In practice, they sit between model reasoning and real-world execution, reducing the risk that a capable agent turns a valid instruction into an unsafe action. For NHI Management Group, the key distinction is that tool permissions govern operational authority, not model quality: a well-aligned model can still cause harm if it can access high-risk APIs, privileged workflows, or unrestricted parameter sets.

Definitions vary across vendors, especially where product documentation blends tool permissions with function calling, plugin policies, or broader agent guardrails. The security meaning is narrower and more actionable: enforce only the minimum callable tools, scope each tool to approved actions, and validate parameters before execution. This aligns with identity and access control principles reflected in NIST SP 800-53 Rev 5 Security and Privacy Controls, where authorization, separation of duties, and system integrity remain central concerns.

The most common misapplication is treating prompt instructions as if they are sufficient access control, which occurs when organisations expose powerful tools to an agent without enforcing per-tool authorization, argument validation, or execution logging.

Examples and Use Cases

Implementing tool permissions rigorously often introduces workflow friction, requiring organisations to balance agent autonomy against the cost of tighter approval paths and narrower tool scope.

• An internal support agent may be allowed to read ticket status and draft replies, but blocked from closing incidents or refunding customers unless a human approves the action.
• A finance workflow agent might query invoice records, yet be denied access to payment execution tools, because a single erroneous call could create direct fraud exposure.
• A software engineering agent may open pull requests and run tests, but be prevented from merging code or rotating secrets without a separate privileged approval step.
• An operations agent can restart a non-production service, while production change tools are restricted to a narrower role set and session-based authorization.
• A non-human identity inventory agent can read metadata from service accounts, but it should not be able to create, rekey, or deactivate identities unless the action is explicitly approved, consistent with the governance concerns highlighted in the OWASP Non-Human Identity Top 10.

These use cases show that tool permissions are not only about blocking dangerous tools. They also define safe granularity, so an agent can still be useful without gaining unrestricted execution power across business systems, identity platforms, or privileged admin interfaces.

Why It Matters for Security Teams

Security teams need tool permissions because agentic systems can convert a minor prompt error, malicious input, or misrouted workflow into a real operational event. Without explicit permission boundaries, an LLM may invoke tools that modify records, move money, alter identities, or change infrastructure state. That creates a direct bridge between model risk and enterprise risk, which is why tool permissions belong in access governance rather than only in application design.

For identity and NHI programs, the issue is especially acute. Agents often operate through service accounts, API keys, or delegated credentials, so weak tool permissions can magnify the blast radius of a compromised NHI. Security teams should pair least privilege with monitoring, revocation, and audit trails, then map the controls to standards-based governance such as NIST SP 800-53 Rev 5 Security and Privacy Controls. The practical question is not whether an agent can reason well, but whether it can do only what it is truly authorised to do.

Organisations typically encounter the consequences only after an agent has already changed production data or triggered an unauthorised workflow, at which point tool permissions become operationally unavoidable to address.

Related resources from NHI Mgmt Group

• 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?
• What breaks when tool permissions match names but not parameters?