Per-argument conditions. Authorization that stops at the tool name is too coarse. The interesting rules live in the arguments: allow create_refund only up to an amount, allow execute_query only when it is a SELECT, allow send_email only to internal domains.
{"version":"1","default":"deny","tools":{"create_refund":{"deny_if":[{"conditions":[{"path":"args.amount","op":"gt","value":100}],"on_deny":"Refund exceeds the policy limit."}]}}}
Permission ceilings. A ceiling a developer cannot raise from their own client, even with admin access to the agent. The denial holds regardless of who is driving or what they prompt. This is the model security architects keep arriving at independently: limits enforced below the agent, not configured within it.
Scoped to identity
Authorization is most useful tied to the per-person grant tokens from MCP authentication. The same create_refund call can be allowed for a finance lead and denied for a contractor's agent, because the gateway resolves the policy against the identity behind the token. One enforcement layer, different answers per person, no change to the agent.
The agent stops being trusted by default and starts being permitted by rule. That is the whole shift.
Related reading
Control what your agents can do through MCP.
Get started now β. The product is live.
Browse the policy library β. Pre-classified tools across thousands of MCP servers.
Read the MCP security reference β. What the boundary looks like.