Skip to main content
Policy changes don’t take effect immediately. You publish a release — a versioned snapshot of your policies. The latest release is automatically enforced by the gateway.

The publish workflow

Draft policies          Publish release
(edit freely)     →     (snapshot becomes active)
  1. Edit your policies in the console (these are drafts)
  2. Publish a release from the Releases tab — this snapshots your current policies and makes it the active release

Create a release

1

Review your policies

Go to Policies and review all your policy rules. Make sure the expressions, effects (allow/deny), and ordering are correct.
2

Go to Releases

Switch to the Releases tab in the Policies section.
3

Click Publish Release

Click Publish Release. This creates a versioned snapshot of all current policies and makes it the active release.The gateway picks up the new release within about a minute.

Version management

Every release gets a version number. You can:
  • View any past release to see what policies were active at that time
  • Rollback to a previous release if something goes wrong
  • Compare releases to see what changed
Publish a new release before making significant policy changes. This gives you a known-good state to roll back to.

How the gateway uses releases

When you publish a new release, it becomes the active release. The gateway picks up changes within about a minute. There’s no downtime — in-flight requests complete with the old policies, and new requests use the updated ones.

No release published

If no release has been published for a project, the gateway uses the project’s default policy action:
  • Deny (recommended) — all tool calls are blocked
  • Allow — all tool calls are permitted
Running without a release in deny-default mode blocks all agent tool calls. Make sure to publish a release before agents start connecting.

Next steps

View executions

Check the audit log to verify policies are working as expected.

Policy examples

Real-world policy patterns to reference.