Lesson 4: Draw a Tool That Reaches Any Host

Training overview · Lesson 4 of 11 · Previous: Mark who is outside · Next: State what the agent can do

Goal

A tool that can reach any host is one flow to an untrusted "any host" element, and it is both a way out and a way in.

After this lesson you can draw a web fetch, a shell or any other tool whose destination the attacker can choose, without drawing every host it might reach.

What you start from

Your model from lesson 3, or import L3-solution.zip.

The team adds a web-fetch tool to the copilot, so it can open links that customers paste into tickets.

The recipe step

Step 4: Draw tools that reach any host

Draw every flow an agent's tools can open, outbound ones included. A tool that can reach any host (a web fetch, a shell, an image fetched while rendering) gets one flow to an "Arbitrary internet hosts" element in the Untrusted boundary, and the content it brings back as a Context Ingress.

Why: A tool that can reach any host is both a way out and a way in. Nothing infers it from an attribute: it counts only when it is drawn.

Ask:

• Which of the agent's tools can reach a host the attacker chooses?
• Can it reach internal addresses or the cloud metadata endpoint? If so, draw those flows too.

Classes: Untrusted Content Source, Agent Tool Call, HTTP/S Request, Context Ingress.

What the analysis reads here:

• A source whose content is untrusted by its class: Untrusted Content Source, Public AI Artifact Hub.
• A frontend that renders model output: Agent Chat Frontend.

Steps

1. Add Arbitrary internet hosts (class Untrusted Content Source), inside Internet.
2. Draw Fetch URL (class Agent Tool Call) from Support copilot to Arbitrary internet hosts.
3. Draw Context Ingress: fetched page (class Context Ingress) from Arbitrary internet hosts to Support copilot.
4. On the Data tab of Context Ingress: fetched page, add the data item Fetched page (no class). Sensitivity: Public; Origin: Arbitrary public; Credential: No.

The fetched page has no class: no data class describes a page fetched live. Give it the three fields anyway: they are what the analysis reads.

Generate again.

What you should see

Findings: 1 systemic finding: 1 Confirmed · 0 Not ruled out.

Facts to establish: 3 questions.

Facts that could raise a finding:

• Set the attribute Code Execution Tools Present (code_execution_tools_present, in Application Security) on Support copilot, or draw its Agent Tool Call to the harness
• Set the attribute Consequential Tools Present (consequential_tools_present, in Human Oversight) or Code Execution Tools Present (code_execution_tools_present, in Application Security) on Support copilot
• Draw the runtime boundary or the Agent Tool Call that ties Support copilot to its harness

Model gaps: 1 of 1 agents have no hosting harness drawn, so their W cannot be read from one (on Support copilot)

The summary looks the same as after lesson 3: the trifecta is still Confirmed. The change is inside the finding.

What changed and why

Expand the lethal trifecta and look at its legs.

X has a new route of the copilot's own. The fetch is a tool the copilot calls, so you draw it as an Agent Tool Call, like CRM lookup and Post reply. The fetch flow goes from the copilot straight to Arbitrary internet hosts, in the Untrusted zone. The copilot can send data out on its own, not only through the ticket system's e-mail. The route is labelled stated: you drew it.

U has a new route too. The content of a fetched page comes back on the Context Ingress from Arbitrary internet hosts. The route reads stated: the Fetched page item you drew on it has a stated origin, Arbitrary public. Its basis adds two more reasons: the source sits in the Untrusted zone, and it is an Untrusted Content Source, whose content is untrusted because of what the element is (a class premise). That premise would hold even with no data item drawn on the flow.

One element stands for every host. You do not draw each website. One element in the Untrusted boundary, one flow out to it and one Context Ingress back cover every host the tool can reach. Nothing infers a tool like this from an attribute: it counts only when it is drawn.

"Any host" can mean your own hosts too. If the tool can also reach internal addresses or the cloud metadata endpoint, those are destinations an attacker can choose as well. The step's second question asks about them: draw those flows too.

Exercise: Think in routes, not in tools

Make this change and generate again:

On a scratch copy: import L4-solution.zip and rename it.

1. Delete Reply e-mail.

Findings: 1 systemic finding: 1 Confirmed · 0 Not ruled out.

Facts to establish: 3 questions.

Facts that could raise a finding:

• Set the attribute Code Execution Tools Present (code_execution_tools_present, in Application Security) on Support copilot, or draw its Agent Tool Call to the harness
• Set the attribute Consequential Tools Present (consequential_tools_present, in Human Oversight) or Code Execution Tools Present (code_execution_tools_present, in Application Security) on Support copilot
• Draw the runtime boundary or the Agent Tool Call that ties Support copilot to its harness

Model gaps: 1 of 1 agents have no hosting harness drawn, so their W cannot be read from one (on Support copilot)

The trifecta stays Confirmed through the fetch. Removing the reply e-mail closed one way out, but the fetch is another. A leg is present as long as one route is present. When you look for a fix, count the routes, not the tools.

Delete the copy when you are done.

Next

Lesson 5: State what the agent can do. You answer the facts about the copilot that no drawing can show.