← Back to list

The AI Control Surface — Part 2 Threads & Perspectives: FTA + Fishbone

This is a seven part series that helps with framework to root cause the PocketOS like situation and prevent them in the future

Sudi Navile · 2026-05-10 22:13 · 0 claps · 4.3 min read
#root-cause-analysis #fta #fishbone-diagram #aisafetyanalysis #aibrf
Open on Medium ↗
Wiki topics: SAF · Safety & Alignment 🎬 · Film & Television

The AI Control Surface — Part 2

Threads & Perspectives: FTA + Fishbone

AI Infrastructure Blast Radius Framework (AIBRF) — A Practitioner’s Series

Why One RCA Tool Is Never Enough. Using fishbone and fault trees together to see the real control interactions in AI incidents

In April 2026, a Cursor agent deleted an entire production database and its backups on Railway in nine seconds. The failure was not caused by a single misconfiguration or a rogue model. It was a sociotechnical breakdown, the result of architecture, access control, agent design, process, data protection, and governance gaps aligning at once.

Most post-mortems pick one analytical tool and stop. They run a five-whys, sketch a fishbone, or build a timeline, then declare the root cause found. That approach is fine for simple failures. It is not sufficient for the class of incidents that AI agents can now produce at machine speed.

The PocketOS incident demanded two complementary lenses.

  • One to prove exactly why this failure happened.
  • One to map the full possibility space of similar failures that have not happened yet — but could.

That is why we used both a Fault Tree Analysis (FTA) and an abstract Ishikawa (fishbone) diagram. The FTA gives you the proof. The fishbone gives you the pattern. Together they form the analytical foundation for a prevention standard rather than another reactive patch.

Fault Tree Analysis: The Proof

A Fault Tree Analysis starts at the top — the undesired event — and works downward using logical gates.

An AND gate (∧) means all connected sub-events must be simultaneously true for the parent event to occur. An OR gate (∨) means any single sub-event is sufficient.

The AND gate is what makes FTA powerful: it forces you to identify the minimal cut set — the smallest combination of conditions that is both necessary and sufficient for the top event.

Top Event Autonomous AI agent deletes production database and all volume-level backups in approximately nine seconds (PocketOS, April 2026).

Level 1 — The Top AND Gate The top event required all three of the following to be true simultaneously:

  • [A] Agent gained access to a high-privilege infrastructure token
  • [B] Destructive API call was technically executable
  • [C] No defense layer stopped the action

Any single one absent would have stopped the incident.

Level 2 — Expanding Each Branch

Branch A — Agent Gained Access to a High-Privilege Token (AND)

  • Token existed with prod-level + destructive permissions
  • Token scope included volumeDelete with no restriction
  • Token was in a file location accessible to the agent

Branch B — Destructive Call Was Technically Executable (AND)

  • Railway exposed volumeDelete as a live, one-shot endpoint
  • Agent inferred the mutation from documentation without verification
  • Backups co-located on same volume — delete removed both simultaneously

Branch C — No Defense Layer Stopped the Action (AND) This is the richest branch. Five independent defensive layers all had holes that aligned simultaneously (the classic Swiss Cheese Model in action):

  • No AI/API gateway blocking destructive calls from agent principals
  • No human-in-the-loop approval for production infra changes
  • No tool allow/deny policy constraining agent API calls
  • No environment isolation — staging task could reach prod resources
  • No anomaly detection or kill switch for unusual agent operations

The Minimal Cut Set

Break any single link in this chain and the nine seconds does not happen. Give the agent a scoped token that excludes volumeDelete → permission-denied error, logged, stopped. Put a gateway in front that blocks destructive calls from agent principals → policy-rejected response, no deletion. Put backups on a separate volume → even if the deletion executes, the backups survive.

he Fishbone Analysis: The Pattern

The FTA told us why this incident happened. But what about the next one — on a different cloud provider, with a different destructive API, or in an enterprise with dozens of agents?

The fishbone answers a different question: Across the full possibility space of AI agent infrastructure failures, what categories of systemic cause could produce this class of outcome?

We built a six-bone fishbone with AI-infra-specific categories (not the generic manufacturing “6 Ms”)

  1. Architecture & Infrastructure — Shared failure domains, high-blast-radius APIs, weak environment isolation.
  2. Access & Credentials — Over-privileged tokens, token exposure to agents, absence of a destructive-only role.
  3. AI Agent Design & Guardrails — Over-broad autonomy, reliance on prompts instead of hard controls.
  4. Process & Change Management — No human approval, no AI-specific runbooks, no “AI-ready for prod” gate.
  5. Data Protection & Backups — Co-located backups, poor RPO, complex restore paths.
  6. Culture & Governance — Over-trust in AI tools, absence of org-level AI access policy.

(The full three-level decomposition is in the paper’s Appendix A. The diagram below shows Levels 1 and 2 for readability.)

Six Bones of AI Agent Infrastructure Failures

Six Bones of AI Agent Infrastructure Failures

What the Two Lenses Together Reveal

The FTA gives you the proof: these specific conditions co-existed and caused this specific failure. Break any single AND link and it does not happen.

The fishbone gives you the pattern: here is the full landscape of cause categories for this class of failure. The terrain that produced those specific conditions — and that will produce different ones next time if you do not address it systematically.

Together they define the requirements for a prevention framework:

  • It must address the minimal cut set from the FTA (the high-leverage control points).
  • It must address the full cause landscape from the fishbone (the systemic, cross-category conditions).
  • It must do both in a way that is implementable, auditable, and robust to the next incident, not just this one.

That is exactly what the Prevention Grid (and the rest of the framework) does.

For the full technical paper (fishbone, FTA, prevention grid, impact worksheet, Admin‑D spec, readiness checklist), see the AIBRF PocketOS paper.

© — toaiornot.ai a property of fourthcircle.ai

Full series links below

Link to Part 1 Prevention Grid

Link to Part 2 FTA + Fishbone

Link to Part 3 AIBRF Framework

Link to Part 4 AI/API Gateway

Link to Part 5 Admin-D

Link to Part 6 Dimension Cost Scorecard

Link to Part 7 Phase Roadmap


메타데이터
post_id
2c33e3062497
slug
the-ai-control-surface-part-2-threads-perspectives-fta-fishbone-2c33e3062497
url
https://medium.com/@snavile/the-ai-control-surface-part-2-threads-perspectives-fta-fishbone-2c33e3062497
canonical_url
https://medium.com/@snavile/the-ai-control-surface-part-2-threads-perspectives-fta-fishbone-2c33e3062497
author_url
https://medium.com/@snavile
status
ok
fetched_at
2026-06-09 15:37:30