What happens without asking

Your connected tool acts on Turn Zero Cloud under your account's credential. Each management action has a tier, and the tier sets whether the action completes in the call or waits for a person's approval. This page lists which actions complete on your request alone, which a person approves in a browser first, and which values never reach the tool. Management action tiers and approvals explains the tiers.

What completes on your request alone

Two of the three tiers complete in the call, with no browser step. The connected tool performs them whenever the task you gave it calls for them.

  • Reads. The observe tier reads state without changing it: read_status, read_logs, read_counters, list_applications, list_versions, list_secrets, read_usage, read_account, and the other read_ and list_ actions. Over plain HTTP at https://turnzero.ai/api/v1/actions/, reading the published contracts and the library needs no sign-in; a connected tool signs in at its first request.
  • Deploys. deploy places a built artifact in the environment a deploy goes to and returns deploying. On a new application that is production, so a deploy changes what your users see. Once you turn development on, a deploy goes to development instead.
  • Promotes and rollbacks. With development turned on, production changes through promote. Whether the application has one environment or two, roll_back puts an earlier production version back. Both change what your users see, with no browser step.
  • Turning development on. create_environment adds the development environment, and from then on a deploy goes there.
  • Manifest submissions. submit_manifest records the manifest and provisions the services it declares. The first database declaration creates the development database. The first accounts declaration creates an end-user realm for each environment the application has.
  • Secret stores and rotations. store_secret stores a value by name, and rotate_secret replaces it. revoke_realm_keys revokes a realm's signing keys, and every user of that realm then signs in again.
  • The other reversible actions. These include create_application, set_plan, halt_environment and resume_environment, configure_realm, declare_storage_area and undeclare_storage_area, declare_upstream and undeclare_upstream, mint_token and revoke_token, and run_schedule. They also include the invitation and end-user actions other than deletion.

Reversible means the action runs without an approval step. It does not mean a second call undoes the first. Each action has its own retry behaviour, and a deploy to production, a promote, or a key rotation changes what your users see at once.

Two limits apply inside this tier:

  • Halting production needs your signed-in session or a token minted for the whole account. A token bounded to one application is refused 403 account_credential_required.
  • A minted token acts only within the scope and the grants it received when it was minted.

The platform also acts on its own in four cases. It halts a development environment that has been idle for the halt interval. It re-creates an environment's running copy after it changes the router mark. Once a day it deletes older versions' images, keeping each environment's serving version and its twenty most recent deployed versions. Each of these three shows in the environment's state or in the version history. Applications and environments describes the first two, and Deploy an application the third.

Once a day it also deletes the record of a token revoked or expired more than thirty days earlier. After that, list_tokens no longer lists the token, and a revoke_token call for it returns not_found. Mint a token describes the listing. None of the four actions changes your data, a credential still in use, or a declaration.

What asks first

The destructive tier completes only after a person approves it in a browser. Calling one of these actions creates a pending action and returns the platform's description of the change with an approval link. The tool prints the link and reads the outcome with read_pending_action.

No tool, token, resource, or prompt can approve. The approving browser session must belong to the requesting account. If the description changed between the request and the approval, the record ends declined.

The destructive actions available today:

  • delete_application removes every environment of the application and everything that belongs to them.
  • delete_environment removes the development environment alone, and the next deploy goes to production.
  • delete_account deletes every application of the account the same way, then ends the account's services.
  • delete_end_user removes one end user's identities, sessions, passkeys, and user record.
  • delete_secret removes one stored secret's entry; the secret store keeps the deleted value for ninety days before it purges it.
  • clear_development_database drops the development database and creates it again empty under the same role; the credential stays valid.
  • purge_logs erases an application's log entries and counter totals before their retention period ends.
  • rename_application permanently retires both of the application's hostnames.

A minted token needs the destructive grant to request one of these, and even with the grant it cannot approve.

Some skills also ask you before a reversible action, where the choice is yours:

  • The deploy and move-existing-app skills ask which plan the application starts on before they call create_application.
  • The update-library skill asks before it updates each library entry.

What the tool never sees

An application's development database credential and development platform credential reach your machine only over the HTTP API, never through the Model Context Protocol (MCP) tool:

  • Through the MCP tool, the first submit_manifest withholds both values and returns credentials: "withheld".
  • Through the MCP tool, rotate_secret on either of those two names is refused local_route_required.
  • Instead, for a run on your machine, the tool calls submit_manifest with local_run: true and runs the provision line the response returns. The line re-mints both values over the HTTP API under a grant and writes them into the environment file without printing them.

The platform never returns a production credential to anyone.

No management action reads a stored secret back. list_secrets returns names, scopes, and timestamps, and list_tokens returns token records without values. The store_secret and rotate_secret tools take no value, so a value cannot pass through a tool call. A call returns a command line, which Store a secret describes. The line sends the value from your machine over the HTTP API, keeping it out of the conversation. A store_secret call naming generate creates the value in custody and returns no line.

Two secret values do reach the tool, each returned once:

  • A minted token, from mint_token. Keep it where the tool keeps environment values, and revoke it if it reaches a chat, a log, or a commit.
  • An invitation URL, single-use, from issue_invitation. list_invitations never returns it again. The platform does not email an application's invitations, so send the URL to the person yourself.