Where teams start with Kodela.
Four problems we see most. Each page shows the setup we would use, and what it does not cover.
route AI coding agents on real repositories
the problem
The team wants agents on the production codebase, and security has not said yes.
what kodela does
Agents work in a workspace on your host. Credentials sit in brokers, traffic leaves through one proxy, and every push says who wrote it.
its limit
Egress starts in observe, which logs and allows. On a member’s own computer, if turned on, it is only observed. The known gaps list applies.
Five routes, one sheet
Who usually asks, what we would set up first, and the limit you should know before you start.
| Need | Who usually asks | What we set up first | Its limit |
|---|---|---|---|
| AI coding agents on real repositoriesHand the agent the ticket. Keep the repository. | An engineering lead who has tried agents on laptops | The assisted agent profile, declared checks, and a week of egress in observe | Egress starts in observe. The validation gate is off until an admin turns it on. |
| Contractor workspacesContractors on your code, not on their laptop. | A team lead with outside developers | An invitation, one repository grant, file transfer off, the supervised profile | The terminal and screenshots can still copy code: detectable, not preventable. |
| Security teamsSee what leaves. Then decide what stays. | The security engineer who has to say yes or no | A pilot host in observe, then the egress summary after a week | Some exfiltration paths are open, and we list them. |
| Platform engineeringOne host. Many teams. Each with its own rules. | A platform team serving several teams or clients | One organisation per team, each on its own network, under your floor | One platform host, no high availability, no organisation deletion yet. Members’ own computers can host workspaces only if you grant it; egress there is observed, not enforced. |
| For larger organisationsWhat exists today, and what does not. | A CISO, a CTO or a procurement team | The capability table, read row by row, then a pilot | No SAML, SCIM, SLA or managed cloud today. |
What Kodela is not for
Kodela is not a network access product. A VPN decides who reaches your network. Kodela decides what an agent's workspace can reach, and records what it wrote.
So there is no solution page for remote access, site-to-site links, container orchestration or managed service providers. If that is the job, another product will serve you better.
- Customer stories
- None published yet
- How evidence arrives
- Pilots, run on real work
- What we publish
- Only with a pilot team's written permission
- What you can read now
- The known gaps and the changelog
What it does not do yet
Every solution above sits on the same product, with the same limits.
- One host. Additional workers are built and off by default. There is no high availability.
- Members’ computers are observed, not fenced. 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).
- Egress starts in observe. It logs and allows until you set deny.
- No SAML or SCIM. Single sign-on is OIDC per organisation, not yet tested against a customer's live IdP.
- Not certified. The evidence report maps to ISO 27001, SOC 2 and NIST 800-53; the audit is yours.
- No managed cloud. Self-hosting is the only way it runs.
- No customer evidence yet. Pilots are how it will be gathered.
Pick the route, then try it
Run it on one host, or ask for a pilot and bring the job you have in mind.