Skip to main content
Policies are CEL expressions that the gateway evaluates on every tool call. Write them in the console’s policy editor.

​
Create a policy

1

Navigate to Policies

Open your project and click Policies in the sidebar.
2

Click Create Policy

Click the Create Policy button.
3

Set the name

Give the policy a descriptive name — e.g., allow-support-reads, block-admin-tools, scope-to-customer.
4

Choose the effect

EffectBehavior
AllowIf expression is false, the request is denied
DenyIf expression is true, the request is denied
Deny rules are evaluated first and take priority.
5

Write the CEL expression

Write the CEL expression directly in the editor. The expression is evaluated on every tool call against the request context:
// Example: only allow support tools for support team
identity.labels.team == "support"
  && request.tool.name in ["get_issue", "add_comment"]
Available variables:
  • identity.name, identity.labels
  • task.name, task.labels, task.context
  • request.tool.name, request.tool.args
See the CEL reference for full syntax.

​
Policy editor

The console includes a code editor with:
  • Syntax highlighting for CEL expressions
  • Access to the variable reference while editing

​
Organizing policies

A project can have multiple policy rules. They’re evaluated in order:
  1. All deny rules first — if any match (true), the request is blocked
  2. All allow rules next — if any don’t match (false), the request is blocked
  3. If all rules pass, the request is allowed
Recommended pattern: 
1. [Deny]  block-dangerous-ops     → block destructive tools for everyone
2. [Deny]  block-production-access  → block production for non-prod agents
3. [Allow] allow-support-tools      → support team can use support tools
4. [Allow] allow-engineering-tools  → engineering team can use dev tools
Policies are drafts until published. Changes to draft policies don’t affect the gateway until you publish a new release.

​
Testing policies

Before publishing, test your policies mentally by checking:
  1. Does an agent with label team: support calling get_issue pass? (Should it?)
  2. Does an agent with label team: engineering calling deploy_service pass? (Should it?)
  3. Does an agent without a task session get blocked? (If your allow rule references task.context, yes — and that might be intentional.)
If a CEL expression references task.context but the request has no active task session, the expression will error — and errors are treated as deny. Use has() to check for optional fields.

​
Next steps

Publish policies

Publish a release to start enforcing your policies.

CEL reference

Full syntax reference for policy expressions.