Egress Network Policies

An egress network policy controls which network destinations a sandbox can reach. Policies are enforced outside the sandbox, so an agent running inside cannot turn the policy off or work around it. This is a guarantee, not a best-effort setting.

This is the gate, whether a sandbox can reach a host. It pairs with the egress proxy profile, which decides what gets attached to the requests it's allowed to make. The two are orthogonal, and a proxy rule never widens what a policy permits. See how egress injection works for how the two planes fit together.

A policy combines two kinds of rule:

• Allow lists. The destinations a sandbox may reach (allowed_domains, allowed_cidrs).
• Deny lists. Destinations a sandbox is blocked from reaching (denied_domains, denied_cidrs), even if an allow rule would otherwise permit them.

Built-in policies

Two system policies ship with Tektona and need no setup:

• tektona/dev is a curated allow list for software development: package managers, git hosts, container registries, CDNs, common AI APIs, and cloud provider endpoints. This is the default.
• tektona/open allows all outbound traffic (allowed_domains: ["*"]).

A baseline of unsafe destinations is always blocked, regardless of policy: private and reserved IP ranges and mail/IRC ports stay off-limits even under tektona/open.

Allow lists

An allow list is the set of hosts a sandbox may reach. A domain entry can be exact (github.com) or a wildcard suffix (*.npmjs.org, which matches any subdomain but not the apex). An empty allow list means "allow all", so only the deny rules and the always-on baseline constrain egress.

Deny lists

Deny rules always win over allow rules. Use them to carve specific destinations out of a broad policy without rebuilding an allow list from scratch, even under tektona/open, or when the same host is also allowed.

Denied domains

denied_domains blocks hosts by name, with the same *.suffix wildcard support as allow entries. A denied domain is blocked even when:

• the policy is tektona/open (allowed_domains: ["*"]), or
• the same host also appears in allowed_domains.

For example, extend tektona/dev but deny a package mirror you don't trust, or run an otherwise-open sandbox with a handful of blocked trackers.

Denied CIDRs

denied_cidrs blocks destinations by IP address. A sandbox cannot reach any destination whose IP falls inside a denied range, even if the domain it used is allowed. This covers the case where an allowed domain resolves into a range you want to keep off-limits, for example a cloud metadata endpoint at 169.254.169.254.

allowed_domains: ["*"]              # open egress…
denied_domains:  ["*.tracker.net"]  # …minus a few hosts
denied_cidrs:    ["169.254.0.0/16"] # …and the metadata range

Custom policies

You can define your own egress network policies at the organization or project scope, and optionally extends a system policy to inherit its allow and deny lists and add your own (the lists are merged). Set an org's default policy and the set of policies its sandboxes may use from the org's sandbox settings. A project can override the default for its own sandboxes.

Manage policies from the Egress Network Policies page in the Tektona console, with the tektona egress-network-policy commands, or via the egress-network-policy endpoints in the API reference for automation. tektona egress-network-policy info <name> prints a policy's allow and deny lists.

Referencing a policy

When you attach a policy at sandbox create with --egress-network-policy, the prefix is a scope keyword — not an org or project name:

A bare name always means the project scope; use org/<name> to reach an org-scoped policy. There is no automatic org fallback.