Approvals

If every deploy needs approval, agents stop being useful and humans start rubber-stamping. If nothing needs approval, the platform is a faster path to shadow IT. So deploys are ungated by default, and approval attaches to blast radius instead.

The five gates

Reason	Trigger
`NEW_PRODUCTION_CAPABILITY`	a capability the previous revision did not have
`RAW_SECRET_ACCESS`	a raw secret the previous revision did not receive
`EGRESS_ALLOWLIST_EXPANDED`	a new outbound host in `network.egress`
`VISIBILITY_WIDENED`	private → organization → public
`DESTRUCTIVE_MIGRATION`	a migration that drops or rewrites data

Everything else — including redeploying an app whose permissions did not change — is fully automatic. That is what makes the platform usable by an agent.

A pause, not a failure

A gated deployment sits in awaiting_approval. The plan stays valid, and approving resumes the same deployment rather than starting a new one.

curl -X POST https://control.example.com/v1/deployments/$DEPLOYMENT_ID/approve \
  -H "Authorization: Bearer $TINY_TOKEN"

Approving at deploy time

pnpm tiny deploy --yes

--yes passes approval intent with the deployment request.

--yes does not bypass role or policy checks. It expresses that the person running the command intends to approve what the plan found — if they lack the role, it is still refused.

In non-interactive use, a plan with required approvals fails with APPROVAL_REQUIRED unless --yes is supplied. That is deliberate: a script should not silently widen production’s blast radius.

Capability grants approve separately

Requesting a capability never approves it, even for an admin, unless organization policy disables the requirement.

pnpm tiny capabilities request stripe.payments.read --connection stripe-production
# then, as an organization admin:
curl -X POST https://control.example.com/v1/capability-grants/$GRANT_ID/approve \
  -H "Authorization: Bearer $TINY_TOKEN"

Previews are exempt

Preview environments skip capability approval. They get sandbox connections and an empty database, so the risk is different in kind. See Previews.

Structured for agents

Approval reasons are structured, so the MCP server returns status: "approval_required" with next_actions an agent can follow — rather than an error it has to interpret from prose.

{
  "status": "approval_required",
  "reasons": [
    { "code": "NEW_PRODUCTION_CAPABILITY", "detail": "stripe.payments.read" }
  ],
  "next_actions": ["tiny_approve_deployment"]
}

The full reasoning is in ADR 0004.

Get started

Build apps

Operate

The five gates

A pause, not a failure

Approving at deploy time

Capability grants approve separately

Previews are exempt

Structured for agents

​The five gates

​A pause, not a failure

​Approving at deploy time

​Capability grants approve separately

​Previews are exempt

​Structured for agents

The five gates

A pause, not a failure

Approving at deploy time

Capability grants approve separately

Previews are exempt

Structured for agents