New
Introducing React Bench, see how different models perform on React code
Menu
What Is React Doctor?
Quickstart
Install for Coding Agents
How to Fix Issues
GitHub Actions Setup
Updating CI
Other CI Providers
Migrating to CI v2
Config Files
ESLint & oxlint Plugins
Add Custom Rules
CLI Reference
GitHub Action Reference
Node.js API
Changelog
Modified MIT License
Terms of Service
Privacy Policy
Data Use
Security
Support
Rules reference

react-doctor/agent-tool-capability-risk

An AI agent tool that can reach shell, filesystem, or network primitives lets prompt-injected input trigger those actions, because the model treats tool arguments as trusted.

  • Category: Security
  • Severity: warn
  • Source: oxlint-plugin-react-doctor
  • Framework: global
  • Enabled when: production source files (.js/.ts/.tsx) located under an agents/tools/mcp directory or with an agent/tool/mcp filename; tests/build/docs/generated paths skipped
  • Tags: security-scan
  • Default: Enabled

Validation prompt

Use this to decide whether a fired diagnostic is real or a false positive.

Fires only in a file whose path is under an agents/, tools/, or mcp/ directory (or whose filename contains agent/tool/mcp) that BOTH defines a tool — tool({, createTool(, defineTool(, or new DynamicTool(/new StructuredTool( — AND, anywhere in the same file (comments stripped first), references a dangerous-capability keyword: exec/execSync/spawn/child_process/eval/new Function/vm.run/readFile/writeFile/fs.read/fs.write/fetch/axios/http.request/sandbox/runCode/executeCode. FALSE POSITIVE to suppress: the dangerous keyword lives in unrelated code in the same file and is not actually wired into the tool's handler, or the tool already validates/allowlists its arguments and scopes the capability so prompt-injected input cannot reach the primitive. This is a file-level co-occurrence heuristic, not data-flow, so confirm the capability is reachable from tool input.

Fix prompt

Use this once validation confirms the diagnostic is real.

Treat every tool argument as attacker-controlled. Validate inputs against a strict schema and allowlist commands, paths, and hosts instead of passing free-form strings into exec/spawn/fs/fetch; never use shell: true or build shell commands by concatenation. Scope each capability to the minimum it needs (sandbox, read-only filesystem, egress allowlist), and prefer purpose-built operations over raw shell, filesystem, or network access.

More Security rules from the rules reference:

  • react-doctor/artifact-baas-authority-surface: Shipping Firebase/Supabase client config with your collection and authorization-field names in a browser bundle hands attackers a map of your data model, which is dangerous when server-side rules do not enforce access.
  • react-doctor/artifact-env-leak: A real secret shipped in a browser bundle under a public env prefix (`NEXT_PUBLIC_`, `VITE_`, `REACT_APP_`, `EXPO_PUBLIC_`) is world-readable and must be treated as compromised.
  • react-doctor/artifact-secret-leak: A live credential (API key, token, or connection string) sits in a browser bundle or static asset, so anyone can read it, and it must be treated as compromised.
  • react-doctor/auth-token-in-web-storage: Auth token in web storage
  • react-doctor/build-pipeline-secret-boundary: Installing dependencies while CI secrets are in the environment lets a malicious package's lifecycle script read those secrets, which risks supply-chain compromise.