The leak-path marker: how it works why an agent on the canvas is flagged with all three legs

The companion page, how posture is computed, covers the other number on an agent card. The two measure different things and can disagree by design.

The marker on the canvas

The marker appears in the corner of an agent’s card in the Threats view (the default when the canvas first loads). It is a clickable button: a small red dot followed by the words Leak path. Hover it and you see the three reachable endpoints Helmwart found. Click it and the side panel opens with the full paths, so you can inspect which private node, which untrusted source, and which outbound exit are in play. Screen readers get the same thing spelled out — Lethal Trifecta: private + untrusted + outbound all reachable. The hover popover carries its own tab, TRIFECTA · n, where n is how many of the agent’s findings the path implicates.

The marker only renders on agents. Other node kinds never get one, because the trifecta is a property of an agent’s reachable surface, not of any single data store or tool.

How Helmwart spots the Private leg

An agent gets credit for the Private leg when Helmwart can walk from it to any node that holds sensitive data. A node counts as private when one of three things is true of it: its sensitivity is marked sensitive or regulated, it is flagged as containing PII, or it is flagged as containing credentials. Those are the only properties this leg reads — there is no separate field for secrets or session tokens, so material of that kind has to be described by one of the three.

Helmwart only follows connections that actually flow data on this leg: a tool call into a database, a memory read against a shared store, a call out to a system of record, a message to another agent that holds the data. Administrative connections that don’t carry data are excluded (more on that below).

How Helmwart spots the Untrusted leg

An agent gets credit for the Untrusted leg when Helmwart can trace back from the agent’s context to a source the attacker can influence. A source counts as untrusted when its provenance — or its content provenance — is untrusted or partial. Partial matters as much as untrusted: it means validated upstream but not signed end to end, which is a real poisoning surface and the commonest shape a RAG corpus takes.

Two kinds of node are untrusted by default, and the author has to say otherwise: an end user, and a document store whose source is the open web or user uploads. Marking either one trusted is the exemption, and it is honoured — an authenticated internal portal or a curated, signed mirror stops counting. Nothing else is assumed: a source with no provenance set does not count.

Direction is the load-bearing detail, and it is not simply “backward”. Push-style connections — a user interaction, a message from a peer, a delegation from an orchestrator — flow into the agent, so Helmwart walks those in reverse. Read-style connections are walked both ways: an agent that pulls from a poisoned corpus ingests that content exactly as one the corpus pushes to it, so a memory read or a tool call counts in either direction. Walking those backward only would miss the commonest RAG case entirely.

One exclusion is worth knowing before you model anything, because it is the quiet way to get no marker at all. An external-call edge is not walked on this leg. That is deliberate: a fetch that returns untrusted content is modelled as a tool call, not an external call. If you draw an open-web fetch as an external call, the content is never treated as reaching the agent’s context, the untrusted leg does not count, and nothing on the canvas explains why. Model it as a tool call.

How Helmwart spots the Outbound leg

An agent gets credit for the Outbound leg when Helmwart can walk from it to any node that can talk to the outside world. A node counts as outbound when it is configured with outbound network access: an external API client, a send-email tool, a webhook caller, even a Markdown renderer that resolves attacker-controlled URLs as images.

When the badge fires

All three legs reachable from the same agent fires the badge. Two legs out of three does not; that is a watch state, not a structural exfiltration path. When the badge fires, opening the side panel shows the three actual paths Helmwart found so the finding can be inspected and acted on. The badge clears the moment any one leg becomes unreachable, which is why the fix in the principle is always to cut a leg rather than to soften a finding.

What doesn’t count

Two categories of connection are deliberately excluded from all three walks. Without these exclusions, every well-designed agent would trivially carry the badge, because every well-designed agent emits audit logs and routes consequential actions through human review.

Edges the author marked as sanitised. When an edge is marked as strictly sanitised, the author is asserting that content arriving on it has been cleaned of injection payloads (content-disarm-and-reconstruct, a strict-mode LLM filter, or equivalent). Helmwart trusts the assertion and the Untrusted walk does not cross that edge. The Private and Outbound legs have no equivalent opt-out; sanitising content does nothing to remove capability.

Administrative connections. Audit-log emissions, human-in-the-loop approval gates, telemetry sinks, observability sidecars. These connect the agent to something but do not flow data in the sense the trifecta cares about. Helmwart excludes them from every walk.

Walking through one example

Picture a support agent connected to three neighbours:

• A web form where customers type questions.
• A customer database holding regulated PII.
• An email-send tool that talks to an external SMTP service.

The web form feeds the agent’s context (the agent reads each question). The agent can query the database for the customer’s record. The agent can send email summaries back. All three walks succeed in one hop: the Untrusted walk steps back from the agent and lands at the web form, the Private walk steps forward and lands at the customer database, the Outbound walk steps forward and lands at the email tool.

The badge fires on the support agent. The side-panel inspector reads: untrusted from web form, private to customer database, outbound via email-send tool. A single crafted question typed into the web form could now read a customer record and exfiltrate it via email. The EchoLeak shape, on your own agent.

What this doesn’t catch

Two limits worth knowing about.

Three legs split across three agents. If one agent holds the private data, a peer ingests the untrusted content, and a third has the outbound capability, the per-agent check passes for each of them. The end-to-end exfiltration path still exists; the badge just doesn’t cover it. Threat coverage for that case lives in T12, T30, and T47. Topology-level detection across peers is on the open work list.

Very long delegation chains. Each walk stops at a depth of eight hops. If the path to a private store, an untrusted source, or an outbound exit requires more than that, the walk gives up and the leg is not flagged. The limit is a runtime trade-off; raising it costs time on dense graphs.

For the concept behind the trifecta, read the primer. For the cut-one-leg playbook and the design rationale, read the principle.