How we rebuilt credential handling to protect your GitHub and Kilo tokens
Kilo’s Cloud Agents let you run Kilo from the web, no local machine required, without losing the context you’ve already built up in your IDE or CLI. What we’re shipping now changes what happens underneath that: how those agents handle your GitHub and Kilo credentials while they run.
Every sandbox provider will tell you their containers are isolated, and they usually are. But isolation only answers “can this thing escape the box.” It doesn’t answer the question that actually matters once you’ve handed an agent a GitHub token and told it to go run arbitrary code: what happens if something inside that box gets its hands on the keys.
A problem nobody wants to talk about #
Every sandbox provider will tell you their containers are isolated. That’s true, and it’s also not the whole story. Isolation answers “can this thing escape the box.” It doesn’t answer the question that actually matters once you’ve handed an agent a GitHub token and told it to go run arbitrary code: what happens if something inside that box gets its hands on the keys?
Most of the time, those keys can do more than the agent actually needs. A GitHub token scoped for “read this repo and open a PR” can often do a lot more than that if it ends up somewhere it shouldn’t. And once a real token is sitting in a container’s environment or filesystem, it’s one bug, one prompt injection, or one bad dependency away from leaving that box.
We didn’t think ephemeral containers were enough. So we built something else underneath them.
What we actually built #
Your real GitHub and Kilo tokens never touch the sandbox. Instead, we mint a short-lived, sandbox-specific capability token and hand that in instead. It looks like a credential to the agent, but it’s not one your tokens could ever be reconstructed from, and it can’t be used anywhere else.
When the sandbox makes an outbound request, we intercept it using a Cloudflare feature built for exactly this, and run three checks before the request goes anywhere:
Did we issue this token? It’s an encrypted blob. We decrypt it and validate the claims and expiry. Anything forged just fails to decode.Is it going somewhere we allow? GitHub tokens can only reach GitHub’s API and github.com. Kilo tokens can only reach the Kilo API. Everything else gets dropped before it leaves the network.Is it coming from the sandbox it was issued to? Each token is bound to one specific container. It doesn’t work from anywhere else, even if it leaks.
If all three checks pass, we swap the capability token for the real one for that single request and forward it upstream. The real token stays in our control plane the entire time. It never sits in the sandbox’s environment variables, never gets written to disk, and never gets logged anywhere the agent could read. The result: even if someone intercepts a token mid-flight, it’s useless outside the one sandbox it was scoped to, and it’s a live credential for exactly as long as that sandbox exists.
Why this matters more as agents get more autonomous #
The sandbox market is getting crowded, and most of it is solving for the same thing: spin up a container, run the agent, tear it down. That’s necessary, but it treats credential handling as an afterthought instead of part of the design.
We started with GitHub and Kilo tokens because those are the two things Cloud Agents touch most. GitLab support is coming next, built on the same architecture, and we expect this pattern to become table stakes for anyone running agents that need real access to real systems.
Try it #
This is live now in Cloud Agents at kilo.ai/cloud. It’s the same place you’ve been running them, just with your credentials a lot harder to steal.