Resources · Guide

Write your first policy.

A policy is a list of rules. Each call your agent makes gets one answer from it — allow, deny, or require a human's approval — matched on the agent, the tool, and even the argument values.

Three ideas

Everything a policy does, in three moves.

Match

What the rule applies to.

Pick what a rule applies to: the agent, the server or tool, and — where it matters — the actual argument values, like an amount over a threshold.

Decide

What happens when it matches.

Choose the outcome: allow the call, deny it outright, or require a human's approval before it runs.

Order

Rules run top to bottom.

Your rules run in order, and the first match wins. Put your most specific rules first, and end with a catch-all.

A list of policy rules in priority order — Rules read top to bottom — the first one that matches decides the call.

Editing a policy rule with an argument condition — A rule can match the call's own arguments — not just which tool was used.

In plain terms

A policy reads like a short, ordered list. Here's a two-rule example: hold back large refunds for a human, and let everything else through.

1. refund tool, amount > 100 → require approval
2. everything else → allow

In the dashboard that rule is one dialog — Add policy. Only two fields are required; leave a section empty and it applies to everything.

Field	What it does
Name	For humans — "Allow GitHub reads" beats an id when you're scanning the list later.
Action	Allow, Deny or Approve — the verdict when this rule matches.
Capture	How much of the call to keep: Meta (who/what/when), Request, Response, or Both. Set per rule, so you keep payloads only where you actually need them.
Agent tags	Limit the rule to agents carrying these tags. Empty means every agent.
Reason code	A short machine-readable label that travels with the decision — handy when you're reading the audit trail.
Description	Why the rule exists and who owns it. Future you will be grateful.
Explicit links	Narrow the rule to specific agents, servers, tools, prompts or resource templates. Leave a list empty and it covers all of them — so linking just the server keeps the rule working as you import more of its tools.
Request conditions	Match on the call itself — argument values by path ($.amount, $.user.email, or just amount) with an operator: eq, neq, gt, gte, lt, lte, matches, contains, in, exists.

Order matters. Rules are evaluated by priority, lowest first, and the first match decides the call — so put your specific exceptions above the broad rules, and let the project default catch whatever falls through.

When a rule says "require approval."

The call pauses mid-flight and waits for a person. Deny it, or let it time out, and it never runs — either way the decision is logged against the rule that asked for it.

You get pinged. A notification appears in the top bar with a Review button — no need to sit watching the dashboard.

A pending approval notification in the top bar

You see what's being asked. Review opens a panel with the call itself — which agent, which tool, and the arguments it wants to run with.

The approval panel showing the pending call

You confirm. Allow asks once more — naming the tool and the server it will run against, and warning that the decision is final. Approve and the call runs exactly as the agent asked; deny and it never does.