Tool-Call Security for AI Agents: Per-Call Policy

An AI agent's permissions are usually granted once, at the level of the tools it may use, yet the risk sits in each individual call: which tool, which arguments, which target, on whose behalf and with what approval. A model that has been confused, misled or steered by injected text will happily issue a destructive call that its broad permissions technically allow. Tool-call security closes that gap by putting an enforcement point between the model's decision and the execution of the action, and by evaluating every call against policy at that moment. This guide shows how to build that enforcement point: where to place it, what to evaluate, how to bind approvals to exact parameters, how to log decisions, and how to roll it out without stalling the agents your teams depend on. It is written for platform engineers, security architects and identity teams who run agents with real tools in production.

Key takeaways

The model is never the final authority. Authorisation for a tool call is decided by an execution component outside the agent's context, which OWASP describes as separating decision-making from execution and the LLM Top 10 calls complete mediation.
Policy is evaluated per call, not per session. The same tool can be safe with one argument and destructive with another, so the decision input must include the tool name, normalised arguments, target resource, environment and the human or agent principal.
Unknown means deny. Unmapped tools, missing risk classifications and unparseable arguments fail closed, and a changed target or parameter is a new action that needs a new decision.
Approvals are bound, short-lived and single-use. A human approval covers one actor, one tool, one target and one parameter set, expires quickly and is consumed atomically at execution.
Every decision is evidence. Log the call, the policy version, the decision, the approval identifier and the result, with secrets redacted, so a reviewer can reconstruct what the agent tried and why it was allowed.

Why per-call enforcement is different from agent permissions

Conventional access control asks whether a principal may use a resource. For agents, the principal is a reasoning loop whose next action depends on text it has just read, including text from untrusted documents, web pages, tickets and tool results. OWASP's LLM06:2025 Excessive Agency describes three root causes: excessive functionality (tools the task does not need), excessive permissions (identities with more rights than the tool needs) and excessive autonomy (high-impact actions with no independent check). Trimming tool lists and scopes, covered in the AI Agent Authorisation Guide, addresses the first two. Per-call enforcement addresses the third, and it catches the cases where a permitted tool is called with a harmful argument.

The PocketOS Database Deletion 2026 shows the gap clearly. A coding agent working on a staging task found an account-scoped token in an unrelated file and issued a single volume delete call that removed production data and its volume-level backups. The agent had assumed the call was limited to staging and had not checked. Nothing at execution time asked whether a delete against a production volume, from a staging task, without approval, should run. A per-call policy would have evaluated exactly those attributes.

The MCP tools specification places the same expectation on implementers: servers MUST validate all tool inputs, implement proper access controls, rate limit tool invocations and sanitise tool outputs, and clients SHOULD prompt for confirmation on sensitive operations, show tool inputs before calling the server, validate results, apply timeouts and log tool usage. It also states that clients MUST treat tool annotations as untrusted unless they come from trusted servers, which matters because a server that labels a destructive tool as read-only should not be able to talk its way past policy.

Where to put the enforcement point

A policy enforcement point (PEP) intercepts the call; a policy decision point (PDP) evaluates it. The PEP must sit on the only path to execution, otherwise the agent can route around it. Four placements are common, and mature deployments combine two of them.

Placement	What it sees	Strengths	Limits
Agent framework hook (pre-tool callback in the orchestrator)	Tool name, arguments, conversation and task context	Richest context; easy to add approval prompts	Runs in the same process as the agent; bypassed if the agent has a shell or raw network access
Tool gateway or MCP gateway	Every tools/call request to registered servers, client identity, server identity	Central policy across many agents and servers; one log stream	Sees only calls routed through it; needs egress controls to stop direct calls
Inside the tool or MCP server	Validated arguments, downstream resource identifiers, the token presented	Closest to the resource; can check business rules such as environment tags	Policy is spread across many servers and teams
Downstream API and identity layer	The credential and the API operation	Cannot be bypassed by the agent; enforced even if upstream layers fail	Coarse; no knowledge of the agent's task or the human who asked

Decision guidance: small teams running one framework can start with the framework hook plus least-privilege credentials at the downstream API. Organisations with many agents, many MCP servers or several frameworks should put a gateway on the path and keep the downstream scopes tight as the backstop. The gateway approach is covered in the MCP Gateway and MCP Server Governance Guide. Whatever the placement, close the bypass routes: an agent that can open arbitrary network connections or run a shell can call an API directly. Pair the PEP with the controls in the Agent Egress Control and Network Isolation Guide and the AI Agent Sandboxing and Code Execution Guide.

Keep the PDP separate from the agent. A policy engine that receives a structured decision request and returns allow, deny or require-approval can be versioned, tested and reused across frameworks. Open Policy Agent, for example, is designed so that services offload decisions by sending a query with structured input and receive a result, with policies that can be updated without redeploying the service. Policy-as-code patterns are covered in the Policy-as-Code for Authorisation Guide.

What the decision must evaluate

A per-call decision is only as good as its input. Build a canonical decision request for every call, normalised before evaluation so that equivalent arguments produce the same decision.

Attribute	Example values	Why it matters
Agent identity	Workload identity of the agent instance, agent registry ID, version	Different agents get different policies; attribution in logs
Delegating principal	The human user or upstream agent the action is on behalf of	Actions run in the user's context, never with more rights than the user has
Tool and operation	Server ID plus tool name, for example `db.query` versus `db.drop_table`	Risk tier lookup; unknown tools fail closed
Normalised arguments	Canonical paths, resolved hostnames, parsed SQL verb, recipient domains, amounts	Stops path traversal, alias tricks and parameter smuggling from changing the decision
Target resource and environment	Resource ID, owner, environment tag (prod, staging), data classification	The PocketOS failure mode: right tool, wrong environment
Task context	Ticket or task ID, declared purpose, data sources read so far in the session	Detects calls unrelated to the task; flags sessions that have ingested untrusted content
Rate and volume	Calls per minute, records affected, cumulative spend	Bulk actions and runaway loops need a different decision than single actions
Approval state	Approval ID, approver, scope hash, expiry	Lets the PDP allow a high-risk call only with a matching, unexpired, unused approval

Validate arguments against the tool's inputSchema before policy evaluation, reject unknown fields, and apply allowlists for paths, hosts, commands and recipients rather than blocklists. The OWASP AI Agent Security Cheat Sheet gives the pattern: limit a file reader to one directory and read operations, block sensitive file types such as .env, .key and .pem, and reject tool names outside an allowlist. Open-ended tools such as "run a shell command" or "fetch any URL" are the hardest to govern per call; OWASP LLM06 recommends replacing them with narrow tools wherever possible, and that is often cheaper than writing policy for an unbounded argument space.

Risk tiers and default decisions

Classify every tool operation before it is exposed to an agent. A simple four-tier model is enough for most organisations, and it gives policy authors a default for each tier that individual rules can tighten.

Tier	Examples	Default decision	Extra conditions
0: Read, low sensitivity	Search public docs, read a non-sensitive ticket	Allow	Rate limit; log
1: Read, sensitive or write, reversible	Read customer records, create a draft, add a comment	Allow within scope	Delegating principal must have the same right; volume caps; data-loss checks on outputs
2: Write with external effect	Send email outside the domain, merge to main, change a configuration, issue a refund under a limit	Require approval or a strict rule	Recipient or target allowlists; amount limits; preview shown to approver
3: Destructive, privileged or irreversible	Delete data or backups, change IAM, rotate or export secrets, payments above limit, production deploys	Require approval with step-up	Two-person rule for the highest impact; environment checks; time-boxed

Tools that have no tier are treated as tier 3 until classified. Do not rely on the server's own description or annotation to set the tier; the MCP specification is explicit that annotations from untrusted servers are untrusted. Assign tiers in your own registry, keyed by server identity and tool name, and alert when a server's tool list changes (the notifications/tools/list_changed message) so new tools are reviewed before they are callable. Spending and transaction limits are covered in depth in the AI Agent Action Approvals and Spending Limits Guide.

Binding approvals to the exact action

Human approval is only a control if it approves what actually runs. The OWASP AI Agent Security Cheat Sheet sets out the properties an approval needs; build them into the approval service rather than the prompt.

Bound scope: the approval record holds the actor, tool name, target and a hash of the normalised parameters, plus a timestamp and expiry. The PEP recomputes the hash at execution and refuses on any mismatch.
Single use: check and consume the approval atomically immediately before execution so it cannot be replayed. A retry with different parameters needs a new approval.
Readable preview: show the approver the resolved action, not the model's summary of it: the real recipient list, the real SQL statement, the environment tag of the target.
Step-up for tier 3: require fresh strong authentication of the approver for payments, privilege changes, bulk deletion and production deployment, and a second approver where impact justifies it. See Dual control and four-eyes approval for privileged and agent actions.
Interrupt and roll back: users need a way to stop a running agent and reverse its last actions; prefer idempotent or soft-delete operations for anything an agent can trigger.

Watch for approval fatigue. If approvers see dozens of requests per hour they will click through, which defeats the control. Tune the tiers so that routine, reversible work flows without prompts and approvals are reserved for the actions that would genuinely hurt. Design patterns for the human side are in the Human-in-the-Loop for AI Agents Guide.

Credentials at the point of execution

Per-call policy and credential design reinforce each other. If the agent holds a broad token, the PEP is the only thing between a bad call and the API. If the tool layer instead obtains a narrowly scoped, short-lived credential for each approved call, the downstream API enforces the same decision a second time.

Act in the user's context: OWASP LLM06 recommends executing extensions in the user's context with the minimum privileges necessary, for example OAuth with minimum scope, so the agent cannot exceed what the person who asked could do. See Confused Deputy in AI Agents Guide.
No token passthrough: the MCP security best practices state that MCP servers MUST NOT accept tokens that were not explicitly issued for the MCP server; forwarding a client token downstream breaks audience checks, attribution and rate limits.
Progressive scopes: start with a minimal scope set and elevate through targeted scope challenges when a privileged operation is first attempted, logging each elevation with a correlation ID.
Keep secrets out of reach: the credential belongs in the tool or broker, never in the prompt or workspace where the agent could find and reuse it. See the Runtime Secrets Injection for AI Agents Without Prompt Exposure guide.

Implementation roadmap

Inventory tools and calls. List every agent, every tool and MCP server it can reach, and the downstream identity each tool uses. Record current call volumes from framework or gateway logs.
Classify operations. Assign a risk tier to each tool operation and record the owner. Mark open-ended tools for replacement with narrow ones.
Insert the PEP in log-only mode. Route calls through the hook or gateway, build the canonical decision request, evaluate policy and log the would-be decision without blocking. Run for two to four weeks across representative workloads.
Review the shadow decisions. Investigate every would-be deny and every tier 2 or 3 call. Fix false positives in policy, and fix true positives in the agent design or credentials.
Enforce in rings. Turn on enforcement for tier 3 first (deny or require approval), on internal agents first, then customer-facing agents, then tier 2. Keep a documented break-glass that disables enforcement for one agent with an alert and an expiry, rather than a global off switch.
Test continuously. Add policy unit tests for each rule and adversarial test cases (injected instructions, parameter tampering, wrong-environment targets) to the agent's CI. See the AI Agent Security Testing Checklist.
Roll back safely. Version policies, deploy them like code, and keep the previous version ready to restore; a bad policy release should be a one-step revert, not an agent outage.

Detection and measurement

For high-risk actions, the OWASP AI Agent Security Cheat Sheet recommends recording the action classification, authorisation outcome, approval identifier, execution result and policy version. Add the agent identity, the delegating principal, the session and task IDs and the normalised parameters, with passwords, keys and tokens redacted before the record is written. Forward decisions to the SIEM and correlate with the downstream API's own logs, which is how you find calls that bypassed the PEP. Reconstruction from these records is covered in Agent Activity Timeline Reconstruction from Tool Calls and Identity Logs.

Alert on: repeated denies from one session (an agent probing or an injection attempt), tier 3 calls outside business hours, calls to tools not seen before for that agent, sudden spikes in call rate, approval requests that are retried with slightly changed parameters, and downstream API activity from an agent credential with no matching PEP decision. Behavioural baselines are covered in the AI Agent Behaviour Baselining and Anomaly Detection Guide.

Metric	Target direction	What it tells you
Share of tool calls mediated by a PEP	100% for production agents	Coverage; any gap is an unmediated path
Tool operations with an assigned risk tier	100% before exposure	Whether fail-closed defaults are being hit by unclassified tools
Downstream calls with no matching PEP decision	Zero	Bypass routes through shells, raw HTTP or leaked credentials
Approval requests per approver per day and median time to decide	Low and stable	Approval fatigue risk; tiers may need tuning
Deny rate by agent and rule	Investigated, not minimised	Policy quality and possible injection activity
Open-ended tools still exposed	Falling to zero	Progress replacing shell and fetch-anything tools with narrow ones

Common failure patterns

Policy in the prompt: instructions such as "never delete production data" are not enforcement. The model can misread them, and injected text can override them. Policy belongs in the PEP and in downstream permissions.
Enforcement that can be routed around: a framework hook guards the tools list, but the agent also has a shell and network access and calls the API directly. Close bypass paths with sandboxing and egress controls.
Trusting server metadata: a tool described as read-only, or annotated as non-destructive, is treated as safe. Assign risk tiers yourself and re-review when a server's tool list changes.
Approvals that approve a summary: the approver sees "clean up old records" while the call deletes a whole table. Show the resolved parameters and bind the approval to their hash.
Environment blindness: the decision request carries the tool name but not the target's environment, so a staging task can act on production. Put environment and ownership tags into the decision input, as the PocketOS Database Deletion 2026 illustrates.
Logs that leak: full tool arguments and results are logged, including tokens and personal data. Redact before writing and treat decision logs as sensitive. See Secure AI Logging.

Framework mapping

Framework	Reference	How tool-call enforcement supports it
OWASP Top 10 for LLM Applications 2025	LLM06:2025 Excessive Agency; LLM01:2025 Prompt Injection	Complete mediation, user approval and narrow tools reduce the impact of manipulated model output
MITRE ATLAS	AML.T0053 AI Agent Tool Invocation; AML.T0086 Exfiltration via AI Agent Tool Invocation; AML.T0051 LLM Prompt Injection	Per-call policy, output checks and egress allowlists detect and block misuse of legitimate tools
NIST SP 800-53 Rev. 5	AC-3 Access Enforcement; AC-6 Least Privilege; AC-6(9) Log Use of Privileged Functions; CM-7 Least Functionality; SI-10 Information Input Validation; AU-12 Audit Record Generation	The PEP enforces access per call, tool minimisation limits functionality, schema validation covers inputs, decision logs provide audit records
NIST CSF 2.0	PR.AA-05; DE.CM-09	Permissions defined in policy and enforced; runtime environments monitored for adverse events
MCP specification	Tools: Security Considerations; Security Best Practices: Token Passthrough, Scope Minimization	Input validation, access control, rate limits, confirmation of sensitive operations, audience-bound tokens

Practitioner checklist

Every production agent's tool calls pass through a PEP that sits on the only path to execution, with sandboxing and egress controls closing bypass routes.
The PDP is separate from the agent, versioned, unit tested and deployable with a one-step rollback.
Each decision request includes agent identity, delegating principal, tool and operation, normalised arguments, target environment, task context and approval state.
Arguments are validated against the tool schema and allowlists before policy evaluation; unknown tools and fields fail closed.
Every tool operation has a risk tier in your own registry; tool list changes trigger review before new tools are callable.
Tier 3 actions require a bound, single-use, short-lived approval with step-up authentication, and a second approver for the highest impact.
Tools act with narrowly scoped, short-lived credentials in the user's context; no token passthrough; no secrets in prompts or workspaces.
Decision logs record classification, outcome, approval ID, result and policy version with secrets redacted, and are correlated with downstream API logs.
Open-ended shell and fetch-anything tools are on a dated plan for replacement with narrow tools.

Tool-Call Security for AI Agents: Enforcing Policy on Every Action