{"slug": "kilo-cloud-agents-we-took-the-keys-out-of-the-box", "title": "Kilo Cloud Agents: We Took the Keys Out of the Box", "summary": "Kilo has rebuilt credential handling for its Cloud Agents, ensuring that real GitHub and Kilo tokens never enter the sandbox environment. Instead, short-lived, sandbox-specific capability tokens are issued and swapped for real tokens only during authorized outbound requests, preventing credential theft even if the sandbox is compromised. This approach addresses the risk of prompt injection or malicious dependencies in autonomous agents.", "body_md": "# Kilo Cloud Agents: We Took the Keys Out of the Box\n\n### How we rebuilt credential handling to protect your GitHub and Kilo tokens\n\nKilo’s [Cloud Agents](https://app.kilo.ai/cloud) 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.\n\nEvery 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.\n\n## A problem nobody wants to talk about\n\nEvery 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?\n\nMost 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.\n\nWe didn’t think ephemeral containers were enough. So we built something else underneath them.\n\n## What we actually built\n\nYour 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.\n\nWhen 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:\n\n**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.\n\nIf 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.\n\nThe 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.\n\n## Why this matters more as agents get more autonomous\n\nThe 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.\n\nWe 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.\n\n## Try it\n\nThis is live now in Cloud Agents at [kilo.ai/cloud](https://kilo.ai/cloud). It’s the same place you’ve been running them, just with your credentials a lot harder to steal.", "url": "https://wpnews.pro/news/kilo-cloud-agents-we-took-the-keys-out-of-the-box", "canonical_source": "https://blog.kilo.ai/p/keys", "published_at": "2026-07-13 20:01:14+00:00", "updated_at": "2026-07-13 20:10:21.319811+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-infrastructure"], "entities": ["Kilo", "GitHub", "Cloudflare"], "alternates": {"html": "https://wpnews.pro/news/kilo-cloud-agents-we-took-the-keys-out-of-the-box", "markdown": "https://wpnews.pro/news/kilo-cloud-agents-we-took-the-keys-out-of-the-box.md", "text": "https://wpnews.pro/news/kilo-cloud-agents-we-took-the-keys-out-of-the-box.txt", "jsonld": "https://wpnews.pro/news/kilo-cloud-agents-we-took-the-keys-out-of-the-box.jsonld"}}