New Your team’s decisions, in one playbook every coding agent works from. Never answer your agent twice

What is a Forbidden Argument?

2 min read Updated

A policy rule that blocks tool calls containing a specific argument or argument value. Forbidden argument constraints prevent agents from using dangerous parameters — for example, forbidding force: true on destructive operations or blocking admin-level privilege escalation flags.

WHY IT MATTERS

Some tool arguments are inherently dangerous. A force: true flag bypasses safety checks. A --no-verify option skips validation. A recursive: true parameter on a delete operation turns a single-file removal into a directory wipe. Forbidden argument constraints let policies block these specific danger signals.

This is more nuanced than simply blocking the entire tool. The tool itself might be perfectly safe — it is a specific argument or argument value that creates risk. By forbidding the dangerous parameter rather than the entire tool, policies maintain agent productivity while eliminating the most hazardous usage patterns.

Forbidden argument constraints are particularly valuable for tools with broad capabilities. A shell execution tool, a database query tool, or a cloud infrastructure tool might accept hundreds of valid parameter combinations. Rather than trying to enumerate every safe combination, operators forbid the known-dangerous ones — a much more maintainable approach.

Forbidden Argument isn't theory — define it as policy in PolicyLayer and it's enforced on every tool call.

ENFORCE THIS WITH POLICY →

Enforced before the call runs. Nothing to install.

HOW POLICYLAYER USES THIS

PolicyLayer expresses forbidden argument rules as deny_if conditions on a tool in the JSON policy document, set in the dashboard's visual policy builder or its Raw JSON view. A condition on an argument's presence blocks calls containing it entirely; a condition on its value denies only matching values — e.g. blocking force: true while allowing force: false. Violations are logged to the audit trail with the specific forbidden argument that triggered the denial.

FREQUENTLY ASKED QUESTIONS

Can I forbid an argument entirely or just specific values?
Both. Write a deny_if condition on the argument's presence to block it regardless of value, or a condition on its value to block only specific values while allowing others.
What if the agent needs the forbidden argument in some cases?
Use policy conditions to make the prohibition conditional — e.g. forbid force: true unless the agent has an elevated role or the operation targets a non-production environment.
How does this interact with required arguments?
An argument cannot be both required and forbidden in the same policy rule — that would deny every call. But different tools or conditions can apply different rules to the same argument name.

FURTHER READING

// THE REGISTRY

Every MCP server your agents touch has a registry record.

Type a name, get the breakdown: verified identity, auth posture, risk grade, every tool classified, recommended policy. Re-checked continuously.

Teams ship this data inside their own products. See what a licence covers →

Take your agents live. Without losing control.

Route your MCP traffic through PolicyLayer. Every tool call is checked against your policy before it runs: allow, deny, or require approval. Per-identity grants. Full audit log. Live in minutes.

Instant setup, no code required.

46,500+ MCP servers and 515,000+ tools scanned and risk-classified.

// GET IN TOUCH

Have a question or want to learn more? Send us a message.

Message sent.

We'll get back to you soon.