Build a Basic AI Agent From Scratch: Security and Controls (Part III)

Reaching the final part of our Build a Basic AI Agent from scratch series, we complete the mission of securing our agent. In previous segments, we began closing gaps left by human-in-the-loop controls by introducing a Docker sandbox to contain runaway commands, prompt-injection defenses to stop models from trusting tool outputs blindly, and schema validation. In this installment, we finalize the security hardening by introducing path scoping, shell command restrictions, server-side request forgery (SSRF) guards, resource and cost limits, environment secret scrubbing, audit logging, and a kill switch.

Previously, check_permission was a single function handling mode-based decisions where read and planning tools were always allowed, and write tools were permitted within the working directory during acceptEdits. We have now introduced a policy gate running strictly before the mode-based decision. This gate consists of three layers: path scope checking, shell policy enforcement, and web/SSRF policy validation. A failure at any of these layers results in a hard block that no permission mode can override.

Path scoping has been generalized beyond just write tools to encompass every tool utilizing paths, such as read_file, glob_files, grep, write_file, and edit_file. Each path argument is resolved—handling relative paths, symlinks, and directory traversals—and rejected outright if it escapes the designated working directory. Meanwhile, run_bash remains the most dangerous tool, receiving its own specialized screening against a regex denylist of dangerous binaries including docker, sudo, su, nc, netcat, curl, wget, chmod, and various system service controls.

Stock photo for illustration only, not from the actual event