Before you run the code your AI agent wrote, check these five things

A developer published a five-point checklist for reviewing AI-agent-generated code before running it, covering hallucinated package names, unreviewed install scripts, agent hooks and MCP configs, hardcoded keys and unsafe eval, and SSRF in agent-written URL features. The same author released two open-source MIT-licensed tools, am-i-hacked and secure-semgrep, which scan projects for malicious code and AI-agent-specific risks and exit non-zero on findings for CI use.

Coding agents are good enough that it's tempting to accept the diff, run npm install , and start the dev server. Most of the time that's fine. The problem is the time it isn't, because an agent has your permissions and reads text you never saw. These are the five places I look before running anything an agent produced. Assistants sometimes suggest package names that don't exist, or that are one letter off a real one. Attackers register those names. For every new entry in package.json or requirements.txt , check that it's the package you meant and that it has a real history. Advisory scanners npm audit , OSV-Scanner are still worth running, but they only know about reported problems. A brand-new malicious package has no advisory yet. curl ... | sh , a new postinstall script, an editor task. An agent that browses can repeat whatever an untrusted page told it to run. Read every script entry the agent added or changed. Agent hooks, MCP server definitions, .claude/settings.json , .mcp.json , .vscode/tasks.json , .config.js . All of these start processes, and none of them look like "code" in a diff review. Hardcoded API keys. Model output passed to exec or eval . User input concatenated into a system prompt. No max tokens . Agents write this code readily because it's all over their training data. If the agent wrote a link preview, a webhook, or an "import from URL" feature, check whether it validates where the URL points. Otherwise someone can aim your server at 169.254.169.254 and read your cloud credentials. That's SSRF. I maintain two open-source tools for this. Both run with npx and need no account. am-i-hacked https://isaacbell.github.io/secure-devtools/tools/am-i-hacked/ reads the project for signs of malicious code: auto-run editor tasks, install scripts that download or decode things, obfuscated payloads, executables disguised as assets, capture code paired with an exfiltration endpoint, and the project's own AI-tool config. npx am-i-hacked Put it in front of your dev server so it runs every time: { "scripts": { "dev": "am-i-hacked && next dev" } secure-semgrep https://isaacbell.github.io/secure-devtools/tools/secure-semgrep/ runs Semgrep with bundled rules for AI-agent code: hardcoded provider keys, model output to exec, user input in system prompts, MCP command injection and tool poisoning, risky agent hooks, prompt injection in SKILL.md files. It also adds Semgrep's own security packs for your stack. It needs semgrep installed. npx secure-semgrep -L ts -L node . npx secure-semgrep -L ssrf . opt-in SSRF rules Both exit 1 on findings, so they drop into CI. Neither tool knows what you asked the agent to do. A scan finds known patterns; it doesn't prove the code is correct or safe. Neither scans installed node modules . Neither is antivirus. They're a first pass that tells you where to look, and reading the diff is still the check that matters. The full guide, including a table of what the AI rules cover, is here: Is AI-generated code safe to run? How to check it first https://isaacbell.github.io/secure-devtools/guides/ai-generated-code-security/ . Everything is MIT licensed: github.com/IsaacBell/secure-devtools https://github.com/IsaacBell/secure-devtools .