Escalation Authority Governance

2. Summary

Escalation Authority Governance requires that organisations pre-define who can escalate, pause, override, or terminate AI agent operations under different risk conditions, and that these authorities are documented, communicated, tested, and structurally enforced. This dimension addresses the critical governance question: when something goes wrong with an AI agent, who has the authority to act, what actions can they take, and under what conditions? Without pre-defined escalation authority, incident response degenerates into improvisation — individuals make ad-hoc decisions about whether to intervene, waste critical time seeking authorisation, or act without authority and face personal accountability consequences. AG-261 ensures that the right people have the right authority to take the right actions under defined conditions, before those conditions occur.

3. Example

Scenario A — Authority Vacuum During a Live Incident: A crypto exchange deploys an AI market-making agent. At 02:17 on a Saturday, the agent begins executing trades at prices 15% away from the market mid-point due to a liquidity model miscalibration. The on-call engineer recognises the problem but does not have authority to pause trading — that authority sits with the Head of Trading, who is unreachable. The engineer escalates to the CTO, who is unsure whether they have authority over trading operations. By the time the Head of Trading responds at 03:45, the agent has accumulated £2.8 million in losses. The 88-minute delay between identification and action occurred because no pre-defined escalation authority existed.

What went wrong: No documented escalation authority defined who could pause the agent under different conditions. The on-call engineer could detect the problem but not act on it. The CTO was uncertain about cross-functional authority. The Head of Trading was the single point of authority with no delegate. Consequence: £2.8 million in trading losses, regulatory investigation by the FCA into adequacy of systems and controls, reputational damage in the crypto market, personal accountability review for the Head of Trading under SM&CR.

Scenario B — Over-Escalation Causing Operational Paralysis: A government agency deploys an AI case-processing agent for benefits applications. The escalation policy states that "any anomaly must be escalated to the Director before action is taken." When the agent encounters a batch of 340 applications with minor formatting inconsistencies, the operator escalates to the Director. The Director is in meetings until the next day. The 340 applications are paused for 26 hours. The applicants — many of whom depend on timely benefit payments — experience delays. The media reports that "AI is blocking benefit payments."

What went wrong: The escalation authority was defined but not graduated by risk level. Minor operational issues required the same authority level as critical failures. The Director's calendar became a bottleneck for routine decisions. Consequence: 340 applicants experienced unnecessary delays, negative media coverage, ministerial inquiry, loss of public trust in the agency's AI programme.

Scenario C — Well-Defined Escalation Authority in Action: A payment processor's AI fraud-detection agent flags a pattern that matches a potential coordinated attack — 47 transactions from different accounts targeting the same merchant within 3 minutes, each just below the reporting threshold. The pre-defined escalation framework specifies: Level 1 (operator can pause individual transactions), Level 2 (team lead can pause all transactions to the affected merchant — triggered when 10+ flagged transactions involve the same entity within 10 minutes), Level 3 (Head of Operations can pause the entire fraud-detection channel — triggered when the pattern suggests systemic compromise). The operator pauses the 47 transactions under Level 1 authority. When 12 more arrive in the next 2 minutes, the team lead exercises Level 2 authority and pauses all transactions to the merchant. The pattern is analysed, confirmed as coordinated fraud, and the merchant is suspended. Total exposure limited to the 47 initially flagged transactions (£23,500). Without the graduated authority framework, the operator would have continued flagging individual transactions while the attack scaled.

What went right: Escalation authority was pre-defined with clear triggers, graduated levels, and named roles at each level. Each person knew their authority boundary and could act immediately within it.

4. Requirement Statement

Scope: This dimension applies to all AI agent deployments where agents can affect external state, process material transactions, handle personal data, or operate in safety-critical environments. The scope covers all escalation scenarios: operational anomalies, performance degradation, safety threshold breaches, security incidents, regulatory triggers, and ethical concerns. For each scenario category, the organisation must define: the conditions that trigger escalation, the authority levels required for different response actions (pause, override, restrict, terminate), the named roles or individuals holding each authority level, the maximum response time at each level, and the fallback authority when the primary authority is unavailable. The scope extends to cross-organisational escalation: where an agent operates across multiple entities (AG-266), escalation authority must be defined for each entity and for the joint-authority scenario.

4.1. A conforming system MUST define a documented escalation authority framework specifying at least three graduated levels of escalation, each with defined trigger conditions, authorised response actions, named authority holders, and maximum response times.

4.2. A conforming system MUST ensure that at least one escalation level can be exercised by the on-call operator without requiring additional authorisation, enabling immediate containment of detected anomalies.

4.3. A conforming system MUST define fallback authority for each escalation level — if the primary authority holder is unavailable, a named alternate MUST be designated with identical authority.

4.4. A conforming system MUST enforce escalation authority through access controls — individuals SHALL NOT be able to exercise escalation actions above their defined authority level.

4.5. A conforming system MUST log all escalation actions with the identity of the person acting, the authority level exercised, the trigger condition, the action taken, and the timestamp, retaining these logs for the same period as other governance evidence.

4.6. A conforming system MUST test the escalation framework through simulated exercises at least semi-annually, verifying that authority holders can exercise their authority within the defined maximum response times.

4.7. A conforming system SHOULD define separate escalation paths for different risk categories (operational, security, safety, regulatory, ethical) to ensure that escalation reaches persons with appropriate domain expertise.

4.8. A conforming system SHOULD implement automated escalation triggers that initiate the escalation process when predefined thresholds are breached, rather than relying solely on human detection.

4.9. A conforming system MAY implement time-based automatic escalation — if a Level 1 escalation is not resolved within a defined period, it automatically escalates to Level 2, and so on.

5. Rationale

Escalation authority governance exists because the gap between detecting a problem and having authority to act on it is where most AI agent incidents compound. Detection without authority creates helpless awareness — operators watch damage accumulate while seeking permission to intervene. Authority without structure creates chaos — multiple people take conflicting actions, or no one acts because everyone assumes someone else will.

The challenge is particularly acute for AI agents because they operate at machine speed. A human employee making errors gives the organisation minutes to hours to intervene. An AI agent making errors gives the organisation seconds to minutes. If the escalation framework requires 30 minutes to navigate — finding the right person, confirming their authority, explaining the situation — an AI agent operating at 100 transactions per second will have executed 180,000 additional transactions during that delay.

AG-261 addresses this by requiring pre-defined, graduated, tested escalation authority. The graduation is critical: not every anomaly warrants a system shutdown, and not every system shutdown requires board-level approval. A well-designed escalation framework empowers the nearest competent person to take immediate containment action within defined boundaries, while escalating to higher authority for broader actions. This mirrors the incident-command model used in emergency services, aviation, and military operations — organisations that have learned through experience that pre-defined authority structures are essential when response time determines outcome severity.

The testing requirement (4.6) reflects the principle that untested authority is unreliable authority. An escalation framework that has never been exercised will fail under pressure — people will not know their authority, will not have practiced the actions, and will not have experienced the decision-making pressure. Semi-annual exercises ensure that the framework is not merely documented but operational.

6. Implementation Guidance

The escalation authority framework should be designed around two principles: graduated response and pre-authorised action. Graduated response means that the severity of the intervention matches the severity of the situation. Pre-authorised action means that the person at each level already has authority to act — they do not need to seek approval in the moment.

Recommended patterns:

• Three-level escalation framework. Define three levels with clear boundaries:
• Level 1 (Operator): Authority to pause individual agent actions, flag transactions for review, and restrict agent scope to a subset of its normal operations. Trigger: any detected anomaly. Maximum response time: 5 minutes. No additional authorisation required.
• Level 2 (Team Lead / Manager): Authority to pause the entire agent, switch to a fallback system, and restrict agent access to specific systems or data. Trigger: Level 1 action taken and situation not resolved within 30 minutes, or the anomaly affects more than 10 transactions/interactions, or the anomaly involves potential regulatory breach. Maximum response time: 15 minutes. No additional authorisation required.
• Level 3 (Senior Management / Incident Commander): Authority to terminate the agent, invoke disaster recovery procedures, notify regulators, and engage external support. Trigger: Level 2 action taken and situation not resolved within 2 hours, or the anomaly involves potential safety risk, governed exposure above £100,000, or data breach affecting more than 100 data subjects. Maximum response time: 30 minutes. Authority delegated from the board via standing governance resolution.
• Escalation runbooks. For each escalation level, maintain a runbook specifying the exact steps to take, the systems to access, the commands to execute, and the people to notify. Runbooks should be tested during simulation exercises and updated after each exercise based on lessons learned. Runbooks should be accessible to authority holders at all times — not locked behind VPN, not stored in systems that may be affected by the incident.
• Automated escalation triggers. Configure monitoring systems to automatically initiate escalation when predefined thresholds are breached. For example: if the agent's error rate exceeds 5% over a 10-minute window, automatically page the Level 1 operator and create an escalation ticket. If the operator does not acknowledge within 5 minutes, automatically escalate to Level 2. This removes the dependency on human detection and reduces response time.
• Post-escalation review. After every escalation event, conduct a review within 5 business days examining: whether the escalation was triggered appropriately, whether the response was timely, whether the authority framework was adequate, and what changes (if any) are needed to the framework. Document findings and track remediation actions.

Anti-patterns to avoid:

• Single-level escalation. An escalation framework with one level ("escalate to the Director") creates bottlenecks and provides no graduated response. Minor issues require the same authority as critical failures, leading to either over-escalation (paralysis) or under-escalation (the Director is not contacted because the operator does not want to "bother" them with a minor issue that turns out to be major).
• Escalation requiring consensus. An escalation framework that requires multiple people to agree before action is taken introduces delay. In a time-critical situation, consensus-seeking can delay response by the time required for the slowest responder. Each escalation level should empower a single named individual to act — they may consult others, but the decision authority rests with them.
• Untested frameworks. An escalation framework that has never been exercised will fail under pressure. People will not know their authority boundaries, will not have practiced the technical actions, and will not have experienced decision-making under time pressure. The semi-annual testing requirement is a minimum — quarterly testing is recommended for high-risk deployments.
• Authority without tooling. Granting someone the authority to pause an agent is meaningless if they do not have the system access, credentials, and tools to actually pause it. Authority must be accompanied by capability — the authority holder must have tested access to the systems required to exercise their authority.
• Escalation paths that bypass the on-call function. If the escalation framework allows issues to be raised directly to senior management without going through the on-call function (AG-263), the on-call function is unaware of active incidents and cannot coordinate the response. All escalations should route through the on-call function as a coordination point, even if the authority to act resides at a higher level.

Industry Considerations

Financial Services. Escalation authority should align with existing trading-halt and circuit-breaker mechanisms. The FCA expects firms to demonstrate that they can halt AI agent operations within minutes when anomalies are detected. Under SM&CR, the Senior Manager with responsibility for AI operations should be the named Level 3 authority or should have formally delegated that authority to a named deputy. Escalation logs are likely to be requested during FCA supervisory visits.

Healthcare. Clinical escalation for AI agents must integrate with existing clinical escalation frameworks (e.g., NEWS score escalation, clinical emergency response). The Level 1 authority for clinical AI agents should be a clinician with appropriate clinical standing, not a technology operator. Patient safety must be the primary criterion for escalation triggers, ahead of operational or financial considerations.

Critical Infrastructure. Escalation in safety-critical environments must integrate with existing safety systems and emergency procedures. The escalation framework should define clear interfaces with emergency shutdown systems, safety instrumented systems, and emergency services notification. IEC 61511 requires that safety functions are independent of the control system — AI agent escalation must not rely on the agent's own systems for communication.

Maturity Model

Basic Implementation — The organisation has a documented escalation framework with at least three levels, named authority holders at each level, and defined trigger conditions. The framework has been communicated to all relevant personnel. Escalation actions are logged. The framework has been tested at least once. Fallback authorities are defined but may not be regularly verified.

Intermediate Implementation — Escalation authority is enforced through access controls — individuals can only exercise escalation actions at their defined level. Automated triggers initiate escalation for predefined threshold breaches. Escalation exercises are conducted semi-annually with documented findings and remediation tracking. Post-escalation reviews are conducted after every escalation event. Separate escalation paths exist for different risk categories. Fallback authorities are verified quarterly.

Advanced Implementation — All intermediate capabilities plus: automated time-based escalation ensures that unresolved issues escalate automatically. Escalation response times are measured and trended — the organisation can demonstrate that median response times are well within defined maxima. Escalation frameworks have been validated through independent testing, including scenarios where primary authorities are unavailable and fallback authorities must act. The organisation can demonstrate to regulators that at no point is the operation without a reachable, capable, authorised escalation authority.

7. Evidence Requirements

Required artefacts:

• Escalation authority framework document. The documented framework specifying levels, triggers, authorities, response times, and fallback designations. Must be versioned with change history.
• Authority holder register. Named individuals at each escalation level with contact details and verified system access. Must be current within 30 days.
• Escalation exercise records. Documentation of semi-annual (or more frequent) escalation exercises, including scenario description, participants, response times achieved, findings, and remediation actions.
• Escalation event logs. Complete logs of all escalation events, including trigger, identity of person acting, authority level exercised, actions taken, timestamps, and outcome. Minimum 36 months retention.
• Post-escalation review reports. Review documentation for each escalation event, including root cause, response effectiveness assessment, and any framework improvements. Minimum 36 months retention.

Retention requirements:

• Escalation framework and event logs: minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise.

Access requirements:

• Producible to regulators or auditors within 48 hours of request. The escalation framework document must be accessible to all authority holders at all times, including during system outages.

8. Test Specification

Testing AG-261 compliance requires verifying both the documentation completeness and the operational effectiveness of the escalation framework.

Test 8.1: Framework Completeness

• Stimulus: Review the escalation authority framework document. Verify that it defines at least three graduated levels, each with trigger conditions, authorised response actions, named authority holders, maximum response times, and fallback authorities.
• Expected behaviour: The framework is complete at all levels.
• Pass criteria: All required elements are defined for all three or more escalation levels.
• Fail criteria: Any level lacks trigger conditions, authority holders, response time targets, or fallback designations.

Test 8.2: Level 1 Immediate Action Capability

• Stimulus: Simulate an anomaly during a period when only the on-call operator is available. Verify that the operator can exercise Level 1 containment actions (pause, flag, restrict) without seeking additional authorisation.
• Expected behaviour: The operator takes containment action within the Level 1 maximum response time without contacting any other person for permission.
• Pass criteria: Level 1 action is taken within the defined maximum response time (e.g., 5 minutes) without additional authorisation.
• Fail criteria: The operator requires additional authorisation or cannot take action within the defined time.

Test 8.3: Access Control Enforcement

• Stimulus: Attempt to exercise a Level 2 escalation action using Level 1 credentials. Attempt to exercise a Level 3 action using Level 2 credentials.
• Expected behaviour: The system blocks the action and generates an alert.
• Pass criteria: All cross-level attempts are blocked.
• Fail criteria: Any cross-level attempt succeeds.

Test 8.4: Fallback Authority Availability

• Stimulus: Simulate the unavailability of each primary authority holder. Verify that the designated fallback authority is reachable and can exercise the required authority within the defined response time.
• Expected behaviour: Fallback authorities respond and act within the defined maximum response times.
• Pass criteria: All fallback authorities are reachable and capable of exercising their authority within the defined timeframes.
• Fail criteria: Any fallback authority is unreachable or cannot exercise their authority within the defined time.

Test 8.5: Automated Trigger Accuracy

• Stimulus: Inject synthetic anomalies that cross defined threshold triggers. Verify that the automated escalation system initiates escalation within the expected timeframe.
• Expected behaviour: Automated triggers fire within 60 seconds of threshold breach.
• Pass criteria: All synthetic anomalies trigger escalation within the defined timeframe.
• Fail criteria: Any threshold breach fails to trigger escalation or triggers with excessive delay.

Test 8.6: Escalation Logging Completeness

• Stimulus: Conduct a test escalation at each level. Verify that all required metadata (identity, authority level, trigger, action, timestamp) is captured in the escalation log.
• Expected behaviour: Complete metadata is logged for each escalation action.
• Pass criteria: All escalation actions are logged with complete metadata.
• Fail criteria: Any escalation action is missing from the log or has incomplete metadata.

Test 8.7: Semi-Annual Exercise Evidence

• Stimulus: Request evidence of the two most recent escalation exercises. Verify that they occurred within the past 12 months, involved authority holders at all levels, and produced documented findings.
• Expected behaviour: Exercise evidence exists, is timely, and includes documented findings and remediation tracking.
• Pass criteria: Two exercises within the past 12 months with complete documentation.
• Fail criteria: Fewer than two exercises in the past 12 months, or exercises lack documented findings.

Conformance Scoring

• Score 0: No escalation authority framework exists — incident response is ad-hoc, with no pre-defined authorities, triggers, or response times.
• Score 1: Escalation authority is documented but not enforced through access controls or tested through exercises — authority exists on paper but has not been validated operationally.
• Score 2: Escalation authority is enforced through access controls, tested semi-annually, and logged — the framework is operational, with documented exercises demonstrating that authority holders can act within defined response times.
• Score 3: Verified by independent testing — an independent party has conducted unannounced escalation exercises confirming that the framework operates as defined under realistic conditions, including fallback authority scenarios and automated triggers.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 14 (Human Oversight)	Direct requirement
EU AI Act	Article 9 (Risk Management System)	Supports compliance
FCA SYSC	3.2.6R (Responsibility for Compliance)	Supports compliance
FCA SM&CR	Prescribed Responsibilities	Direct requirement
NIST AI RMF	GOVERN 1.4, MANAGE 2.4	Supports compliance
ISO 42001	Clause 8.4 (AI System Operation)	Supports compliance
DORA	Article 11 (Response and Recovery)	Direct requirement
IEC 62443	SR 3.4 (Software and Information Integrity)	Supports compliance
NIS2 Directive	Article 21 (Cybersecurity Risk Management Measures)	Supports compliance

EU AI Act — Article 14 (Human Oversight)

Article 14 requires that high-risk AI systems are designed and developed so that they can be effectively overseen by natural persons during the period of use. Effective oversight requires the ability to intervene — which requires defined authority to intervene. AG-261 implements the authority framework that makes Article 14 oversight actionable. Without defined escalation authority, human oversight is observational, not interventional.

DORA — Article 11 (Response and Recovery)

Article 11 requires financial entities to put in place ICT-related incident management processes, including escalation procedures and communication protocols. For AI agent incidents, AG-261 provides the escalation authority framework that DORA Article 11 requires. The graduated authority model ensures that response is proportionate and timely.

FCA SM&CR — Prescribed Responsibilities

Under SM&CR, Senior Managers hold personal accountability for governance functions within their Prescribed Responsibilities. AG-261's Level 3 authority framework must map to SM&CR Prescribed Responsibilities, ensuring that the individual who holds Level 3 escalation authority also holds the SM&CR accountability for that function.

10. Failure Severity

Field	Value
Severity Rating	Critical
Blast Radius	Incident-specific but potentially organisation-wide if escalation failure allows an incident to compound

Consequence chain: Without defined escalation authority, the gap between detecting an AI agent anomaly and having authority to act on it becomes the period during which damage compounds. At machine speed, this gap can be catastrophic. An agent executing 100 transactions per second accumulates 6,000 transactions during a 1-minute authority vacuum — and 360,000 during an hour-long vacuum. The immediate consequence is delayed containment: the organisation knows something is wrong but cannot act because no one knows who has authority to act, or the person with authority is unreachable. The downstream consequences include: financial losses proportional to the delay duration and agent transaction rate; regulatory enforcement action for inadequate incident response procedures; personal liability for Senior Managers who failed to establish adequate escalation frameworks; and reputational damage from public disclosure of incidents that could have been contained earlier with proper authority structures.

Cross-references: This dimension builds upon AG-019 (Human Escalation & Override Triggers) which defines when escalation should occur — AG-261 defines who has the authority to act when it does; AG-259 (Role-Segregated Control Ownership Governance) which ensures that escalation authority is held by appropriately segregated individuals; AG-262 (Kill Authority Designation Governance) which addresses the specific authority to terminate an agent; AG-263 (On-Call Responsibility Governance) which ensures authority holders are available when agents operate; AG-264 (Successor and Coverage Planning Governance) which ensures fallback authority is maintained; and AG-267 (Incident Commander Assignment Governance) which establishes the command structure for managing escalated incidents.