Threat modeling for agentic systems
Turn an agent repository into a security decision your team can explain.
Helmwart reads supported agent configuration, maps how agents connect to tools, memory, and data, then traces which threat paths that design makes reachable. The result is a cited finding, a control to test, and evidence your team can review before release.
Analysis is based on supported local configuration. See what stays local and what you choose to share.
- 01Read the systemAgents · tools · memory · data
- 02Trace reachabilityFind paths the design permits
- 03Test a controlChange · rescan · keep evidence
Static analysis of declared configuration—not runtime behavior or a safety certification.
Useful to the whole review team
One model. Three decisions it helps you make.
Connect the analysis to a change your team can verify.
For the engineer
The fix, written for your platform
Use platform-specific guidance across 68 mitigations to choose a concrete control, then rescan to see whether the reachable path changed.
For the auditor
Evidence that exports
Trace findings and control coverage into evidence reports. Mappings organize review evidence; they do not certify compliance or replace assessor judgment.
For the pipeline
A gate that fails the build
Run helmwart scan --fail-on critical in CI to fail a build when a critical finding remains. SARIF can surface findings in GitHub’s Security tab.
Deterministic graph analysis
It traces reachability, not keywords.
A risk can emerge from a combination: an agent may receive untrusted content, reach sensitive data, and have a declared path to an external action. One permission in isolation may look ordinary. Helmwart traces configured connections to show when those capabilities meet, and which edge or control deserves review. That is a signal about declared reachability—not proof that an exploit will succeed.
This is design-time analysis of supported files, not a probe of a running deployment. It can reveal paths to investigate before release, but cannot observe runtime prompts, actual credentials, or behavior that the configuration does not describe.
The method is the standard one.
Adam Shostack's four questions, applied to agentic systems.-
1
What are we working on?
Map the agents, tools, memory and trust boundaries onto a canvas, or import them from the config.
-
2
What can go wrong?
The engine enumerates the threats that traverse your graph, each mapped to the OWASP catalog.
-
3
What are we going to do about it?
Place controls against each threat and watch residual risk move.
-
4
Did we do a good enough job?
Audit against zero-trust, least-privilege and defence-in-depth, then sign off.
It stands on published work.
Helmwart maps onto these, it does not replace them.Two OWASP publications inform the catalog. The MAS guide reuses some extended IDs for scenario variants; Helmwart normalizes those and represents the colliding RPA source T16 / T17 entries as T48 / T49.
Where the engine stops.
The engine reads what the configuration declares. It cannot see the prompt that will actually arrive in production, the credential scoped too wide in a console it never opens, or the people around the system. So there is no safety score here, and framework coverage is a map of placed controls and remaining gaps, not a compliance verdict. Helmwart makes a security review a head start; it does not replace one. The sign-off stays with a person.
See it on a config you actually run.
Start with local configuration, inspect reachable paths, and decide what evidence is useful to share.
Helmwart is independent. It is not endorsed by or affiliated with OWASP, the Cloud Security Alliance or MITRE. The threat reference content is adapted from their published frameworks under CC BY-SA 4.0.