The agentic AI containment-action gap, viewed from the desktop layer

The thesis

Almost every essay on the containment-action gap is written from a CISO’s desk. The agent in question is a service: it lives in someone’s cloud, it authenticates through an identity provider, it accesses data through APIs the security team can audit. The fix is policy: tighter scopes, kill switches at the IAM layer, runtime governance frameworks, action-based access models. That writing is not wrong. It is also not the worst version of the problem.

The worst version is on your laptop. A desktop computer-use agent runs inside your logged-in OS session. It does not authenticate to your apps because your apps already trust you. It drives the UI through the accessibility API, which gives it the same surface area a human gets, including the bits no API exposes. There is no identity provider in front of it. There is no token to revoke. The blast radius is everything you have a cookie for, every keychain entry, every SSH key, every browser tab that is already logged in. If you cannot stop the next tool call, you cannot contain the agent.

That changes the engineering problem. Containment on the desktop is not a policy plane sitting beside the workload. It is a piece of the runtime, embedded in whatever the agent uses to talk to the model. If the runtime does not have a real interrupt path that can stop the next click in flight, no amount of dashboarding above it matters.

What this looks like in Fazm’s source

Fazm is a macOS computer-use agent. The chat side is Swift. The model side is a Node process that speaks Anthropic’s ACP (agent client protocol) over stdio. Almost everything containment-shaped lives in one file: Desktop/Sources/Chat/ACPBridge.swift.

Two methods do the work. The first is the legacy global interrupt at line 1158:

/// Interrupt the running agent, keeping partial response.
func interrupt() {
  guard isRunning else { return }
  isInterrupted = true
  // Also mark every active per-session query as interrupted
  for key in sessionContinuations.keys {
    sessionInterrupted[key] = true
  }
  sendLine("{\"type\":\"interrupt\"}")
}

That is the broad halt. Useful, but if you are running three concurrent sessions (a foreground chat, a queued cron, a pop-out window), it cancels all three. The surgical version is right below it at line 1169:

/// Interrupt a specific session only. Other concurrent
/// sessions continue running.
func interrupt(sessionKey: String) {
  guard isRunning else { return }
  sessionInterrupted[sessionKey] = true
  let dict: [String: Any] = [
    "type": "interrupt",
    "sessionKey": sessionKey,
  ]
  if let data = try? JSONSerialization.data(withJSONObject: dict),
     let json = String(data: data, encoding: .utf8) {
    sendLine(json)
  }
}

The flag flip is local; the JSON line is the wire signal that reaches the Node bridge. Inside query(), around line 951, the loop checks the flag before each subsequent tool call:

// Per-session interrupt flag takes precedence;
// fall back to legacy global
let interrupted = sessionKey
  .flatMap { sessionInterrupted[$0] } ?? isInterrupted
if interrupted {
  log("ACPBridge: skipping tool call \(name) (interrupted)")
  // ...drain pending messages, return partial
}

That is the action gap closing in code. The model can still propose more tool calls, the bridge can still receive them, but the runtime stops dispatching them as soon as the user flips the flag. The interrupt is not advisory and not best-effort. It runs on the same path that does the dispatching.

What the user sees when the watchdog fires

The other half of containment is what happens when the user does not press stop, but the agent gets stuck. The bridge ships a watchdog tied to FAZM_TOOL_TIMEOUT_SECONDS (passed in via the env at line 473). When a tool exceeds it, the bridge emits a structured cancellation event. The Swift handler at line 1144 turns that into a log line and forwards it as a status event the UI renders as a system card.

How that compares to the typical cloud-agent stop

Most cloud-agent platforms expose stop as a state mutation in a control plane. You hit a /stop endpoint, the control plane writes “cancelled” to the run row, the worker eventually polls and gives up. There is real distance between “user pressed stop” and “tool stops executing.” On a desktop runtime that distance is fatal: the action you wanted to stop already fired clicks. The bridge model collapses the distance because the dispatcher and the interrupt flag live in the same process.

The lifecycle, end to end

Five stages between “user presses stop” and “the model knows the turn is over.” None of them require a network round trip. All of them are observable in the bridge log.

Three things that make desktop containment different

What this does not solve

Honest part. The interrupt path stops the next tool call. It does not roll back the previous one. If the agent already shipped an email, deleted a row, or pushed a commit, that is gone. Closing the action gap is necessary; it is not the same as closing the consequences gap. The containment work that pairs with the interrupt is the boring stuff: dry-run modes for destructive tools, confirmation prompts on side-effect tools, structured logs of every dispatched action so a human can audit what happened. Those live in the bundled skills layer, not in the bridge.

The interrupt path also assumes the bridge is healthy. If the Node process is wedged hard enough that stdin is not being read, the JSON line lands in the kernel pipe buffer and goes nowhere. That is what the orphan sweep at startup (Self.sweepOrphanedBridges) and the global stop are for. They are the layer below the surgical interrupt and they exist because real processes do hang.

None of this generalizes for free to other desktop agents. It only matters that one open-source implementation does it, because that is enough to stop the conversation from being abstract. Anyone arguing that desktop computer use is intractable on the containment side has to engage with running code, not a whitepaper.