Request, approve and revoke

Workflow

AI can request a one-off operation or refer to a saved task, but it cannot approve its own request. In the local console, review the fixed target, program and arguments, credential slots, output scope and expiry before deciding.

Boundary and checks

Execution uses the approved request snapshot. A change in target, task version or credential state can invalidate an older approval. Revoke unexpected access and inspect run history; revocation cannot undo a remote operation already completed.

From request to result

1. The AI registers the current conversation and reads the non-secret catalog. It can propose an exact one-off command or use a user-saved template.
2. A request freezes the target, program or protocol operation, individual arguments, credential slots, selected output fields, template version and expiry. Ordinary parameters are stored and returned to MCP; never put secrets in them.
3. In the local approval window, check the environment, permissions, full arguments, output scope and lifetime. A rejection can carry feedback; the AI should read it rather than automatically resubmit.
4. After approval, create a run using the approval ID and an idempotency key, then query state and filtered output. Reusing the same key returns the same run. After a disconnect, inspect existing records first.

Authorization scope

The default is human review of each request. “Approve the same task once” reuses an identical approved snapshot for a fixed hour. “Approve this conversation once” can automatically approve different subsequent operations in that conversation for one hour. That high-risk option needs additional confirmation in Web and displays a persistent warning; MCP cannot set either policy. A particular task can also be one-time or repeatable within its approved time window, without changing reviewed parameters.

Optionally, a user can bind a TOTP authenticator and, after reviewing one pending request, voluntarily supply a current single-use six-digit code for the AI to relay. MCP cannot read the seed, generate codes or reuse one for another request. Approving directly in the local page remains available.

Expiry and cancellation

Approvals last 60–3600 seconds. A changed target, template or credential version, expiry, revocation, rejection or consumption of a one-time grant prevents a new run. Revocation attempts to cancel active work but cannot undo a remote action already completed. A timeout does not prove the target did nothing. Inspect run and terminal history and the target before requesting again.