AI Agents Engineering · Tool Use & Function Calling · Lesson 3 of 3
Least privilege & tool security
Every tool is an attack surface. An agent that can read data and take actions is only as safe as the weakest tool you gave it. Design tool permissions the way you would design a service account: least privilege.
- Least privilege: give each tool the narrowest scope that works (read-only where possible; a single calendar, not the whole org).
- Validate + sanitize arguments server-side: the model can emit anything. Parameterize queries; never string-concat into SQL/shell.
- Allow-list high-impact actions: refunds, sends, deletes, and payments go through explicit checks or human approval.
- Untrusted content: tool results and retrieved documents can contain instructions (indirect prompt injection) — treat them as data, not commands.
- Rate limit + audit: cap tool calls, log every call with inputs/outputs for tracing and forensics.
Say 'security boundary'Interviewers want to hear that the tool executor is the trust boundary: the model is untrusted, its arguments are untrusted, and retrieved content is untrusted. All enforcement happens in your code.
◆ Lock it in
- Treat every tool as an attack surface; grant least privilege.
- Validate/sanitize args server-side; allow-list or gate high-impact actions.
- Model output, tool args, and retrieved content are all untrusted.
Feynman drill — say it out loudExplain why 'the tool executor is the security boundary' and what that means for how you write a delete tool.
Step 1 rate your confidence · Step 2 pick your answer
What is the safest default posture for an agent's tool permissions?
Step 1 — how sure are you?