Problem it solves

Agents silently escalate their own scope during execution, accessing systems or data the user never authorized. The violation often goes undetected until after the fact.

When to use

Whenever the monitoring layer detects that an agent is attempting to access resources, tools, data, or authority outside its approved scope definition.

When not to use

For actions explicitly included in the original scope. This pattern is for detected violations, not routine boundary-checking.

Governing principle

Scope violations are not recoverable without a human consent event. The agent cannot self-authorize scope expansion. Execution must pause.

Required Components

Interaction Flow

1

Monitoring layer detects scope escalation

The agent attempts to access a resource or take an action outside its authorized scope.

2

Execution halted

The agent is paused immediately. The action is not attempted.

3

Attention trigger surfaces

An Agent Attention Trigger notifies the user of the scope violation, naming the specific resource or action attempted.

4

Scope gate activates

A Consent & Scope Gate presents the escalation: what was attempted, what the original scope was, and what the user must decide.

5

User approves expanded scope or declines

Approving extends scope for this run only. Declining terminates the run at this step.

6

Decision logged

The scope violation, the gate shown, and the user's decision are all written to the audit trail.

Governance requirements

Scope violation events are security events and must be logged regardless of the user's decision. Scope expansion approvals are scoped to the specific action and must not be interpreted as general scope expansion.

Accessibility notes

Scope escalation alerts must use role="alert". The gate component must be keyboard-accessible and must not be dismissible without a deliberate user decision.