Execution Rules and Traffic Guide

The project's “Execution rules” screen is the same as in the SaaS edition. In the Marketplace edition, though, what it applies to is narrower than in the SaaS edition. A registered agent is a container the purchaser built, and the platform does not stop the operations inside it one by one.

	Workflow	Cycle
Basic rules (Open / Guarded / Strict)	Before starting, checks whether the agent supports them	No effect
Forbidden operations added by the project	No effect (not passed to the agent)	No effect
Outbound traffic	Restricted with NetworkPolicy (by default it cannot go out) and “Banned URL” in the admin console	Restricted with NetworkPolicy (by default it can go out) and “Banned URL” in the admin console

The SaaS edition's explanation that “writing it as a forbidden operation stops it” (Execution Rules Guide) does not apply to the Marketplace edition. Prevent operations you do not want the agent to perform through how the agent is built, and through the traffic restrictions below.

How the basic rules are checked (workflows)

Before starting a registered agent on a workflow step, the runtime checks the following.

1. It combines the tenant-wide execution rules with the project's execution rules, and takes the stricter as the basic rules for this run
2. It checks whether those basic rules are among the agent's certified “Supported run rules”
3. If they are not, it does not start, and that step ends as “Not allowed by rules”. The case stops with a review request (the record shows “The Agent is not certified for this project's execution rules”; Trigger Guide)

The “Supported run rules” are registered by an administrator in the agent's certification. They are the values for which the agent's developer confirmed by testing that it runs under those basic rules (Settings Guide).

Make the project's basic rules stricter and agents that do not support them stop running. For example, an agent whose “Supported run rules” are only Open and Guarded does not start in a Strict project.

The basic rules applied are kept in the execution's record.

When the agent itself decides “I will not perform this operation”, the agent may also report “Not allowed by rules”. Which operations it treats that way is settled by how the agent is built.

Forbidden operations have no effect on the agent's execution, but they are used in the check before starting. If the project's forbidden operations still include one that points to a connector that no longer exists, the execution rules cannot be read and it cannot start. It checks again after a short while, and if they still cannot be read, it becomes a review request. Remove forbidden operations that point to connectors you no longer use.

Restricting outbound traffic

How far a registered agent can communicate externally is settled by two layers. Both are settings for the whole environment, not for a project.

Layer	Who sets it, and where	What it can restrict
Banned URL	Administrators. “Banned URL” in the admin console	URLs of destinations you want to stop
NetworkPolicy	Whoever builds and operates the environment. The Helm values of agent-executor	Destination IP addresses and ports

Workflow agents

By default, they cannot go out. A workflow agent's Pod can communicate only with DNS, the platform's runtime API and the traffic decision service.

To run an agent that uses external services (GitLab, an LLM API, internal systems and so on), whoever operates the environment writes the destinations and ports to allow in agent-executor's marketplaceDefaults.networkPolicy.workflowEgress.allowedEgress.

Example: allow only port 443 on 203.0.113.10YAML

marketplaceDefaults:
  networkPolicy:
    workflowEgress:
      allowedEgress:
        - to:
            - ipBlock:
                cidr: 203.0.113.10/32
          ports:
            - protocol: TCP
              port: 443

• NetworkPolicy can only be written with IP addresses. To stop a particular URL, register it under “Banned URL” in the admin console
• With mode: open, every destination and port except cloud metadata and the like becomes reachable. This is not recommended
• When destinations increase, add them to this value and update agent-executor. For how to change Helm values, see the Application Update Guide

Place an agent that uses external services while it still cannot go out, and its executions fail with communication errors. Before placing a new agent, check its destinations with the agent's developer.

Cycle agents

A cycle agent's Pod has the same NetworkPolicy as agents used in chat. Except for cloud metadata (169.254.0.0/16) and the like, it can reach every destination. Whoever operates the environment adds the IP address ranges of destinations you want to stop to agent-executor's marketplaceDefaults.networkPolicy.additionalDeniedEgressCIDRs.

Banned URL

The agent's Pod is given HTTP(S) proxy settings that go through the traffic decision service. Traffic that follows these proxy settings cannot reach destinations registered under “Banned URL” in the admin console. How to set it is in the Settings Guide.

“Banned URL” alone does not stop it reliably, though. Traffic that connects directly without using the proxy settings does not go through the decision service. There are also destinations, such as services inside the cluster, that are let through without a decision. Block destinations you want stopped reliably with NetworkPolicy as well (for workflows, do not write them in allowedEgress; for cycles, add them to additionalDeniedEgressCIDRs).

“Connection domain restrictions” in the admin console is a setting that allows or blocks traffic from the widget. It does not restrict the agent's outbound traffic.