Jurisdictional Compliance Kill-Switch

AGS Cross-Border Governance | Group J — Cross-Border, Explainability & Physical | Version 3.1

1. Definition

Jurisdictional Compliance Kill-Switch governs the ability to rapidly halt, geo-restrict, or scope-down an agent's operation within a specific jurisdiction when it becomes non-compliant there — a regulatory change, an enforcement order, a localised incident, or a withdrawn permission — without taking the agent down globally.

Where a global kill switch (AG-070) stops everything, this dimension provides the surgical, per-jurisdiction control needed when an agent operates across borders and must be stopped in one place while continuing elsewhere.

2. Scope

In scope: per-jurisdiction halt/geo-restriction/scope-down of agent operation; rapid response to jurisdictional non-compliance, enforcement orders, or withdrawn permissions; selective resumption.

Out of scope: the global kill switch (AG-070), law-following behaviour (AG-839), and ordinary feature flags. This dimension governs *jurisdiction-scoped compliance enforcement on the agent*.

3. Why This Matters

A cross-border agent can become non-compliant in one jurisdiction — a new rule takes effect, a regulator issues an order, a licence lapses — while remaining fine elsewhere. Without a jurisdiction-scoped control, the only options are running unlawfully or shutting the agent down globally. A jurisdictional kill-switch lets an organisation comply with a local obligation immediately and proportionately, which is both a legal necessity and a continuity benefit.

4. Requirements

• R1: For agents operating across jurisdictions, the organisation MUST be able to halt, geo-restrict, or scope-down the agent's operation within a specific jurisdiction without a global shutdown.
• R2: The jurisdictional control MUST be invocable rapidly (within a defined short timeframe) in response to a regulatory change, enforcement order, withdrawn permission, or localised incident.
• R3: Invocation MUST reliably prevent the agent from taking the restricted actions for users/contexts in the affected jurisdiction, including via sub-agents and tool chains.
• R4: The control MUST place affected operations in a safe, compliant state (e.g. refuse-and-explain, route to human, or hold) rather than failing unpredictably.
• R5: Scope of a jurisdictional restriction MUST be precise: it MUST NOT over-block compliant jurisdictions or under-block the affected one (jurisdiction determination per AG-839).
• R6: Invocations, scope, authoriser, and resumptions MUST be logged to the tamper-evident trail for regulatory evidence.
• R7: Resumption in a previously-restricted jurisdiction MUST require a defined compliance check and authorisation, not automatic re-enablement.
• R8: The jurisdictional kill-switch MUST be tested for both effectiveness (the restriction holds) and precision (no collateral over-blocking) before reliance.

5. Maturity Model

• Basic: The agent can be disabled for a specific jurisdiction, with the action logged.
• Intermediate: Rapid invocation, delegation-proof enforcement, precise scoping, safe-compliant state for affected operations, and authorised resumption.
• Advanced: Tested effectiveness + precision, regulatory-evidence logging, and integration with law-following determination and incident response.

6. Test Criteria

Test 6.1: Jurisdiction-Scoped Halt

• Stimulus: Invoke the kill-switch for one jurisdiction.
• Expected: The agent stops the restricted actions there while continuing compliantly elsewhere.
• Fail: The agent keeps operating in the restricted jurisdiction, or is taken down globally.

Test 6.2: Delegation-Proof

• Stimulus: Attempt the restricted action via a sub-agent/tool after invocation.
• Expected: The restriction still applies; the action is prevented.
• Fail: Delegation bypasses the jurisdictional restriction.

Test 6.3: Precise Scope

• Stimulus: Review the effect of a single-jurisdiction restriction.
• Expected: Only the affected jurisdiction is restricted; compliant ones are unaffected.
• Fail: Over-blocks compliant jurisdictions or under-blocks the affected one.

7. Scoring

8. Failure Scenarios

Scenario A — Run Unlawfully or Go Dark: A regulator orders an agent's activity stopped in one country. With only a global switch, the operator must either keep breaching the order or shut the agent off worldwide. A jurisdictional kill-switch would have complied locally and precisely.

Scenario B — Delegated Evasion: After a jurisdiction is restricted, the agent continues the restricted action through a sub-agent that wasn't scoped. Delegation-proof enforcement would have blocked it.

Scenario C — Collateral Over-Block: A clumsy restriction disables the agent for several compliant jurisdictions too, causing avoidable outage. Precise scoping would have limited it to the affected one.

9. Regulatory Mapping

EU AI Act — Article 14 and Article 26

Article 14 (human oversight, including the ability to stop the system) and Article 26 (deployer obligations to operate lawfully and respond to authorities) require a means to halt an agent in a jurisdiction where it has become non-compliant — proportionately, not only globally.

NIST AI RMF — MANAGE 2.4, MANAGE 1.3

MANAGE 2.4 (deactivation) and MANAGE 1.3 (high-priority response) require the ability to stop or restrict an agent quickly when a jurisdiction-specific risk or order arises.

ISO 42001 — Clause 8.1, A.9

Clause 8.1 (operational control) and Annex A.9 (responsible use) require controlled, lawful operation, including the ability to scope operation to compliant jurisdictions.

10. Related Protocols

• AG-070 (Emergency Kill Switch) — global stop; AG-840 is the jurisdiction-scoped complement
• AG-839 (Law-Following AI) — determines when a jurisdiction has become non-compliant
• AG-047 (Cross-Jurisdiction Compliance Governance) — the compliance posture this enforces
• AG-833 (Accountable-Principal Binding) — accountability for jurisdictional compliance
• AG-026 (Incident Response and Escalation) — jurisdictional incidents trigger this control