Paste the config. Get the threat model. Same config in, same findings out.
Helmwart reads the file that already defines your agent system: an MCP server list, an n8n export, a LangGraph or CrewAI project, a Bedrock or Foundry agent, 16 formats in all. It rebuilds it as a graph of agents, tools, memory and data, then checks the graph against 51 threat classes. No language model sits in that loop. The findings come from fixed rules over the graph, which is why they can be reproduced, diffed and gated on.
Fixes · evidence · a build gate
What you walk away with.
For the engineer
The fix, written for your platform
All 67 mitigations carry remediation for the platform the config names. Not "apply least privilege" left as an exercise, but the concrete change to make in Bedrock, n8n, LangGraph, Foundry, whichever runtime you actually run.
For the auditor
Evidence that exports
The threat model maps requirement by requirement onto NIST AI RMF, the EU AI Act, ISO 42001, SOC 2, ISO 27001 and the NHI Top 10, and exports as an evidence report. Control questions get answered from the model instead of from memory.
For the pipeline
A gate that fails the build
helmwart scan --fail-on critical runs the engine on every change and stops the merge when a critical finding appears. SARIF output puts findings in GitHub's Security tab beside the rest of your checks.
No model in the loop
It reads reachability, not keywords.
The findings that matter most are combinations. An agent that takes in untrusted content while holding private data and an open path out is one prompt injection away from a leak, and no single edge in that triangle looks wrong on its own. The engine walks the actual edges of your graph to find where all three meet, then points at the specific connection that completes the triangle.
All of it happens at design time, on the shape of the system. A scanner probes a running deployment for what already went wrong; this reads the design for what still could, while the wiring is still cheap to change.
The method is the standard one.
Adam Shostack's four questions, applied to agentic systems.What are we working on?
Map the agents, tools, memory and trust boundaries onto a canvas, or import them from the config.
What can go wrong?
The engine enumerates the threats that traverse your graph, each mapped to the OWASP catalog.
What are we going to do about it?
Place controls against each threat and watch residual risk move.
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.
The account is free. Paste one config and read what comes back.
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.