Why Every Write Action Is Gated

The Cost Asymmetry

Preventing a bad write costs: seconds of human review time, plus the latency of an approval queue. Reversing a bad write costs: customer refunds, inventory reconciliation, chargeback fees, support tickets, and reputation damage.

A single unreviewed bulk price change can create 500+ customer refunds. A single unreviewed inventory sync can oversell stock by 200 units. A single unreviewed customer data export can leak PII. The median cost to reverse these exceeds $5,000 per incident. The cost to gate them: 30 seconds of review time.

This is not risk management theater. This is arithmetic.

Incident Pattern: The Permission Creep

Teams grant write access to systems for legitimate reasons (a contractor needs to upload a CSV, a vendor needs to update their product feed, a new employee needs to process returns). Over time, the scope of that access expands. The contractor's CSV upload tool gains the ability to modify prices. The vendor gains access to customer data. The employee gains the ability to issue refunds without limits.

Without gating, a compromised account or a moment of inattention can execute writes at scale. With gating, the blast radius is capped at whatever a single approval can authorize.

Implementation: Approval Queues vs. Validation Rules

Two gating mechanisms exist. Approval queues require human sign-off. Validation rules block writes that violate predefined conditions.

Approval queues are slower but catch novel errors. Validation rules are instant but only catch known bad states. The best systems use both: validation rules block obvious violations (price set to negative, inventory set to -500), and approval queues catch edge cases (a 15% price increase that's technically valid but unusual).

Decision rule: if the write can be validated by a formula (price > 0, inventory >= 0, email format valid), use validation. If the write requires judgment (is this price increase justified, is this customer refund legitimate), use an approval queue.

When Gating Fails: The Incident Postmortem

Gating failures fall into three categories: the gate was bypassed (a user found an undocumented API endpoint that skipped approval), the gate was too permissive (an approval was granted without proper review), or the gate was too slow (an urgent operational need forced a user to skip the gate).

The fix for bypass: audit all write endpoints, document the approval path for each, and block undocumented paths. The fix for permissiveness: tighten the approval criteria and add a second reviewer for high-impact writes. The fix for slowness: pre-authorize common urgent scenarios (e.g., a manager can approve a refund up to $500 in 30 seconds without escalation).

Want this on your account?

Thirty minutes. Bring the number that keeps you up.