Docs / Agents
Plans and approvals
Review significant cloud infrastructure work, and how plan approval differs from runtime permission prompts.
A plan is a reviewable proposal for cloud infrastructure work. It records what will change, the key decisions, the steps, the risk and the expected cost. Work in a plan waits for approval before it runs.
When to expect a plan
Agents create a plan when they start a new, non-trivial cloud infrastructure task in the app or in Slack, where a review card is available. For example, creating an application's network, cluster and database is a plan. Deleting or replacing a lasting cloud resource, such as a database or bucket, also gets a plan in those channels, even if it is a single command.
Simple changes, and work already covered by a running plan, don't need another plan. Repository edits, pull requests, tickets, diagrams and research are not cloud infrastructure tasks. Other channels and automated turns may have nowhere to show a plan. Don't assume an unattended run will stop at a plan card. State the changes and approvals you want in its prompt, and use provider permissions to enforce the limit.
Plans are an agent workflow, not a provider IAM policy or a gate on every write. Use read-only credentials when writes must be impossible.
What you review
- Overview and decisions: scope, assumptions and choices that still need input.
- Steps, jobs and commands: the work, with its recorded progress and output.
- Risk: possible impact and mitigations.
- Cost: expected one-time or recurring charges and savings.
Read the decisions and the risk first. Check the accounts, the resources and anything exposed to the public. Reject with a reason, or ask the agent to revise the plan, when something is wrong. Review the changes again before you approve the revised plan.
Find every plan for the team on the Plans page.
Lifecycle and access
A plan moves from proposed to approved, executing and completed, or ends as rejected, failed or cancelled. Each approval records who approved it and when. Execution records show what really ran. A failed plan does not mean earlier commands were rolled back.
Administrators and Editors can act on plans. Viewers can't. Approving a plan does not give anyone access to an account they couldn't use before, or widen the connector's provider permissions. See Access control.
Runtime permission prompts
Auto Mode and Full Access govern single actions, such as shell commands and tool calls. The runtime decides when to ask. Auto Mode shows those requests; Full Access approves them automatically. A command prompt and a plan card are separate decisions. Approving one does not approve unrelated work.
An IAM denial is different again: neither a plan nor Full Access can add missing cloud permissions. See Cloud permission errors.