Is your agent's grep tool a shell command?

When you give an LLM a tool, you hand it a real function and let it choose the arguments. Those tools are everything your agent can do to a real system: read a file, write to your database, send an email, run a shell command, delete data. They are your risk surface, and most teams have never looked at it in one place.

So we did. We ran scan across a batch of popular open-source TypeScript AI agents. A few of the things it found, none of them exotic:

• A coding agent whose grep and glob tools, which sound read-only, actually shell out through execSync. Its bash tool passes a model-chosen string straight to spawn. Arbitrary command execution, behind three innocuous names.
• A query tool that fires an HTTP DELETE. A "query" that deletes.
• A calculator that runs eval on whatever the model types, in a widely-used agent framework. Arbitrary code execution behind the friendliest name in the box.
• A send-email tool that posts to an array of recipients, so the model chooses who gets mailed.
• The single most common finding, in almost every agent we scanned: a fetch tool aimed at whatever URL the model supplies. That is a door to your internal network (an SSRF surface).

Notice the pattern. The dangerous tools are not named dangerous. They are named grep, query, calculator. A name is a claim. The code is the evidence.

See your own agent's tools

scan reads that evidence. One command, no install, no signup, no code change:

npx @agentx-core/scan .

It lists every tool the model can call and ranks each one by what it can do, from read-only up to destructive:

🔍 AGENTX SCAN        (TypeScript · 3 files · 5 tools)
===========================================================================

  RISK   TOOL                GUARD TARGET   WHY
  ----   ----                ------------   ---
  high   calculator          yes            calls `eval`
         lib/tools/compute.ts:4
  high   grep                yes            calls `execSync`
         lib/tools/system.ts:8
  med    sendEmail           yes            calls `mailer.send`
         lib/tools/io.ts:5
  med    fetchUrl            yes            makes an outbound request to an agent-controlled host via `fetch` (SSRF surface)
         lib/tools/io.ts:11

  2 of 5 tools can take destructive or batch actions.
  Nothing here is guarding them: no AgentX in this project's dependencies.

Every ranking carries its evidence, so you can check it instead of trusting it. Scan reads the tool's body, not its name: a tool called tidyUp that deletes files ranks high, and a scary-sounding tool whose code is actually clean goes to "review," not the top. When it cannot tell, it says so. On one agent, all 32 tools came back "nothing here to guard" because they run elsewhere, and scan said exactly that instead of inventing risk.

What it does not do

It does not run your code, and it does not decide whether a tool is exploitable. It sorts an inventory so the dangerous end is the first thing you see. Expect roughly a third of a real codebase to land in "review." That is the honest cost of not guessing.

Guarding what it finds

Scan reports. It does not change your code. To actually guard what it finds, put the AgentX gateway in front of your agent, or wrap your MCP server in one line. Both are language-agnostic, so there is no SDK to adopt.

It covers TypeScript agents built on the Vercel AI SDK today. Python agent? The scanner is TypeScript for now, but the guard it points to, the gateway and the MCP wrapper, is language-agnostic. Run it on yours:

npx @agentx-core/scan .

This matters more as models get better, not less. A more capable agent does more with an unguarded tool.

Try it

• Run it on your own agent: npx @agentx-core/scan .
• Guard what it finds: the gateway
• Wrap an MCP server in one line: agentx-mcp
• Watch a catch-and-recover live: Playground
• Tell us what it caught, or what it missed: Discord