Encryption and data handling

A data owner evaluating any platform asks the same three questions, and they are the ones this page answers: where does our data live, how is it protected at rest and in transit, and who holds the keys. The short version is that your data sits in managed cloud stores that encrypt it at rest, your secrets sit in a vault that is provisioned per workspace, every connection runs over TLS, and the platform reaches its own stores through managed identity rather than a key anyone could copy. This page maps those guarantees onto the question your data team actually asks. It is the at-rest and in-transit companion to data access, which covers what an agent can and cannot reach, and to the data and tenancy model, which covers how that storage is built.

Protected at rest

The data the platform stores for you, your plans and bugs, your initiatives, your audit trail, the records that make up your workspace, lives in managed Azure data stores that encrypt it at rest with the cloud's service-managed keys. You do not configure the encryption and you cannot turn it off; it is the default for the storage the platform runs on, applied to every record without an opt-in to remember. This covers every store the platform uses, the database that holds your records, the table store behind your sessions and audit trail, and the object store for larger files, each encrypted by the cloud's default. The keys behind it are the cloud's own, held and rotated by the platform, so there is no encryption key for you to manage or to lose.

Your secrets are held more tightly still. The model-provider keys, the Git tokens, and the credentials your connected tools authenticate with live in a per-workspace vault, provisioned for your workspace on its own and authenticated through managed identity. A value you put in it is set but never read back, and it is encrypted at rest by the vault that holds it. Where a workspace has no dedicated vault, a secret still rests in an encrypted store rather than in the clear; the per-workspace vault is the stronger isolation, and it is where the keys that matter end up.

Where your data lives

Where that data sits is the platform's managed cloud region. A requirement to pin data to a particular geography, the residency rule a regulated team works to, is a commitment your account team confirms as part of an agreement, which is where a commitment of that kind carries its weight, rather than a setting on a page.

Durability is handled the way you would expect of a managed cloud store. The platform keeps periodic backups of your records, and the restore terms a regulated review wants to see, how far back, how fast, are part of that same agreement, so recoverability is something you can hold in writing rather than infer from the architecture.

In transit over TLS

Every connection that carries your data runs encrypted. The app you use serves over TLS, and the channel between a bring-your-own host and the platform runs over a secure WebSocket rather than anything in the clear. Inside that, the gateway each sandbox talks to is guarded by a per-container bearer the platform mints fresh for that one container and useless anywhere else, so even the in-cluster channel is not an open door. When someone opens a sandbox in their IDE, the SSH session to it rides that same secure WebSocket inside the app's TLS, so the editor channel is encrypted the same as everything else. There is no production path where your data crosses a wire unencrypted.

The platform reaches its data with identity, not keys

The most consequential choice in how data is handled is the one a review should look at first: the platform reaches its own data stores through managed cloud identity, not a shared account key or a connection string. In a deployed environment there is no database key set at all; the platform authenticates as its managed identity, and access is governed by the cloud's own role assignments. A standing database key is the kind of secret that, if it leaked, would open everything at once, so the model is built so there is not one to leak. And because the agent works through permission-checked tools rather than a database connection, no store credential is ever handed to a sandbox in the first place.

Your secrets, in a vault provisioned for you

A workspace's secrets get their own vault, and the lifecycle is built to keep the value out of every hand. The vault is provisioned for your workspace the first time you set a secret, it authenticates through managed identity, and it is configured so a deletion is recoverable rather than an instant, irreversible purge. When a workspace is deleted, its vault is soft-deleted under purge protection rather than wiped on the spot, so a mistaken teardown is not the end of the data and a deliberate one still removes it. The everyday mechanics of setting and referencing a secret are on the secrets page; here the point is that the keys behind your work rest in a store scoped to your workspace, reachable only through the platform's own identity. When a run needs one, the value is resolved on the server, held only briefly in memory to serve the work and spare a fresh vault call each time, never returned to a caller, and cleared the moment you change it.

Keys and rotation

Rotating a key is the same one action as setting it: you write the new value over the old one in the vault, and the next operation resolves the new value. There is no separate rotation flow to learn and no list of copies to chase, because a secret was never copied to a standing place. The platform's own signing material follows the same spirit: the issuer that vouches for a sandbox's cloud identity is built to rotate its signing key while still honoring the previous one, so a rotation does not break a token in flight, and the per-container gateway bearers are minted fresh for each run and die with it, so they rotate by being short-lived rather than by a schedule you maintain. Nothing in the chain is a long-lived key sitting somewhere waiting to be rotated under pressure.

Where the work sits, and when it is gone

While an agent runs, the working copy of your code lives on the sandbox's own disk, and what happens to it after the run is a data-handling question worth answering plainly. On the managed pool and on a Kubernetes host, the workspace is scratch space that exists only for the life of the run, gone when the container is torn down, so nothing carries from one run to the next and nothing lingers on a node. On a Local Docker host you can deliberately keep the workspace on a volume between runs, and that disk is yours. The most sensitive credential a run touches, the model-provider key, is resolved when the run starts and handed only to the runtime process in memory, never written to disk at all. A git token or a connected-tool credential that a command needs as a file is written with owner-only permissions and deleted the moment that command finishes. Either way, a secret is not left readable on disk for the rest of the run. The fuller treatment of what a disposed sandbox holds is on sandboxed execution isolation. And when a workspace itself is closed, deleting it tears down its stored records along with it; the workspaces and tenancy page covers the full teardown.

What a reviewer can verify

Each guarantee on this page is a fact a data owner can confirm rather than a posture to accept:

• Encryption at rest is on by default, applied by the managed cloud stores to every record, with secrets held in a per-workspace vault.
• The platform holds no standing database key, reaching its stores through managed identity, so there is no master credential to leak and none is ever handed to a sandbox.
• Every connection is encrypted in transit, the app over TLS and the sandbox channel over a secure WebSocket with a per-container bearer.
• Your records are scoped to your workspace in storage, and the platform reaches them only as its own identity.
• Working data is ephemeral by default, gone when a run ends, and persisted only where you deliberately keep it.

Standing up a workspace, end to end

When Priya's team adopts Disco Parrot, the data owner's review is short because the answers are structural. The team's records land in managed stores that encrypt them at rest; their first secret provisions a vault scoped to their workspace, reachable only through the platform's managed identity, that gives the value back to no one. Their connections run over TLS, and the agent work happens in containers whose disks are wiped when the run ends. When the data owner asks the question every review asks, "is there a key that opens all of this," the answer is that the platform authenticates as an identity rather than holding one, so there is no such key to ask about. The review is a walk-through, not a negotiation, because each control is something the platform engineer can point at rather than promise.

Why data handling works this way

The expensive way to fail a data review is to rely on a standing secret that is convenient until the day it leaks: a database key in a config, a connection string in an environment, a credential copied to wherever it was handy. So the model is built to not have those. The platform reaches its stores as a managed identity, your secrets sit in a vault that returns them to no one, the credentials a run needs are resolved at the moment of use and deleted after, and the data at rest is encrypted by the stores that hold it without anyone having to enable it. The result is that the data-handling questions a review asks, where the data lives, how it is encrypted, and what would happen if a key leaked, have answers that come from the architecture rather than from a promise that everyone remembered to do the careful thing.

For the person who owns data, this is the answer to "where does our data live and how is it protected." It rests encrypted in managed stores, your secrets in a per-workspace vault, every connection runs over TLS, and the platform reaches its stores as an identity rather than with a key, so there is no master credential to lose.

For a security owner, the detail to check is the absence of standing keys: managed identity to the data stores, a per-container bearer on the sandbox channel that is checked in constant time so a guessed token gains nothing, leased credentials for the work, and a vault that is set but never read back. The encryption at rest is the cloud's default, and the isolation between workspaces is a scoped partition plus an identity boundary, not a master key anyone could lose.

For a platform engineer, what protects the data is that there is no standing credential anywhere in the path: managed identity to the data stores instead of a connection string, TLS to the app and a secure WebSocket to the operator, leased credentials for the work, and a per-workspace vault provisioned on first use. Rotating a secret is one write, and the short-lived tokens rotate themselves.

For a prospect evaluating the platform, the thing to notice is that none of this is a claim you are asked to trust. Each protection is a structural fact you can check: encryption the cloud applies by default, access by identity rather than a key, and secrets in a vault that gives them back to no one. The answer to "where is our data and who can read it" is something you confirm, not something you weigh.