Customer system and attack-path map
Select a path to trace preconditions, propagation, unsafe outcome, evidence, and the governance response.
See how an AI failure can move through a customer’s system, then connect the test evidence to controls, owners, decisions, and re-testing.
Select a path to trace preconditions, propagation, unsafe outcome, evidence, and the governance response.
The chain updates with the selected path. Each link must be explicit for a finding to change how the system is governed.
Trace whether injected content affects tool choice or arguments.
Retrieved chunk, provenance, model trace, authorization result, side-effect log.
AI product owner + Product security
Untrusted content cannot authorize a privileged tool action.
Keep writes behind confirmation until the control claim passes.
Re-run after model, router, corpus pipeline, or tool-permission changes.
This is a scoped starting set, not an exhaustive taxonomy. A real engagement adds paths from architecture review, threat intelligence, incidents, stakeholder concerns, and observed behavior.
| Path | Unsafe outcome | Priority lens | Control evidence | Decision gate | Accountable owners |
|---|
System mapping is useful only when it sharpens testing and survives contact with operational decision-making.
Identify actors, assets, trust boundaries, dependencies, privileged actions, and the system changes that matter.
Express each concern as an attack path with preconditions, a test sequence, an unsafe outcome, and required evidence.
Link findings to the owner with authority, the control claim being relied on, and the decision the evidence should change.
Record residual uncertainty and re-run the relevant tests when models, prompts, tools, data, permissions, or workflows change.
A client engagement replaces this illustrative model with your architecture, threat hypotheses, evidence sources, controls, owners, and review cadence.