One way out. Watch it first, then close it.
- 09:14:07acme/dev01
registry.npmjs.orgon the allowlistproxyallowed - 09:14:06acme/dev01
cdn.example.comnot on the allowlistproxylogged · let through - 09:14:05acme/agent
GitHub (direct)GitHub only through the brokerproxyrefused · every mode below file transfer both - 09:14:04acme/agent
git push acme/paymentsthrough the git brokergit brokerallowed - 09:14:03acme/dev01
203.0.113.9:22skips the proxyfirewalldropped, every mode - 09:14:02acme/dev01
unlisted.example.testDNS lookup from the workspaceDNS filterrefused, every mode - 09:14:01acme/dev01
pypi.orgon the allowlistproxyallowed
Observe is the default: the proxy decides, logs and lets the connection through. On your host, GitHub, the DNS filter and the firewall enforce in every mode.
Every workspace on your host sends its outbound traffic through one proxy on that host and a firewall that fails closed, on a network that belongs to one organisation.
Workspaces run on your Kodela host. If a platform operator grants it and your organisation turns it on, a member's own computer can host their workspaces too. There, internet access is observed, not enforced; DNS filtering is not enforced; the source on its disk is readable by whoever uses it; and Docker is not available. Tested end to end only on Windows (Linux laptops up to enrolment; Mac only in a simulation).
Switch the organisation to deny and the unlisted hosts already in the log are struck: the proxy that refused them takes the stamp. The traffic shown is synthetic.
An allowlist written before you have watched the traffic is a guess
Observe mode turns the guess into evidence.
Agents install packages, call APIs and push code. Without a single exit you cannot say what left, and a blind deny-list breaks the team on day one.
A DNS filter refuses names you have not allowed. You start in observe mode, which records every decision, and promote to deny when the record shows what your team needs.
- Find out what your agents actually contact before you write a single rule.
- Close it with the record in hand. The 14-day summary is your allowlist evidence.
- Let people ask for a host instead of working around the rule. A member asks, an admin decides, and both are audited.
- Run in observe for a weekThe default. The proxy logs unlisted hosts and lets them through; GitHub, the DNS filter and copy ports still enforce.
- Read the summary
bin/egress-proxy summary --days 14 - Add the legitimate hostsThe organisation's additions join the platform's allowlist. It can only be added to.
- Switch the organisation to denyOn its Egress card. Strictest wins: an organisation can tighten, never loosen.
- Answer egress requestsA developer who hits a new host gets a sentence and a "request access" path, not a timeout.
The chain, per organisation
iptables rules in DOCKER-USER send each organisation's subnet to its own chain, which logs and drops anything not going to the proxy.
- Workspaceacme/dev01
- acme networkone per organisation
- acme chainto the proxy, or LOG and DROP
- Egress proxyper hostname; no TLS termination
- Internetthe allowed host
DNS filteron the acme gateway; unlisted names get REFUSED
Git brokerthe separate exit to GitHub
registry.npmjs.org · on the allowlist · allowed in both modes
- The proxy decides per hostname. Observe: decide, log, allow. Deny: decide, log, refuse. It does not terminate TLS.
- The firewall fails closed. If the proxy stops, the firewall drops the traffic. The rules survive a reboot; the firewall is a systemd unit.
- Workspace creation refuses unless the firewall has verified the organisation's network and a DNS gateway exists.
- Some controls enforce in every mode on your host: GitHub only through the git broker; the DNS filter; copy tools refused unless file transfer is
both, by port, and on any port when the connection goes through the egress proxy, which recognises ssh, rsync and ftp by their opening bytes. - Docker containers get no internet by default. In a workspace with Docker on, containers reach only the workspace database and each other;
docker_egressset toproxygives them the workspace's own allowlist. egress-coveragenames any organisation network that has no rules.- Every decision is audited in the egress stream, which your SIEM reads through the audit export.
What ships, what it defaults to, where it stops
Each row carries its limit. Deny is built and off until an admin turns it on.
| Capability | Default | Limit |
|---|---|---|
| Egress proxy plus fail-closed firewall, reboot-safe | on | Hostname level; no payload inspection |
| Observe / deny, per organisation, strictest wins | observe | Deny-by-default for new installs is built and held |
| Per-organisation DNS filter | on | All names allowed at file transfer both; fails closed, so an organisation without a running filter has no DNS; not enforced on a member's own computer |
| GitHub only through the broker | on in every mode | Refused in every mode unless file transfer is both, which opens direct GitHub access; use the git broker instead. A connection to a raw IP address is not recognised as GitHub, and neither is codeload.github.com (archives): both fall to the allowlist, so under observe they are only logged |
| Allowlist: the platform's plus the organisation's additions | GitHub, npm, PyPI, Anthropic, Open VSX | Add-only per organisation |
| Egress requests (a member asks, an admin decides) | on | n/a |
| Egress monitor and 14-day summary | on | n/a |
Coverage check (bin/egress-coverage) | on | Read-only; a network it could not check is "not measured", never "covered" |
Internet for Docker containers in a workspace (docker_egress) | off | proxy gives them the workspace's own allowlist; Docker itself is off until your organisation allows it |
| Workspaces on a member's own computer | off | Internet access there is observed, not enforced; DNS filtering is not enforced; only broker calls are seen |
Known open paths
These leave today, in any mode. They are carried on this page so you do not find them later.
npm publishcan upload to the npm registry in any mode.- Some AI provider APIs are reachable directly on the allowlist.
- Code shown in an attached editor or terminal can leave with the person looking at it; file transfer cannot stop that.
- Preview links are detectable, not preventable.
- On a member's own computer, if your organisation turns it on, internet access is observed, not enforced, and DNS filtering is not enforced.
Questions
Is egress blocked by default?
No. It starts in observe, which logs and allows. On your host, GitHub, DNS and copy-tool controls enforce from day one.
Can Docker containers in a workspace reach the internet?
Not by default. They reach only the workspace database and each other. Set docker_egress to proxy and they get the workspace's own allowlist, through the same egress proxy.
Do you inspect traffic?
No. Decisions are by hostname; TLS is not terminated.
What happens if the proxy stops?
The firewall drops the traffic. It fails closed.
Can the agent send my code somewhere?
From a workspace on your host, everything leaves through one proxy you control. It starts in observe mode, which logs and allows, so switch to deny when you have seen the traffic. Some paths are still open, and we list them. On a member's own computer, if your organisation turns it on, egress is observed, not enforced.
What it does not do yet
- Deny by default on a fresh install. A new install starts in observe; deny is off until an admin turns it on.
- Payload inspection or DLP. Decisions are by hostname only.
- Closing
npm publishand direct AI APIs. Both are open paths today. - Coverage on hosts where the firewall's root copy is not installed.
- A hosted version. Egress runs on your host; it is self-hosted only.
- Enforced egress or DNS filtering on a member's own computer. There it is observed, not enforced.
Watch a week, then decide
Start in observe on your own hardware. The record tells you what to allow.