Security

Security and data lists the roles, the stored credentials, and how to end access and erase data.

Where your data lives

devboxes runs on servers in Germany. A Project runs its agents on one of your own Runners or on capacity that devboxes manages in Germany. An Organization can limit its Projects to its own Runners.

What an agent can reach

An agent can read everything in its workspace, including its Project's unprotected secrets. A secret bound to hosts reaches a task on a devboxes machine only as a stand-in, which devboxes swaps for the value in HTTPS requests to those hosts. See variables and secrets. A task on a devboxes machine also gets only stand-ins for its model provider's key or sign-in and for its own devboxes token: devboxes swaps in the real values only in the requests that devboxes itself makes from the task to the provider and to devboxes, never in the agent's, and keeps a sign-in's renewed tokens outside the task. On your own Runner, a task gets all of these as their real values.

The agent can take only the actions that its Blueprint allows, and only in its own Project's repository.

Instructions in an issue, a pull request, or a chat message do not give the agent more permissions.

A managed task reaches only the hosts its Organization allows and the hosts its secrets are bound to, by name: TLS on port 443 must name an allowed host, and HTTP on port 80 must name one in its Host header. A task with a database reaches it only through a database machine of its own, which only that task reaches and which reaches only its databases' hosts and ports. Through its URL the task can still set the login's password, so it can come to hold a working login. Every other name gets no DNS answer, and the agent's web fetch reads only allowed hosts. This narrows where the agent can send data, but it doesn't make the data stay put. Several default hosts, such as GitHub and npm, accept uploads from anyone. A service that serves many sites under an allowed name can pass a request on to another site, because TLS hides the request from devboxes. The same holds for encrypted ClientHello (ECH): a client can put an allowed name in the outer name devboxes checks and another site in the encrypted inner name. Web search, Integrations, and Git run on devboxes for the task. A task on your own Runner reaches what the Runner's network allows.

The agent's workspace holds your repository, so the repository's own configuration shapes the agent. Configuration that OpenCode reads lists what it reads and what devboxes ignores.

What devboxes in Chat can reach

When someone writes to devboxes in Chat, a separate process on the devboxes server writes the answer. The answer can use two tools, which describe and run devboxes commands, with a token limited to the person, the conversation, and the channel's Chat policy. The operating system keeps the server's own environment, where the server keeps its keys, from that process.

The process runs as the same system user as the server, and so do the answers to other conversations on the same server. These processes close their memory and environment to one another before they receive their token and conversation, keep the conversation out of their files, and load no settings or code that the others can change. A process that escaped its tools could still stop the others, read and change their working files, and read every file of that system user. devboxes in Chat uses only the model providers the server already ships, so an answer never runs a provider's code that another process placed on the server.