Skip to content
⚠️ Before You Start
Risk: High
Duration: 1-2 hours per agent
Last Validated: Not yet validated (draft)
Kind: Checklist
Risk Note: High (excessive agency lets a prompt injection act on real systems)

Tool security and per-tool permission review

Draft outline: not validated

Drafted with AI from official sources on 16 Oct 2026. Do not use on a live system until it is written, dry-run by someone other than the author and signed off (planned 2026-11-18). Author: Sanjay Sarvesh · dry-run: Yasar · sign-off: James. Work items: AGT-02-T13, AGT-02-T14, AGT-02-T15, AGT-02-T16.

1. Summary

Before any tool with side effects goes live, and quarterly for every agent's tool set.

Risk: High (excessive agency lets a prompt injection act on real systems). Typical duration: 1-2 hours per agent.

2. When to use and when not to

Use it when: Before any tool with side effects goes live, and quarterly for every agent's tool set.

Do not use it when:

  • A new read-only tool with no credentials and no access to user data does not need the pre-go-live review. It stays in scope for the quarterly review, because its outputs can carry injection payloads.
  • You are reviewing the agent's orchestration logic rather than its tool permissions. Use PB-AGT-02-03 for schema changes and PB-AGT-02-05 for outage handling.

3. What you must know first

4. Prerequisites

  • Agent's tool permission file
  • Registry entries with scopes
  • Identity and role assignments of the agent
  • Latest threat model

5. Checklist

  • Inventory tools. List each tool, its scopes and side-effect class from the permission file. Check: the list matches the deployed tool registry; no undocumented tool is callable.
  • Remove unnecessary tools. Remove tools the agent does not need for its current job. Check: attempt to call a removed tool and confirm it is rejected.
  • Verify identity scopes. Check each identity has only the scopes listed in the permission file. Check: query the identity provider or az role assignment list and compare.
  • Verify short-lived credentials. Confirm the agent identity uses short-lived, scope-limited tokens, not long-lived API keys. Check: inspect token lifetime and scope claims in a test call.
  • Confirm approval gates. Confirm approval is required for financial, deletion and external messaging tools. Check: call each side-effecting tool without prior approval and confirm it is blocked.
  • Validate MCP audience claim. Confirm MCP servers validate the audience (aud) claim on every inbound token and reject tokens issued for other services. Check: send a token with a mismatched aud and confirm a 401 response.
  • Sanitise tool outputs. Check tool outputs are sanitised before they reach the model (strip or escape markup, enforce a size limit). Check: send a tool response containing a known injection payload and confirm the agent does not execute it. See LLM01.
  • Check tool descriptions. Verify that tool descriptions exposed to the model do not leak internal implementation details such as endpoint URLs or database names. Check: review each tool's description and parameters schema.
  • Check loop limits. Verify that the agent cannot chain more than a defined number of consecutive side-effecting tool calls without a control-loop checkpoint. Check: in a sandbox, prompt the agent to repeat a side-effecting call and confirm it pauses for review.
  • Run injection tests. Run the project's prompt-injection test set against the agent (see also the OWASP GenAI Red Teaming Manual). Check: zero unblocked injection payloads that trigger a side-effecting tool call.
  • Record and sign off. Record findings in the review section of the permission file and obtain sign-off from the agent lead. Check: the last_reviewed field is updated and the reviewer is not the author.

Draft snippet: Per-agent tool permission policy

# tool-permissions/support-agent.yaml
agent: support-agent
identity: mi-support-agent-prod
default: deny
tools:
  - name: orders.lookup
    version: "1.x"
    scopes: [orders:read]
    side_effects: none
    approval: never
  - name: orders.refund
    version: "2.x"
    scopes: [payments:refund]
    side_effects: financial
    approval: always
    limits:
      max_amount_minor: 50000
      max_calls_per_thread: 2
  - name: crm.update_contact
    version: "1.x"
    scopes: [crm:write]
    side_effects: record_change
    approval: when_field_changes
    approval_fields: [email, phone]
review:
  owner: agent-lead
  last_reviewed: 2026-10-16

Snippets to add:

  • snippets/tool-permissions/support-agent.yaml: Per-agent tool permission policy (yaml)
  • snippets/checklists/tool-security-review.md: Review checklist (markdown)

6. Known issues and fixes

Symptom Likely cause Fix
Agent can call a write tool it never uses Copied permission file from another agent Default deny and add tools one by one
Injection in a retrieved document triggers a tool call Tool outputs treated as instructions Separate data from instructions and require approval for side effects
MCP server accepts tokens meant for another service Audience not validated Validate the audience claim and reject other tokens
Agent escalates to admin-level actions through sequential tool calls No loop limit or guardrail between chained calls Add a control-loop checkpoint after N calls; require approval for chains with side effects
Agent identity has read-write access when only read is needed Service account created with broad default role Audit the identity's actual scope; reduce to minimum required permissions and re-test
MCP server forwards inbound token to a downstream API (confused deputy) Token passthrough anti-pattern Validate aud claim; never forward inbound tokens downstream (MCP spec)

7. Monitoring and alerts

Signal Alert when Action
Calls to side-effecting tools without an approval record Any Security on-call investigates and disables the tool
403 responses from downstream APIs for an agent identity Spike above baseline Check for scope drift or abuse attempts
Agent tool-call chain length Any single conversation exceeds the chain-length limit set in the agent's permission file (value TO VERIFY with the agent owner) Pause agent, page on-call, review the chain for goal hijack
Token audience mismatch at MCP server Any rejected token (logged as 401 with audience error) Check whether the token source is legitimate or an attack attempt

8. AWS and open-source equivalents

On AWS use IAM least privilege and AgentCore Gateway inbound and outbound auth. OWASP guidance is cloud-neutral.

9. Validation record

Pending. Planned dry-run scenario: A second engineer reviews a sandbox agent seeded with an over-scoped identity, a write tool without approval and an injection-prone tool, and must find all three.

10. Sources