See what leaves. Then decide what stays.
One way out of every workspace on your host, every decision logged, every push labelled by author, and the paths we have not closed yet written down.
Synthetic events. Egress runs in observe until 10:05, so a host off the allowlist reads would deny and is let through; after the switch to deny it is stopped. Select an event to open its record. The feed is an exported file: you ship it to your SIEM; nothing forwards it for you.
You were asked to approve agents without visibility
The usual answer is a policy document and hope, and network monitoring that cannot see inside a laptop. Kodela moves the agent onto a host you run, so there is one place to watch and one exit to decide on. Members’ own computers can host workspaces too, but only if a platform operator grants it and the organisation turns it on; there, internet access is observed, not enforced.
It also tells you what it does not cover. Few vendors list their own open exfiltration paths; we publish ours.
- Where are the credentials?
- Trust boundaries
- What can a workspace reach?
- Egress
- What is logged?
- Audit and evidence
- Who wrote the commit?
- The authorship record
- What is not covered?
- Known gaps
Seven things you can check
Each control, what it gives you, and where it stops.
| Control | What you get | Its limit |
|---|---|---|
| One way out, policy per organisation | A fail-closed firewall sends workspace traffic to one proxy. If the proxy is down, outbound traffic is blocked. | Starts in observe, which logs and allows. Hostname decisions only; no TLS inspection. |
| The egress record | Every decision is logged. egress-proxy summary turns a week of it into allowlist evidence. | Some paths stay open: npm publish, some AI APIs. Workspaces on members’ computers are observed only. |
| DNS refusals | Each organisation has a DNS filter. Unlisted names get REFUSED, and the refusal is audited. It fails closed. | It filters names; it does not see the content of allowed traffic. Not enforced on a member’s own computer. |
| Credential custody | The GitHub token lives in the git broker, and the Anthropic key behind the model proxy, on the host. GitHub is reachable only through the broker, in every mode. | Holds under the guarded and strict levels; under open or metered, the token is mounted. The OpenAI and Antigravity broker is partial and off, and some AI APIs are directly reachable. |
| The authorship record | Every allowed push names its tip's author: agent, human-console or unattributed, never guessed as human. | An HMAC with a host-held key: verifiable on that host, not by third parties, not against host root. |
| SIEM formats | A hash-chained audit, exported as CEF, LEEF, syslog, JSON or CSV. | Export, not forwarding. Tamper-evident, not tamper-proof, against host root. |
| Published gaps | The open paths are listed before you ask. | A list is not a fix. Read it before you decide. |
From review to deny
The order we would follow if we were in your seat.
- Review the architectureWhere each credential lives and where it never goes. Trust boundaries.
- Read the known gapsWhat is open today. Known gaps.
- Run a pilot hostOne host, real work, egress in observe.
- Review a week of egressThe summary shows what the team really reaches.
- Set denyThe allowlist you reviewed is what stays open.
Objections we expect
Observe mode is not enforcement.
Correct. Observe produces the evidence for the allowlist. Deny is one setting, and the GitHub, DNS and copy-tool controls enforce in every mode on your host; ssh, rsync and ftp are recognised on any port unless file transfer is set to both. On a member’s own computer, if your organisation turns that on, none of them is enforced.
Is the audit log tamper-proof?
It is tamper-evident: a hash chain that names the line where it breaks. The host's root user could rewrite it, so ship the export off the host if that matters to you.
Can we get the logs into our SIEM?
Export CEF, LEEF, syslog, JSON or CSV and ship the file. There is no built-in forwarding.
Containers are not a security boundary.
Agreed that they are weaker than VMs. Kodela uses a non-root user, no-new-privileges, limits and a network per organisation, and it does not claim VM isolation. There is no cap-drop, seccomp profile, read-only root or user-namespace remap yet.
Where is our data stored?
On your host: code in workspace volumes, the audit trail on disk, the control store in one file. Model calls go from your host to your provider. The product sends Kodela no telemetry. If your organisation turns on members’ computers, the code of those workspaces sits on that computer’s disk, readable by whoever uses it.
Can security read the source?
Yes, during a pilot. The code is not open source.
What it does not do yet
An excerpt of the known gaps. The full list is longer.
- Egress is observe by default. Deny is your decision, one setting away.
- Open exfiltration paths.
npm publishand some directly reachable AI APIs. - Members’ computers are observed, not fenced. Off by default. If turned on, egress and DNS filtering there are not enforced, and the source is readable on that disk.
- Detectable, not preventable. The preview route, and copying what the terminal or an attached editor shows.
- Host root is trusted. The audit chain and the authorship HMAC do not protect against it, and nothing ships off the box.
- No live SIEM forwarding. Export formats only.
- Plain HTTP unless you add TLS. There is no built-in certificate automation.
Review it on your own host
Read the security model and the known gaps, then run a pilot and look at a week of real traffic.