Security

Overnite runs code that an AI model decides to run, on your repositories, with your credentials. We design for that: every agent is treated as untrusted, and every secret reaches only the process that needs it.

Isolation: one gVisor sandbox per workspace

• Every workspace is its own Kubernetes Pod, running under gVisor, a user-space kernel that stands between the agent and the host's Linux kernel. A system call from an agent is handled by gVisor, not by the host. Our cluster refuses to start a workspace without it.
• Agents run as root *inside* the sandbox so they can install packages, but the container is never privileged, cannot gain extra privileges through setuid binaries, and has raw network sockets removed.
• A workspace has no Kubernetes credentials and is not told where our internal services are.
• Each workspace has its own disk and CPU, memory and storage limits.

Network: a policy on every workspace

Every workspace Pod runs under a deny-by-default network policy:

• Nothing can connect in. The workspace's runtime dials out to us; no port on a workspace is reachable from the internet or from other workspaces.
• No route to private networks. Traffic to private and internal address ranges is blocked, so a workspace cannot reach our database, our cache, other internal services, or other customers' workspaces.
• Out, only what agents need: DNS, our realtime service, and the public internet - model APIs, Git remotes and package registries.

Encryption

• At rest, AES-256-GCM. Every secret we store - your GitHub token, the API keys you add, the sign-in bundle carried between your workspaces, and connector tokens - is encrypted with AES-256-GCM before it reaches the database. Each value is bound to the row it belongs to, so a ciphertext copied onto another user's row does not decrypt.
• Runtime tokens are hashed. The token a workspace uses to connect to us is created fresh every time the workspace wakes, and we store only an HMAC of it.
• In transit, TLS. The website, the cockpit and our API are served over HTTPS only. Sessions use HttpOnly, Secure, SameSite=Lax cookies.

Secrets live in the environment, not on disk

• A workspace never gets your GitHub token. It gets a token GitHub issues to the Overnite GitHub App for that workspace's one repository - contents, pull requests and issues, nothing else - which expires within an hour and is replaced while the workspace runs. It lives in memory-backed storage and the environment, never on the workspace's disk.
• API keys and connector tokens are handed to one agent at a time, in that agent's own environment, when it starts. An agent only receives the key for its own kind - a key saved for Claude Code never reaches Codex - and only the connectors selected for it.
• Agents start with an allowlisted environment: they do not inherit the runtime's own variables, so nothing meant for the runtime leaks into an agent.
• Secrets are never written to our logs or returned by our API; at most, the last four characters of a key are shown.

One exception to be clear about: when you sign an agent program in *inside* a workspace (for example /login in Claude Code), that program writes its own sign-in files to the workspace's disk, as it would on your laptop. We carry only those sign-in files to your next workspace, encrypted - never conversation history.

Access and approvals

• You sign in with GitHub. There are no Overnite passwords to leak.
• Every API request is scoped to the signed-in user; a workspace, agent or key that is not yours is answered as if it did not exist.
• When an agent asks for approval, the decision is enforced by our servers - a client that fails to show a question cannot answer it for you.

What we are still improving

• Connectors control which credentials a workspace holds, not which internet hosts it can reach.

Reporting a vulnerability

If you believe you have found a security vulnerability in Overnite, please email [security@overnite.dev](mailto:security@overnite.dev).

Please include:

• a description of the issue and where it is;
• steps to reproduce it, or a proof of concept;
• the impact you believe it has;
• how you would like to be credited, if at all.

What you can expect from us:

• an acknowledgement within three working days;
• an assessment, and a timeline for a fix, as soon as we have one;
• word when it is fixed, and credit if you want it.

We will not take legal action against research carried out in good faith that follows these rules:

• only test against your own account and workspaces;
• do not access, change or delete other people's data, and stop as soon as you reach any;
• do not degrade the service for others - no denial-of-service testing, spam or social engineering of our staff or users;
• give us reasonable time to fix the issue before telling anyone else.

We do not currently run a paid bug bounty.