Post 4 of the AgenticOps series introduced the four containment rings. This post shows what happens when a regulator asks to see them.

You Stopped Verifying. traced how verification gaps compound under pressure. This post is about a different kind of gap. One with a fine attached.

The EU AI Act enters its final enforcement phase on 2 August 2026. High-risk AI system obligations become enforceable: human oversight measures, six-month audit logs, kill switches. Not policies. Technical controls with financial penalties.

Penalties reach 35 million EUR or 7% of global annual turnover for the most serious violations. For high-risk system failures, 15 million EUR or 3% of turnover. That is not a compliance risk. That is a business risk.

I used to think AI governance meant writing the right policies. Define acceptable use. Assign a committee. Review quarterly. I know now that none of that produces a kill switch. And the Act requires one.

What the Act Actually Requires

Article 14 is specific. Natural persons assigned to oversee a high-risk AI system must be able to intervene or interrupt it through a stop button or similar procedure. Not a process that eventually leads to stopping. An actual mechanism. Operable now.

Article 12 requires automatic logging of events relevant to risk identification. Retained for at least six months. Not operational logs. Compliance logs. The kind that tell a regulator what the agent decided, what drove the decision, what it did.

Article 50 applies to all AI systems, not just high-risk ones. If your agent interacts with a natural person, it must disclose that it is an AI. Already applicable. Right now.

The Kiteworks Agents of Chaos study surveyed 225 security, IT, and risk leaders. 60% of organizations cannot terminate a misbehaving agent. 63% cannot enforce purpose limitations. 55% cannot isolate AI systems from network access. Real talk: those are compliance failures under the Act.

Why Most Organizations Will Miss It

The failure is structural. Organizations built Ring 3 first. Monitoring, logging, anomaly detection. That is the ring they already understood. The Act requires all four rings as technical controls.

First, a kill switch requires a control plane external to the agent runtime. Most organizations deploy agents as independent processes. No unified control plane. No mechanism to halt all instances simultaneously. Building one is a rearchitecting exercise, not a feature flag.

Second, compliance-grade audit logs are not operational logs. An operational log says “called API at 14:32.” A compliance log says “agent decided to escalate case 4521, sentiment 0.23, invoked route_to_queue, status change at 14:32:07Z.” Six months of those. Queryable by a regulator.

Third, purpose limitation as a technical control means the agent cannot access systems outside its intended scope at runtime. 63% of organizations define intended use in documentation. The agent’s actual scope is whatever tools and data it can reach at runtime. Feel me? That gap is what the Act targets.

The compound effect: most organizations have compliance gaps across three of four rings simultaneously. Ring 3 partially covered. Rings 1, 2, and 4 open. The Act requires all four.

The Fix: Map Rings to Requirements

Compliance is containment infrastructure. The four rings are the checklist. Let me give you a specific example.

Ring 1 is purpose limitation. Articles 9 and 13. The technical control is scoping the agent’s inputs before it starts.

# ring-1-purpose-limitation.yaml
agent: customer-escalation-handler
intended_purpose: "Classify and route customer escalation tickets"
tools:
  allowed:
    - read_ticket
    - classify_sentiment
    - route_to_queue
  denied:
    - update_customer_record
    - issue_refund
    - access_billing
data_scope:
  - tickets.escalation_queue
  - knowledge_base.routing_rules

When the agent cannot access billing systems, it cannot make billing decisions. Purpose limitation becomes a property of the environment, not the prompt.

Ring 2 is environmental isolation. Articles 9 and 15. Network restrictions, filesystem isolation, process sandboxing. Each boundary enforced by the runtime, not by the agent’s instructions.

Ring 3 is audit logging and transparency. Articles 12 and 50. This is the ring most organizations have partially built. The gap is granularity.

Ring 4 is the kill switch. Article 14. This is where 60% of organizations fail.

A compliant kill switch has three properties. It is reachable from outside the agent’s execution environment. It halts the agent within a bounded time, not after the task completes. It is operable by non-engineers assigned to oversight.

The control plane must be separate from the agent runtime. The agent cannot be responsible for its own termination.

What This Means for You

Organizations that built containment rings for engineering reasons will reach compliance faster. The rings were designed to contain stochastic processes. The Act requires containment of stochastic processes. The alignment is structural.

If you deployed agents with YAML policy controls, filesystem restrictions, and network allowlists, you are 80% of the way there. The remaining 20% is log enrichment, retention infrastructure, and a kill switch that non-engineers can operate.

Don’t be scared if you have no containment infrastructure. Article 57 requires each EU Member State to establish at least one AI regulatory sandbox by 2 August 2026. Engage early. Build the rings under regulatory guidance. Validate before penalties apply.

The four containment rings were built for engineering discipline. The regulation made them law. The infrastructure either exists or it does not. An auditor asking to see the kill switch will not accept a policy document.

Let’s talk about it.

Agents of Chaos: AI Agent Security Risks (Kiteworks, 2025)

EU AI Act Full Text (EUR-Lex)

You Stopped Verifying.