audit-agent-code

Audit the agent's code · framework appsec

The companion to redteam-an-agent. That skill breaks the running agent through the model. This one breaks it through its own source code — the classic appsec layer the model's judgment never touches.

Written from real engagements: two well-defended agents whose LLM refused every prompt-injection attempt were broken here instead — one by an unauthenticated path traversal in a channel's file handler, one by a fail-open sandbox. The model can't defend a code path it never sees.

Why this layer

Flagship agents increasingly harden the LLM layer: they refuse injected commands, resist memory poisoning, even decode obfuscated payloads to inspect them. Good. But the code around the model — the channel that parses an inbound message, the handler that saves an attachment, the loader that reads config/skills, the toggle that turns the sandbox on — is ordinary software, and it is frequently not hardened. An attacker who reaches those paths bypasses the model entirely. Audit them like you'd audit any web app.

Authorization & safety

Follow every rule in ../README.md: authorized target, disposable environment, harmless proof, responsible disclosure. Reading source is safe; never run untrusted target code on a machine you care about.

The untrusted-input boundaries (where to look)

Trace every place external, attacker-influenced data enters, and follow it to a dangerous sink:

• Channel / message handlers — attachment filename → file write (path traversal); sender_id → path; message body → any sink. These run on every inbound message, often before auth.
• File / media / download tools — path built from untrusted input; write/read outside the intended dir; symlink following.
• Config / skill / MCP / plugin loaders — untrusted content → deserialization (pickle, yaml.load, eval), dynamic import, or a path.
• The security controls themselves — the sandbox toggle, the guard, the auth gate. Audit the control, not just the happy path.