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
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”)
- Architecture & Infrastructure — Shared failure domains, high-blast-radius APIs, weak environment isolation.
- Access & Credentials — Over-privileged tokens, token exposure to agents, absence of a destructive-only role.
- AI Agent Design & Guardrails — Over-broad autonomy, reliance on prompts instead of hard controls.
- Process & Change Management — No human approval, no AI-specific runbooks, no “AI-ready for prod” gate.
- Data Protection & Backups — Co-located backups, poor RPO, complex restore paths.
- 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
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