Informed Approval

The Principle

A human decides with full visibility. A machine executes precisely. Each access change passes through two phases. First, a human with authority reviews the concrete effects of the change. Then automation applies it as approved across all affected systems. The human does not execute. The machine does not decide.

What Approval Actually Means

In the traditional model, approval is a checkbox on a ticket. The approver: usually a manager: sees a sentence of natural language: “Please grant staging access for the analytics platform.” What does that mean? Which specific permissions? Which resources? Read-only or read-write? The approver does not know. They trust that the admin interpreting the ticket will get it right.

In the declarative model, the approver sees the change in detail: the specific roles being assigned, the systems affected, the permissions being granted or revoked. The approval is informed, precise, and meaningful. A manager reviewing a proposed change can see that it grants access to production systems and ask whether that is intentional: before anything happens.

Approval Fatigue

This only works if the diff is legible, not just available. Approval fatigue is real: anyone who has rubber-stamped a pull request without reading it understands the risk. The tooling must treat the approval experience as a first-class concern: summaries for routine changes, highlighted deltas for sensitive ones, plain-language explanations of what “production write access” actually means in this context. An approval that the approver didn't read is not meaningfully different from no approval at all.

Blast Radius Visibility

Before any access change is applied, the system produces a complete preview of what will change: which users are affected, which systems will be modified, which permissions will be granted or revoked. No change is applied without this preview being generated, reviewed, and accepted.

A change to a role definition might affect dozens of users across multiple systems. Without blast radius visibility, the reviewer sees only the role change. With it, they see each user who will gain or lose permissions and in which systems. This transforms access review from “does this look right in the abstract?” to “do I accept these specific consequences?”

Access changes with unexpected scope carry the highest risk. A well-intentioned modification to a shared role can cascade through the organization in ways that the author did not anticipate. Blast radius visibility makes these cascades visible before they happen, turning surprises into informed decisions. This applies equally to routine changes and emergency ones: especially emergency ones.

Dry-Run Validation

Blast radius visibility shows what the diff says will change. Dry-run validation answers a different question: what would actually happen if we applied this? Before any change is promoted to production, the system attempts it against each downstream system in a read-only or sandboxed mode. It verifies that the target systems are reachable. It checks that the permissions exist and that the mappings are current. It confirms that no API constraints will cause a partial failure.

This is the access equivalent of terraform plan versus terraform apply. A diff that looks correct but fails on three of thirty downstream systems during execution leaves the organization in an inconsistent state. Dry-run catches this before the first real API call is made.

Separation of Approval and Execution

The traditional model conflates approval and execution. The admin who reads the ticket also performs the action. This means a single person can approve and execute an access change, and the only record is that it happened, not that it was authorized.

Separating these concerns is structural. The approver authorizes a specific change. The automation executes that change and nothing else. The approver cannot accidentally grant extra permissions by mis-clicking. The automation cannot act on changes that were not approved. Each side constrains the other.

Antipatterns

• Approvers see a natural-language summary, not the concrete permissions.
• A single person can both approve and execute an access change.
• Changes are applied without previewing who and what they affect.
• No way to verify a proposed change will succeed before executing it.