Hand the agent the ticket. Keep the repository.
Agents read, edit, test and open the pull request in a workspace on your host (or, if your organisation turns it on, a member’s own computer: egress there is observed, not enforced). Under the default profile the token stays on the host, and the push says the agent wrote it.
$ npm test -- health
agent · build mode
edit src/api/health.ts
declared check · runs with no network
turn recorded · actor agent
Edits and declared checks run on their own under the assisted profile.
Synthetic requests in organisation acme, workspace dev01. Defaults shown are a fresh install's: egress in observe, the guarded security level, the assisted agent profile, agent push off until enabled, the validation gate off until an admin turns it on.
Why security has not said yes
Today the agent runs on a laptop with a personal token, or in a vendor's cloud with the repository uploaded. Flip the switch to see what changes.
Where each piece lives
The workspace runs on your host. The brokers and the proxy sit between it and GitHub or your model provider, and the record is written alongside. Nothing passes through a Kodela service.
If a platform operator grants it and your organisation turns it on, a member’s own computer can host their workspaces too. git and the AI agents still go through the platform’s brokers, with no token or key stored there, but internet access there is observed, not enforced, and Docker is not available.
Read the architecture- Workspace
- A container per person or agent; non-root; 2 GB, 2 CPUs by default
- Git token
- In the git broker on the host, under the guarded level. Mounted under open or metered.
- Model key
- Anthropic: behind the model proxy; the workspace gets a key worthless off the host. The OpenAI and Antigravity broker is partial and off.
- Outbound
- One proxy; hostname decisions; no TLS inspection
- Record
- Hash-chained audit on disk; the authorship label on every allowed push
Six steps to a defensible yes
The order matters: you watch the traffic before you enforce it.
- Invite the teamAccounts arrive by invitation. The link lasts 7 days.
- Set the profile to assistedEdits and declared checks run alone; anything that leaves the workspace asks.
- Declare the checksListed checks run without a card, with no network, and are audited.
- Observe for a weekEgress logs and allows.
egress-proxy summaryshows what the team really reaches. - Promote to denyOne setting. The allowlist you built is what stays open.
- Turn on the validation gateA push then needs a passing verdict for its exact commit. Not yet seen on a live GitHub push.
What you get, and what to weigh
- Benefits
- Agents on the real repository. A record for every push. Rules you can defend to the security team.
- Security considerations
- Egress starts in observe. Some paths are still open, including
npm publishand some AI APIs; the known gaps list applies. - Deployment model
- One Linux host to start: Ubuntu 24.04, Docker, Python 3.12. See deployment.
- For larger teams
- SSO per organisation over OIDC, a read-only auditor role, and audit export in CEF, LEEF, syslog, JSON or CSV. See what exists today.
- Proof
- No customer story is published yet. Pilots are how that evidence will be gathered.
Questions we get
Which agents work in a workspace?
Claude Code, Codex and Antigravity CLIs are installed in every workspace, and the console has its own chat for Anthropic, OpenAI-compatible and Gemini models. The Gemini CLI, Copilot and Cursor are not in the image.
Where are my GitHub and model credentials?
On your host, in brokers. Under the default guarded security level, the container holds neither. Under open or metered, the git token is mounted, and the per-workspace model-proxy key is readable by that developer.
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 that on, internet access is observed, not enforced.
Is the authorship record cryptographic provenance?
No. It is an HMAC on your host, and it says unattributed rather than guessing. It is verifiable on that host, not by third parties, and not against host root. Publicly verifiable provenance is planned.
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. The credentials sit outside the container regardless.
Why not build this ourselves?
You can. You would need per-workspace credential brokers, one network per team, a fail-closed firewall with a hostname proxy and DNS filter, a hash-chained audit, an authorship record at push time and an evidence report. Kodela is those pieces already wired, on your host.
What it does not do yet
Read this before you hand an agent the ticket.
- Egress starts in observe. Deny by default on fresh installs is built and not released yet.
- The validation gate is off. It is on for no real organisation yet and has not been seen on a live GitHub push.
- Agent push and PR are off in every profile until an organisation turns them on.
- Open paths remain.
npm publishand some directly reachable AI APIs. Only the Anthropic model proxy keeps a model key off the workspace today. - Members’ computers are observed, not fenced. Off by default. If your organisation turns them on, egress and DNS filtering there are not enforced, and the source is readable on that disk. Tested end to end only on Windows.
- GitHub only. No GitLab, Bitbucket or Azure DevOps.
- No spend caps. The cost meter measures; it stops nothing, and it is off with no rates.
Give it a real ticket
Bring up one host and run a week in observe, or ask us to help with a pilot.