What is Tool Call Approval?
Tool call approval is the gate applied to an individual tool call before it executes, resolving to one of three outcomes — auto-allow, prompt a human, or deny — based on human judgement, policy rules, or both.
WHY IT MATTERS
Every MCP client implements some version of this. Claude Code asks before running shell commands and offers "always allow" per tool; Cursor and other clients surface similar per-call prompts. The client shows the tool name and arguments, and the human approves or rejects. This is the human-in-the-loop control the MCP ecosystem leans on by default.
The problem is fatigue. An agent session can issue dozens of tool calls; humans asked to approve each one quickly stop reading the arguments and start clicking through. Worse, "always allow" decisions accumulate silently, so the effective policy becomes whatever a developer approved once, months ago, with no review. Approval prompts also only fire at the call boundary — they do nothing about attacks that work earlier, such as line jumping.
Deterministic policy resolves most of this. Instead of asking a human per call, a policy engine evaluates each tool call against written rules: read-only tools auto-allow, destructive tools deny or escalate, everything logged. Humans are reserved for the genuinely ambiguous cases, where their attention is still meaningful. The result is consistent — the same call gets the same answer regardless of who is running the agent or how tired they are.
HOW POLICYLAYER USES THIS
PolicyLayer moves the approval decision from the client to the gateway. Every tools/call routed through PolicyLayer is evaluated against the team's policy before it reaches the upstream server — allow, deny, or log — so the decision is deterministic, centrally defined, and identical across Claude Code, Cursor, Codex, and any other connected client. Client-side prompts remain available for cases policy escalates, but the bulk of calls are resolved by rule rather than by a human clicking through.