Syntony
This preview shows how a failure can move through an AI-enabled customer service system. Select a path to see what to test, which controls should stop it, who owns the response, and what decision the result informs.
Select a path to see how the failure could propagate, what evidence the test should capture, and how the client could respond.
The cards update when you select another path. They show what the client needs to document to act on a finding and revisit it later.
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.
The register shows six example paths. A client register is expanded using its architecture, threat intelligence, incident history, stakeholder concerns, and observed system behavior.
| Path | Unsafe outcome | Planning scores | Candidate controls | Decision | Responsible teams |
|---|
A useful system map makes the evaluation more precise and helps the responsible team decide what to do with the result.
Identify actors, assets, trust boundaries, dependencies, privileged actions, and the system changes that matter.
For each attack path, state the conditions, test steps, unsafe outcome, and evidence to collect.
Link each finding to the control under test, the team responsible for it, and the decision the evidence will inform.
Record the remaining uncertainty and re-run the test when a relevant part of the system changes.
For a client engagement, Syntony replaces this example with a map of your architecture and threat hypotheses. Each path is tied to evidence, controls, decision rights, and a schedule for reviewing changes.