Explicit Authorization for Irreversible Changes
Irreversible actions — deletions, prod deploys, payments, public posts — need *explicit per-action* authorization, not standing approval. This topic teaches what 'explicit' actually means (intent stated, scope visible, decision logged) and how to design the authorization moment so it cannot be bypassed by a chatty agent.
Explicit Authorization for Irreversible Changes
The previous topics taught you how to classify risk, gate with humans, and scope permissions. This topic closes the loop on the highest-risk tier: irreversible actions that need explicit, per-action human authorization. Standing approvals do not count. Chat consent does not count. The authorization has to be a real, durable, structured artifact.
What "explicit" means
Three properties, all required:
- Per-action — the approval is for this deploy, this refund, this delete — not a broad permission.
- Scoped to parameters — the approver sees the final values (which branch, which amount, which file path) before approving.
- Logged with identity — the approval is recorded against a named human, with a timestamp and a stable ID a reviewer can pull later.
If any one is missing, you do not have explicit authorization. You have a vibe.
The signed-intent pattern
The strongest implementation of explicit authorization is a short-lived signed token issued at the approval moment and verified by the tool wrapper:
human approves -> auth service issues token(action=deploy, branch=v1.4.0, ttl=5m)
agent calls tool -> tool wrapper verifies token signature, scope, freshness -> executes
The agent never holds standing privilege for the irreversible action; it holds only tokens that humans actively minted. A jailbroken or confused agent cannot deploy because it cannot produce a valid token.
GitHub Copilot's design rhymes with this: the coding agent never merges to main itself. It opens a PR; a human reviews; the human merges. The PR review is the explicit authorization artifact, and the merge is the bound parameter.
Walk the gate
Choose your own outcome
Your agent has just finished a production schema migration plan. It now needs to apply the migration to prod. Walk through the authorization decision.
How does the agent obtain authorization to run the migration?
Exam tip: the keyword explicit is doing real work. Whenever an option offers "standing," "session-wide," "blanket," or "general," it is the wrong answer for an irreversible action.
Where this shows up on the exam
GH-600 will test the difference between standing and per-action approval, and between plan-level and parameter-level scope. The defensible answer always names the artifact (signed token, PR review, change ticket), the identity (who approved), and the parameter binding (what exactly was approved).
Key terms
- Explicit authorization
- A per-action human decision recorded against the specific action, its parameters, and the identity that approved it. 'Yes to everything for the next hour' is not explicit.
- Irreversible action
- An action that cannot be undone without external coordination — sending an email, charging a card, deploying to prod, deleting a backup, force-pushing.
- Confused-deputy problem
- When an agent uses its own elevated permissions to perform an action the requesting user could not perform directly. Explicit authorization breaks this pattern.
- Approval token / signed intent
- A short-lived, action-specific credential issued at the moment of human approval and verified by the tool wrapper before the action runs.
Common pitfalls
- Treating a chat 'yes' as authorization. Chat consent is ambiguous, scope-less, and can be social-engineered by an injected prompt. Authorization needs a structured artifact.
- Granting blanket session approvals ("approve all my agent actions today"). That re-introduces standing privilege and defeats the whole point.
- Authorizing the *plan* but not the *parameters*. A human approved 'delete the staging branch'; the agent then deleted *main* because the plan didn't lock the parameter.