Threat dossier · P2

Automation bias and approval fatigue

Agentic workflows push dozens of approval decisions per hour, and reflexive approval turns the human checkpoint into ceremony that removes no actual risk.

Direct answer

What is automation bias and approval fatigue?

Automation bias is the documented human tendency to approve what an automated system requests; when developers face frequent agent approval prompts, they rubber-stamp the risky request along with the routine ones.

Coverage statements below are limited to the current HOL Guard support contract and do not imply universal model or harness protection.

Copied text includes the canonical source and review date.
Reviewed Reviewer: HOL Guard EngineeringReview cadence: 30 days

Representative attack path

Defensive model only. This sequence omits weaponized payloads and is not attributed to a specific incident unless a source explicitly says so.

  1. Step 1

    An agent requests approvals frequently, most of them routine.

  2. Step 2

    The reviewer learns to approve quickly without full reading.

  3. Step 3

    A malicious or mistaken request rides the same pattern.

  4. Step 4

    The consequential action executes with unexamined approval.

Coverage boundary

What this control can cover

  • Policy can require stronger justification for sensitive action classes instead of relying on human vigilance alone.
  • Decision evidence makes each approval auditable after the fact.

What it does not prove or prevent

  • Forcing a human to read or understand any request.
  • Controlling the approval UI of harnesses outside the supported integration.

Policy pattern

Policy pattern for automation bias and approval fatigue

Keep untrusted context or overbroad autonomy from becoming unconditional execution authority on supported action surfaces.

Use when: Agentic workflows push dozens of approval decisions per hour, and reflexive approval turns the human checkpoint into ceremony that removes no actual risk.

Decision pattern

  1. Identify the trust boundary and consequential action class.
  2. Apply least privilege and the narrowest supported policy.
  3. Require review for sensitive or ambiguous actions.
  4. Preserve only redacted, versioned evidence needed to reproduce the decision.

Limitations

  • Forcing a human to read or understand any request.
  • Controlling the approval UI of harnesses outside the supported integration.

If you suspect prompt injection

  1. Step 1

    Response 1

    Pause and audit recent approvals for pattern-approval behavior.

  2. Step 2

    Response 2

    Re-scope policy so sensitive classes require explicit evidence review.

  3. Step 3

    Response 3

    Reduce approval volume by pre-deciding routine classes.

  4. Step 4

    Response 4

    Retrain reviewers on the updated boundary.

Sources and mappings

Neighboring threat classes that share attack paths or trust boundaries with this dossier.

Last reviewed . This dossier separates sourced threat definitions from modeled attack paths and evidence-bounded product coverage.

Author: HOL Guard Research

Reviewer: HOL Guard Engineering

Change log

  • 2026-09-05: Published canonical threat dossier with attack path, coverage/non-coverage, response procedure, and sources.

Report a correction