The △ PUO badge: how it works why an agent on the canvas is flagged with all three legs

The badge on the canvas

The badge 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 with a red △ followed by three coloured letters: a red P for private data, an amberU for untrusted content, and a blue O for outbound. Hover the badge 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.

The badge 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 data when its sensitivity is marked sensitive or regulated, or when it carries PII, credentials, secrets, or session tokens.

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 is marked untrusted: end-user input, open-web fetches, third-party documents, user-uploaded files, or messages from agents the team does not own.

The direction is the load-bearing detail. Untrusted content flows into the agent (you read it; it doesn’t call you), so Helmwart walks the connections backward from the agent until it reaches an untrusted source. If the path back exists, the leg counts.

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 theprimer. For the cut-one-leg playbook and the design rationale, read theprinciple.