An enterprise's agentic deployment system requires human approval for every action. After three months, the SRE team reports severe 'approval fatigue' — reviewers are rubber-stamping requests without real review because they receive 200+ approval requests per day, mostly for low-risk routine operations. This is paradoxically creating more risk than a better-designed autonomous system would. Which design approach would MOST effectively reduce approval overhead while maintaining meaningful human oversight for genuinely risky actions?
Select an answer to reveal the explanation.
Short Explanation
Making humans approve 200 trivial things a day to catch 2 risky ones is like checking every pallet of copy paper to find one shipment of contraband. You need a narrow catalog of pre-approved low-risk actions, and anything outside it goes to a human. Keep the gate narrow and meaningful, not wide and rubber-stamped.
Full Explanation
The scenario describes approval theater — a governance process that appears rigorous but provides no actual safety because reviewers cannot exercise genuine judgment at volume. The solution is not to reduce volume by batching or scheduling, but to fundamentally redesign which actions require approval.
The correct design approach implements a risk-proportionate low-risk action catalog. It works as follows:
1. Define the catalog: Based on historical action logs, identify the most common action types and their parameters. For each, define narrow, specific criteria that make them low-risk: - restart_service(target: dev-*, restart_reason: health_check_fail) — low risk, catalog entry - update_configmap(namespace: staging, key: log_level, values: [debug, info, warn, error]) — low risk, catalog entry - Actions against production namespaces — always requires approval, never in catalog
2. Catalog matching at runtime: Before execution, each action is checked against the catalog. Exact match within bounds -> autonomous execution. No match or out-of-bounds parameter -> human approval required.
3. Continuous refinement: Review approval history monthly. Actions that were consistently approved without modification for 6+ months with no subsequent incidents can be promoted to the catalog. Actions with high modification or rejection rates stay in the approval queue.
4. Audit everything: Even catalog-matched autonomous actions are logged with the matching catalog rule that authorized them, providing a complete audit trail.
The approach that reduces the approval team size so fewer reviewers handle more requests increases per-reviewer cognitive load, worsening fatigue without improving quality. The approach that batches all approval requests into a daily digest defers approval for actions that may have already executed or whose window for meaningful intervention has passed — by the time a reviewer sees a daily digest, many actions may be moot. The approach that requires approval only on Fridays and during business hours conflates staffing patterns with risk profiles — a high-risk database truncation on a Tuesday at 2 PM is no less dangerous because it happens during business hours.