How do you secure an LLM agent that uses tools and function calling?

An agent is an LLM wired to tools — functions it can call to read email, query databases, hit APIs, run code, or move money. That's where prompt injection stops being a content problem and becomes an action problem. If an attacker can influence the model's input (directly, or indirectly via a retrieved document or web page), they can potentially make it do things. OWASP calls the over-empowered version of this excessive agency.

The threat

Excessive agency has three flavors: too many tools (functionality you don't need), too much permission (a tool with broader scope than the task requires), and too much autonomy (irreversible actions taken without confirmation). Combine any of these with an injection and you get data exfiltration, destructive operations, or lateral movement.

Controls

• Least privilege per tool. Each function gets the narrowest scope, narrowest data access, and shortest-lived credentials possible. Prefer fine-grained tools over a generic "run anything" tool.
• Validate tool arguments. Treat model-generated arguments as untrusted: type-check, allowlist, and bound them server-side before execution.
• Human-in-the-loop for sensitive or irreversible actions (payments, deletes, external sends).
• Sandboxing for any code execution; network egress controls to limit exfiltration and SSRF.
• Budgets and rate limits to cap denial-of-wallet and runaway loops.
• Full audit logging of every tool call with its arguments and the triggering context.

What interviewers look for

A clear chain — injection plus tools equals real actions — naming excessive agency, and a least-privilege, human-in-the-loop, defense-in-depth answer rather than relying on the system prompt to keep the agent in line.