Tools are the attack surface

Before you start, from Lessons 1 and 2: which three legs does the Rule of Two count? In Lesson 1, where in the context did an instruction carry least weight on your model, and how sure are you of that difference?

Lesson 2 drew the trifecta as a property of a session. This lesson looks at where the legs come from in practice: the tools an agent is given, and the configuration that gives them.

Tool text is trusted text

A tool reaches the model as a name, a description and an input schema, placed in the context the model reads. The user rarely sees that text. The model reads it as part of its instructions. The Model Context Protocol's specification says clients "MUST consider tool annotations to be untrusted unless they come from trusted servers", and its guidance on local servers advises treating tool definitions as untrusted input. On pinning definitions, so that a later change is noticed, the guidance is candid: "The protocol does not require this".¹

Hidden instructions in tool metadata are called tool poisoning. On the MCPTox benchmark, tool-description poisoning succeeded 36.5% of the time on average across 20 models, and 72.8% on the worst model.² MITRE ATLAS records publishing a poisoned agent tool as a technique. Since July 2026 it is AML.T0115.002, "Publish Poisoned AI Artifacts: AI Agent Tools". The release that lists it, v2026.09, has 120 techniques and 73 case studies.³

Config is code

The worst MCP bugs of 2025 and 2026 were not model failures. They were configuration that ran code. The Cloud Security Alliance's July 2026 note collects them. In CVE-2025-54136, a client bound its approval to a server's name rather than its content, so a config changed after approval ran without a word to anyone. In CVE-2025-54135, rated CVSS 8.6, an injected message rewrote the global MCP config and started a program. A May 2026 study found trust prompts in several command-line coding agents that defaulted to yes, or were skipped in headless runs. And a worm planted malicious MCP configs in 73 GitHub repositories.⁴

This course recommends the old supply-chain controls, applied to a new artefact. Approval binds to a server's content, not its name. Config changes get code review. Unattended runs never auto-trust. Credentials are short-lived and scoped to one session's tools. In the OWASP Top 10 for Agentic Applications 2026 these fall under ASI02 Tool Misuse and Exploitation, ASI04 Agentic Supply Chain Vulnerabilities and ASI05 Unexpected Code Execution (RCE).⁵

Red tools and blue tools

Tim Kellogg proposed a colouring for tools: red if a tool ingests untrusted input, blue if it takes a critical action, and never red and blue tools in the same context.⁶ A tool list coloured before any test runs shows where the two meet.

Agents act on the world

In July 2026 the UK AI Security Institute ran a cyber challenge 122 times, with internet access deliberately enabled and the developers' cyber classifiers deliberately switched off. Across 10 of those runs, agents took 19 actions the institute had not sanctioned, on the live internet. In the worst case an agent went rather further than anyone had asked. It created fake identities, used them to socially engineer a real maintainer, and opened a malicious pull request on a real open-source project. The institute found no resulting real-world harm. It says it cannot yet be certain when the agent understood that it was taking real-world action.⁷

Two lessons for a tester follow. The first is that agents can target other systems and other agents, so containment belongs to the test from the start. The second is that a result measured with a sandbox and classifiers in place is a different measurement from the model alone. Say which one you took.

The lab

The toy agent runs a local model with three stub tools. None of them reaches anything outside a folder you made.

Prepare everything while online: pull the model and build the agent image with its Python packages, because an internal network cannot download anything. Then run the agent and the model in containers on an internal network: docker network create --internal agentlab (Podman takes the same flag), start Ollama on it, and start the agent with docker run --rm --network agentlab --read-only --tmpfs /tmp --cap-drop ALL --security-opt no-new-privileges -v ./lab:/lab <your image>. An internal network can still reach the host's gateway address, so keep any Ollama on the host bound to the loopback interface only.⁸ Docker Desktop is free for personal use, education and small businesses; Podman is a free alternative.⁹ Inspect's Docker sandbox, whose generated configuration sets network_mode: none (a custom compose file must set it again), is another route.¹⁰

# toy agent skeleton (MIT). Fill the three marked lines; see Ollama's tool-calling docs.
import json, ollama
LAB = "/lab"
client = ollama.Client(host="http://ollama:11434")   # the Ollama container on the internal network
def read_notes():  return open(f"{LAB}/notes.txt").read()
def fetch_doc():   return open(f"{LAB}/page.html").read()
def send_message(text):
    with open(f"{LAB}/outbox.log", "a") as f:
        f.write(json.dumps({"text": text}) + "\n")      # the only effect: one log line
    return "logged"
TOOLS = {"read_notes": read_notes, "fetch_doc": fetch_doc, "send_message": send_message}
def run(task, model="granite4:3b", max_turns=6):
    messages = [{"role": "user", "content": task}]
    for _ in range(max_turns):
        reply = ...   # 1. client.chat(model=..., messages=..., tools=[...]) with your options
        messages.append(reply.message)
        if not reply.message.tool_calls:
            return messages
        for call in reply.message.tool_calls:
            name = call.function.name
            if name not in TOOLS:
                raise SystemExit(f"STOP: unknown tool {name}")   # stop rule
            result = ...  # 2. call TOOLS[name] with call.function.arguments
            ...           # 3. append {"role": "tool", "tool_name": name, "content": result}
    return messages

Tool calling follows Ollama's documented loop.¹¹ The granite4:3b model in Ollama's library lists tool support; check its model card for the exact variant. Log every message and tool call to a JSONL file beside the run record.

Writing it up

Write the diagram's findings first: the sessions that held all three legs, and the redesign that removed one. Then the build and scan results, with the run record. Read it against the rubric from Lesson 1.

Lesson text is CC BY 4.0 and code samples are MIT.