Tool Use
Advanced 13 min read Tool Use

Tool Security

Model args are attacker input

Tools widen the attack surface: prompt injection through tool inputs, SSRF from URL tools, exfiltration through write tools. Security means treating model-controllable arguments as untrusted input to every system they reach.

securityprompt injectionssrfexfiltrationinput validationuntrusted
Prerequisites: Tool Governance
Before we start

What you will learn

  • Trust-boundary tool arguments
  • Prevent SSRF via URL tools
  • Stop data exfiltration via writes
Introduction

What is this?

Tool arguments originate from model output, which is influenced by user and web content — i.e., by attackers. Tool security is treating those args as untrusted: validate and allowlist everything, sandbox executors, block internal-network targets, and scrub content before it re-enters a prompt.

Motivation

Why do you need it?

  • Prompt injection can steer tools (search a URL, send a file) — a RCE-ish chain.
  • SSRF lets a crafted URL hit internal metadata endpoints.
  • Write tools turn exfiltration into a one-liner.
  • Content injected into RAG/web pages becomes instructions on re-read.
Think about it

Mental model

Imagine

Treating every phone caller as a lobby visitor

Think of

Tool security

You wouldn't give a caller your building master key because they 'asked politely'. Tool args come from an untrusted caller (the composite of user+web). So you check ID (allowlists), escort through public areas only (sandbox), and never let guests read the server closet (internal hosts).

Mechanics

How it works

  • Validate args against strict schemas at dispatch.
  • Allowlist hosts/protocols for any URL-fetching tool.
  • Sandbox executors; no internal network, no secrets.
  • Truncate/scrub fetched content; treat as data, not instructions.
  • Audit tool sequences to spot exfiltration patterns.

Threat chain to close.

User
Web/RAG
Args
Tool
Systems
Real world

In production

  • URL tools restrict to an allowlisted, public-host domain set.
  • File tools run in read-only mounts with MIME checks.
  • Write tools target scoped namespaces and rate-capped queues.
Guidelines

Best practices

  • Schema-validate args before ANY tool runs.
  • Never let model-picked URLs reach internal hosts (SSRF guard).
  • Sandbox executors; keep secrets outside reach.
  • Log and alert on odd tool sequences (fetch→send patterns).
Watch out

Common mistakes

  • Hidden internal endpoints reachable via flexible tools.
  • Trusting 'the model decided it', so skipping schema checks.
  • Storing secrets in tool-visible env vars.
Root cause analysis

Common issues

Error
Tool accesses blocked host
Root cause

Allowlist missing/loose

Fix

Enforce explicit protocol+host allowlist at the tool boundary.

Error
Prompt injection steered write tool
Root cause

Content trusted

Fix

Never let fetched content read as instructions; scrub and treat as data.

When things break

Debugging tips

  • Suspicious URL pattern → audit tool fetch history; tighten allowlist.
  • Cross-tenant reads → scope checks missing in dispatch.
  • Content anomalies → inspect injected text for instruction strings.
Interviews

Interview checkpoint

Practice

Hands-on lab

Harden a URL Tool Against SSRF
40 min · advanced
In progress
Objectives
  • Allowlist protocols and hosts
  • Block internal/loopback targets
  • Validate args before fetch

Harden a URL Tool Against SSRF

40 min · advanced

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

Model-picked URLs must be…

2

Fetched web content is data, not instructions.

Go deeper

Official documentation

OWASP LLM Top 10
docs