Skip to main content

How much to delegate

Tighten the execution rules, and can you say an agent will not do anything dangerous? You cannot. Some things stop and some do not, and the line between them does not match your intuition.

The execution rules are the setting that decides which operations an agent may perform. This page explains what they stop and how far, and where your own responsibility begins. How to set them up is in the Execution Rules Guide.

You cannot go looser than the tenant-wide execution rules​

Execution rules come in two layers. The execution rules are set for the whole tenant, and a project inherits them.

What a project can choose is the same as the tenant-wide rules, or stricter — never looser. Where both have something set, the stricter one wins.

There are two ways to stop an operation​

One is choosing the basic rules. Each operation built into the product carries a class: read, write, or destructive. That class is decided on the product side, and you cannot change it.

The basic rules, from loosest, are Open, Guarded and Strict. These three are all you choose from. Open lets classified operations through as they are. Guarded stops the ones classified as destructive. Strict lets through reads only.

The other is naming it as a forbidden operation, and this takes effect first. What a project adds can be given in three ways: picking an internal tool by operation kind, giving what it connects to (an external service takes a tool name as well; an agent-to-agent integration takes the connection only), or giving a tool name pattern (Execution Rules Guide). A forbidden operation is evaluated before the basic rules, so it stops the operation even under loose basic rules. The reverse does not work: you cannot let through, from the forbidden operations, what the basic rules stop.

Forbidden operations stack from two places: what was set for the whole tenant, and what the project added. Both apply, and what was set for the whole tenant cannot be removed from the project. What the project added, the project can remove.

Connectors can only be stopped as forbidden operations​

Operations through a connector carry no class. The names of an external service's tools are whatever that service chose, so a name starting with get_ does not mean it only reads. Since there is no way to keep deciding a class from the name, the premise of classifying them was dropped. With an agent-to-agent integration, what the other side does is the other side's decision, so it cannot be classified here either.

With no class, the basic rules cannot judge them. They go through even under the strictest, Strict. To stop one, name it as a forbidden operation.

Take care when you add a connector. There are two kinds of connector — external services and agent-to-agent integrations — and neither goes through the basic rules check.

Forbid one operation and another can still do the same​

This is what to watch for when you write forbidden operations. A block designates operations, not acts. So what stops is only the operations you designated.

Say you forbid the operation that writes to files. The agent can still rewrite the same file using the operation that runs a command. Command execution is a different operation, so the block does not cover it. You meant to stop writing, and writing still happens.

The same goes for the operation that drives a browser — it can write through the web. To stop an act, you have to name every operation that can perform it.

A block is not lifted by human review​

An operation the execution rules forbid is not allowed even when a person advances the step.

Human review and execution rules are two entirely separate mechanisms. Review decides whether this work may go on. Execution rules decide whether that operation may be performed. Even when a person decides to go on, a forbidden operation cannot run.

So do not think "if I make it too strict, I can let it through at review". You cannot.

They only apply inside a project run​

The execution rules you set apply to the steps of a project run, and to a cycle's sweeps. Use the same agent in a conversation outside the project and they do not apply. They do not apply to jobs running outside a project either.

What they watch is each time an agent calls a tool. What the platform itself does — writing a record, for instance — is not in scope. Direct API requests made by scripts inside a shell command or a skill are not judged either, because they are not tool calls. To narrow the traffic itself, use the execution environment's network settings or the permissions on the service you are calling.

Note that a refusal does not stop the run. The refused operation is recorded, and the agent takes the refusal and carries on within what it is allowed. A run ends as "Not allowed by rules" when the platform stopped the run itself.

Where responsibility begins​

What the execution rules judge is only whether an operation is allowed or forbidden.

Whether that operation is right as a piece of work, and whether what comes out is usable, is not something the platform can judge. Keeping the platform itself healthy is on the provider; the work you build on top of it, and the business data handled in the systems you connect, are your responsibility.

So "it is safe because I made the execution rules strict" does not follow. What to delegate is yours to decide, and the execution rules are the mechanism that holds you to that decision.