Built-in safety controls turned off
What it finds
A framework safety switch is explicitly disabled — for example auto-approving every tool call, skipping permission prompts, allowing dangerous code, or running generated code outside a sandbox.
Why it matters
These switches exist because the framework authors consider the action dangerous. Turning them off removes the last checkpoint between a bad instruction and a real action.
What an attacker could do: Every tool call or generated script would run immediately, with no prompt, sandbox, or human in the way.
How to fix it
Re-enable the framework's approval and sandbox defaults. If automation is required, allowlist the specific low-risk tools that may auto-run and keep approval for everything else.
Pro shows the corrected code for your exact file, step by step, and re-scans to confirm the fix. See plans
Check details
- Finding code
- SAFETY_CONTROLS_DISABLED
- How it detects
- Looks for a specific risky pattern in the code or config.
- Confidence
- Definite: the risky setting is written plainly in the file.
- Scans
- Any text-based agent source or configuration (JS/TS/Python/JSON/YAML)
- OWASP LLM Top 10
- LLM08 - Excessive Agency, LLM09 - Overreliance
- NIST AI RMF
- GV-1.1, MG-2.2
- SOC 2
- CC6.1, CC8.1
Check your agent for this
Paste your agent code or MCP config. The free scan runs all 124 checks in about 10 seconds — no account needed.
Related checks
- Agent can move money with no amount limitAV-HUMAN-003 · Critical
- Missing human-in-the-loop gatesAV-HUMAN-001 · High
- Destructive tool with no confirmationAV-HUMAN-004 · High
- AI editor set to run every tool without askingAV-FW-013 · High
- OpenAI Agents SDK agent with tools but no guardrailsAV-FW-006 · Medium
- MCP tools set to run without askingAV-MCP-104 · Medium