Skip to main content
Before a destructive or high-risk cloud change, the agent stops and asks for your approval. The request is a question card with Approve and Reject in the Inbox and in the chat’s Needs your input list. The card lists the steps, cost, risks and rollback. The agent waits until you answer, then continues or stops.

​
When to expect an approval

The agent asks before:
  • Deleting or replacing a cloud resource that is not ephemeral, such as a cluster, database, bucket or DNS zone. This includes something the same conversation created minutes ago.
  • A change with a wide blast radius.
“Delete X and rebuild it as Y” is two approvals, one before each change. Routine, reversible changes do not ask, and neither does work you already approved in the conversation. Repository edits, pull requests, tickets, diagrams and research are not cloud changes. A trigger or an external channel may run with nobody available to answer. State the approvals you want in its prompt and use provider permissions to enforce the access boundary.
Approvals are an agent workflow, not a provider IAM policy or a universal gate on every write. Use read-only credentials when writes must be impossible.

​
What you review

  • Steps: what will change, in order.
  • Cost: expected one-time or recurring charges and savings.
  • Risks: possible impact, including anything publicly exposed.
  • Rollback: how to undo the change, or that it cannot be undone.
Check the accounts and resources named in the card. When it is wrong, reject it or answer with what should change, and review the revised request before approving it.

​
Who approves

The conversation’s owner approves. When a teammate answers instead, the agent treats the answer as information from them, not as the owner’s approval. Approving does not give anyone access to an account they could not otherwise use, or widen the selected connector’s provider permissions. See Access control. Plans created before approvals replaced them remain readable from links in their conversations.

​
Runtime permission prompts

Auto Mode and Full Access govern individual actions such as shell commands and tool calls. The runtime decides when to request permission. Auto Mode shows those requests; Full Access approves the available permission requests automatically. Full Access does not answer an approval card, and approving one change is not a blanket approval of unrelated work. An IAM denial is different again: neither an approval nor Full Access can add missing cloud permissions. See Cloud permission errors.