Approved actions
What an agent is allowed to do, and what it is not. Tool allowlists, credentials it never holds, and environments that only accept proposals.
An agent in Disco Parrot is capable inside its sandbox and bounded at every edge of it. Approved actions is the model that decides what an agent may actually do: which tools it can call, which credentials it can use and for how long, and whether it may change a given target or only propose changes. Together these set the agent's blast radius, and they are how reviewable autonomy stays safe in practice.
The tools an agent may call
An agent can only act through the tools it has been given. External tools arrive through MCP, the open standard for connecting tools to an AI, and each connection you add declares exactly which of its tools are turned on. Anything not on that allowlist is not available to the agent.
The set in each context
In an interactive chat, an agent works through a fixed set of registered tools: it reads and writes files, runs commands inside its own sandbox, and calls whichever external tools an MCP connection exposes. The set is defined for each context rather than open-ended, and the MCP allowlist is the lever that governs everything the agent can reach outside its sandbox. A Flow step can widen or narrow that set to fit the work, and a step that should only call specific tools can run with no shell access at all.
The point is not that the agent is weak. It is that its reach is enumerated. Every tool an agent can call is a tool you can see on the list, and the sandbox is the wall around everything that list can touch. For how that fixed surface is built, the four kinds of tools and the gate every write to your work model passes, see the agent runtime and tool surface.
How MCP connections work
MCP connections come in a few shapes: a local server the platform runs alongside the agent, or a remote endpoint reached over SSE or HTTP. They authenticate without handing the agent a standing secret, through an OAuth sign-in, a reused CLI session, or a scoped token the platform holds. You add a connection from your MCP settings, choose which of its tools to turn on, and test it before any run relies on it. The step-by-step, browsing the catalog, connecting a server, and setting its tool allowlist, lives in MCP tools.
Approval is at the step, not the call
Within the sandbox, the agent's tool calls are not approved one at a time. The bound is the enumerated tool set and the allowlist, not a prompt before every call, which is what lets a run move at the speed of the work. The place a person signs off is the Flow's checkpoints, on the step rather than the keystroke.
Credentials it never holds
The agent never receives your long-lived keys. Model-provider keys, Git tokens, and other managed secrets stay on the server, and every sandbox host blocks them from entering the container at launch. A run cannot read a standing secret, because the secret was never placed where the run could see it.
When a step genuinely needs to act, for example to push a branch or call a provider, one of two things happens. Either the platform performs the action on the agent's behalf, or it hands the sandbox a short-lived credential lease that is scoped to a single operation and expires in minutes rather than living for the whole run. A credential for pushing to Git is granted for about ten minutes; a token handed to an external tool can be as short as a minute. The lease is used once and gone. Because the standing secrets are never in the agent's environment, there is nothing for a run to leak or carry away, and each lease the agent is granted is recorded. The deeper mechanics are the credentials and the secret policy page, with the per-operation grant on credential leases.
Environments that only accept proposals
Some changes should never be applied by an agent without review. An environment carries a change policy that says, for each kind of change, whether an agent may apply it directly or may only propose it.
An environment is attached to a run through its sandbox profile, which is where the change policy reaches the work: choose the profile and you choose the lines the run will hold. A staging profile and a production profile can point at environments with very different policies. The how-to for creating an environment, reading its health, and clearing a blocking event is environments.
Under a propose-only policy, the agent prepares the change as reviewable source, the code and configuration that expresses it, and stops short of the apply-class commands that would push it to the live target. The platform backs that up: when a run produces a change against a propose-only axis, it raises a blocking issue on the environment and the run pauses rather than carrying on as though the change were already live. The change comes back as a proposal that a person reviews and ships through the normal pull-request path, instead of something the agent applies on its own.
The policy has five axes, with safe defaults:
| Kind of change | Default |
|---|---|
| Code | Apply allowed |
| Database schema | Propose only |
| Infrastructure | Propose only |
| Pipeline and environment config | Propose only |
| Secrets and identity | Propose only |
So out of the box an agent can write code freely in its sandbox and open a pull request, while a schema migration or an infrastructure change comes back to a person as a proposal. You set this per environment, so a staging target and a production target can hold different lines.
Everything an agent does is recorded
Approved actions are not only about prevention; they are about evidence. Every tool the agent calls is captured in the run's Sessions transcript, with the tool name, the parameters, the result, and any file edit with the before-and-after. Every short-lived credential the agent is granted, and every attempt a policy blocks, such as a secret that was kept out of the sandbox, is written to the audit trail. Secrets themselves are redacted from both records, so the evidence shows that a credential was granted or an injection was blocked without ever exposing the credential. You can answer, after the fact, exactly what an agent reached for and what it was allowed to touch.
Why it matters
For your team, approved actions make agents predictable. You decide what they can call and what they can change, and the rest is off by default.
For the people who own security and compliance, this is least privilege built into the runtime. An agent's reach is bounded by tool allowlists, a credential policy that keeps keys out of its hands, and propose-only environments that route the riskiest changes back for review, and all of it is auditable. The governance view, which sets these agent bounds alongside the people-side scopes and roles as one least-privilege model you can attest, is approved actions and least privilege.