Security overview

Disco Parrot lets agents do real work: clone your code, run commands, open pull requests, reach your tools. That is the point, and it is also the question a security team asks first. How do you let software act on your behalf without handing it the keys to everything, the run of your network, and a free hand in your data?

The answer is not a single feature. It is a small set of design decisions that hold together, each one independent of the others, so that no single mistake takes the whole thing down. This page is that model on one page. Each part below is the short version; every one links to the page that covers it in full. If you read one thing before a security review, read this, then follow the threads that matter to you.

The container is the boundary

Every agent run happens inside a disposable container, and the container is the security boundary. A chat turn, a flow step, a background task, each gets its own container, created for that run and torn down after it. The container is named for the exact work it holds, by an identifier unique enough that no other run can land on it, so two workspaces and two conversations never share one, and the boundary is the container itself rather than a promise the agent makes to behave.

That last point is the load-bearing one. The agent does not police itself; it runs inside walls it cannot see past. It reaches its own working directory and a platform-owned gateway, and nothing else, not the control plane, not another run's container, not your data at rest. How sandboxed execution isolates agents is the full account; the sandbox concept is the everyday version.

The agent never holds the keys

An agent does plenty of work that needs a credential: a token to clone a repository, a key to call a model, the secret a connected tool authenticates with. In Disco Parrot the agent never holds any of them. Your secrets live in a per-workspace vault, set but never readable, and when a run genuinely needs one the platform mints a short-lived, scoped version of it and delivers it through the narrowest channel the task allows. Then it expires.

The rule is enforced by a policy that maps every phase of a run to exactly how a credential may, or may not, reach it, and for your model-provider and integration keys the answer at every agent-facing phase is the same: not as an environment variable, not at all. The agent gets the use of a key for the moment it needs it, never the key itself to keep. The credentials and secret policy page is the model in full; credential leases is the grant itself; secrets is where you set them.

A person approves what matters

Autonomy in Disco Parrot is reviewable: an agent does the labor, and a person approves at the points that matter. The agent can pause its own turn to ask a question or present a plan and wait for an answer. An environment can be set so that changes to its code, its schema, or its infrastructure are proposed rather than applied, parking the risky step until a person signs off. And the way an agent ships code is a pull request under your own identity, reviewed and merged by you, never a write the agent makes on its own.

The shape is the same everywhere: the machine proposes, a person disposes, and the record shows who decided. Reviewable autonomy is the operating model; approved actions is the blast radius; background tasks wait in review before their work lands.

Least privilege, built in

Every action in the platform is a named permission, and every route declares the permission it requires. The protection for you is that there is no quiet corner where access goes unchecked: every route is checked against that rule, and a route that forgot to declare a permission fails the test suite before it can ship. An unguarded path is caught at the gate, not found by an audit a year later in production.

On top of that, permissions carry a danger level, the destructive ones are called out and confirmed, and there is no owner override that reads past a scope. Access is the union of the roles a person holds, and nothing more. Access control is the governance view; roles and permissions is how you assign it.

Everything is recorded

What a workspace does is written down. A tenant-wide audit trail records who changed what and when, with an agent's hand marked distinctly from a person's, and you read it two ways: a friendly activity feed for catching up and a forensic audit log for proving. Every agent run also keeps its full transcript, every message, tool call, and file edit, so the step-by-step is there when the headline is not enough.

Underneath the tenant-facing trail, the platform can stream security events, the permission checks, credential grants, and policy decisions, into an immutable, hash-chained evidence record built to hand to an auditor. The credentials themselves never appear in it. Audit and evidence covers both trails.

Run it in your own network

For organizations that need the work to happen on their own ground, the agent compute can run in your own cluster or Docker engine rather than the platform's. The connection is outbound only: your operator dials out to the platform, there is no inbound port to open and nothing for the platform to call into. Your code and your secrets stay on your side and never cross the channel, which carries only lifecycle commands and the agent's output stream.

This is the option a regulated environment reaches for, and it changes where the compute lives without changing any of the model above. Network boundary and customer-hosted compute is the deep version; sandbox hosts is the deployment choice.

How the pieces hold together

The reason to look at all six at once is that they are layers, not a single gate. The container would contain an agent even if it held a key it should not; it does not hold the key, but the boundary would hold anyway. A person approves the risky change even though the audit trail would have caught it; the trail catches it anyway. Least privilege bounds what a credential could reach even in the moment it is leased; the lease expires anyway.

Each layer is built to stand on its own, so the failure of any one of them is contained by the others. That is the whole design: not a wall with a single door, but a set of independent walls, each enough on its own and stronger together.

What to bring to a security review

If you are evaluating Disco Parrot for a security review, the six parts above are the agenda, and each one resolves to something you can check rather than a claim to take on faith. Four questions carry most of the weight.

Where does the agent run, and what can it reach? The sandboxed execution page answers this with the container boundary, the keyed gateway, and a plain list of what a run can and cannot do from inside. Where do our keys live, and who can read them? The credentials and the secret policy page answers it: a per-workspace vault, values never returned, short-lived leases at the moment of use. What is on the record? Audit and evidence covers the tenant trail and the hash-verified evidence record built to hand to an auditor. What can an agent reach in our data, and what can it never reach? Data access answers it in plain language: the work it was handed through permission-checked tools, with your secret values, another tenant's data, and another run's data all out of reach by construction. Can we keep the compute on our own ground? Network boundary and customer-hosted compute covers the outbound-only channel and running the work in your own cluster. How is our data protected at rest and in transit? Encryption and data handling covers the encryption at rest, the TLS in transit, and the managed-identity access that means there is no standing database key. How do your controls map to what we have to attest? Compliance and trust maps each control to its family and names what is sourced from an agreement rather than the architecture.

Start with the first two. They carry the most weight in a review, and the other four sit more comfortably once the boundary and the secret policy are settled.

Why security works this way

The decision under all of it is that an agent is treated as untrusted code that does useful work, not as a trusted member of staff. A trusted insider model would hand the agent broad access and rely on it to behave, and the day it misbehaved, through a bad instruction, a prompt injection, or a plain mistake, the blast radius would be everything it could touch. Disco Parrot starts from the other end. The agent is contained by a boundary it cannot reach past, handed credentials it cannot keep, and gated by a person at the points that matter, and all of it is recorded. The usefulness comes from what the agent can do inside those walls; the safety comes from the walls.

That stance is what lets the autonomy be real. Because the container, the secret policy, the checkpoints, the least privilege, and the audit trail each hold on their own, you can let an agent do substantial work without betting your security on its good behavior. The agent is free to act because it is not free to escape.

For the person who owns security, this page is the map. Every claim here resolves to a mechanism on a linked page, grounded in how the platform actually behaves rather than a posture statement. Start with the container and the secret policy; they are the two that carry the most weight.

For an engineering leader, the model is what lets you adopt agents without a separate security project for each one. The boundary, the leases, and the checkpoints are platform-wide, so a new agent inherits them rather than re-earning them.

For a team lead, the practical effect is that you can hand real work to an agent and know the limits are real: it works in a container, ships through a pull request you approve, and leaves a trail you can read.

For a prospect evaluating the platform, this is the real shape of the security model, six independent layers rather than one. Every linked page shows you exactly where a boundary is enforced and how, so what you are evaluating is the mechanism itself, not a posture statement about it.