Rules

This page covers the rules that do not depend on what data a run carries. In the policy editor they are under What agents may do (tools, approvals, network, code execution) and the top half of Where data may be processed (which models may be used). Rules about data are on Data protection.

All of these rules are available on every edition.

Tools and connections

What agents may do → Tools & connections sets a decision for each tool an Agent can be bound to, and one for Anything not listed:

A rule can name a whole kind of tool or one tool:

A catalog connector rule (the tool picker's Catalog connectors group) covers every MCP server added from that catalog entry and, for a fixed-URL entry, any server added by hand with the same URL (a per-tenant entry has no URL to match, so its rule covers only servers added from the catalog, until they are detached); a rule on the server itself is more specific.

The most specific rule that names a tool decides; Anything not listed decides the rest (Allowed when it is not set). When several policies apply, the strictest decision any of them gives wins.

A Skill call cannot pause, so Needs approval cannot be set on a Skill rule. If Anything not listed is Needs approval, the editor warns that every Skill binding it reaches is hidden from the Agent.

Where it is enforced:

• When an Agent is saved. A new binding to a denied tool is refused (403 policy_tool_forbidden), naming the policy and rule.
• When a run starts and on every call. A binding that was allowed when it was made and is denied now is removed from the Agent's tools, and any call to it is refused again where it leaves the platform. The Agent's Policy tab shows a banner for each such binding, and Review & activate lists the existing bindings a new version would forbid.

A tool denied only by a monitor policy stays usable and the would-be denial is logged.

Network destinations

What agents may do → Network destinations is the host allowlist (egress.allowed_hosts): host names, *.example.com for subdomains, and IP addresses. An empty list means no allowlist. The lists of every applying policy are intersected.

What it covers, what it does not cover yet, and how to back it up at the network level are on Network egress.

Code execution

What agents may do → Code execution:

The two limits cannot exceed the deployment's own ceilings (CODE_NODE_TIMEOUT_MAX_SECONDS and CODE_NODE_MEMORY_MB, shown as the field placeholders). A higher value is refused at save (policy_above_ceiling). At run time the sandbox gets the lower of the policy's value and the ceiling.

When code is off:

• A Code node is refused when it runs, and the decision is logged.
• A workflow with a Code node the policy blocks still saves, but it cannot be published: "A Code node in this workflow won't run: … Save it as a draft, or replace the node before publishing." The canvas marks the node WON'T RUN. Activating a Package whose workflow has such a node is refused the same way.
• A Skill script is refused when an Agent calls it.

A monitor policy's false lets the code run and logs the would-be refusal.

Models and regions

Where data may be processed → Which model configurations requests may use limits the LLM Configurations a model call may use:

A configuration must satisfy every setting that is set. Across policies each list is intersected. The table under the settings shows every LLM Configuration of the Organization as Permitted or Excluded, with the reason, computed the way enforcement will decide.

A configuration's region is set on the configuration itself (Settings → LLMs, Region field): pre-filled where the provider implies one, otherwise unknown. Unknown satisfies no region rule, so a policy that requires EU or Local excludes the configuration until someone sets its region. The region chips group the stored values: EU is eu or any EU member country, US is us, Local is local, Other is any other country.

The check applies to every model call ai-workers makes (an Agent's model, a Team's lead and members, AI Prompt and Classify nodes, and the query-rewriting and skill calls an Agent makes on the side), to embedding calls when a Knowledge Base is indexed or searched (checked against the Project's policies), and to a voice Agent's direct Gemini model. A refused call is never sent: the run ends as policy_denied, and a Knowledge Base document shows the refusal on its status.

Activation is refused (no_model_permitted) when the draft would permit none of the Organization's configurations, since every model call would then be denied.

To choose models by the data a call carries (for example: financial data only to Local models), see Routing by data category (Enterprise).