Agent tools are powerful. That's exactly why they need sandboxes.

A customer asked me: 'We built an agent that writes and executes code. The demo wowed investors. Should we put it in front of users?' My answer was no. Tools transform agents from chat interfaces into software that reads, writes, searches, and triggers workflows. The same power makes them dangerous. A production agent tool system needs five layers of defense.

5 layers of defense

1. Schema validation: Validate tool inputs with typed schemas (Zod, JSON Schema). Reject invalid calls with clear errors so the model can self-correct.
2. Secret isolation: Reference secrets by ID, inject at execution time. The model should know a tool exists, never see the credentials that power it.
3. Runtime limits: CPU cap (30s), memory cap (256MB), no network egress, read-only fs except /tmp, no process spawning, no host fs access.
4. Audit logging: Log every tool call with agent ID, tool name, redacted params, output summary, duration, and status. Essential for incident investigation.
5. Approval gates: Classify tools by risk level. High-risk operations (send email, modify data, make payments) require human approval before execution.

Updated: May 22, 2026