Claude Code, Cursor and Codex security
Govern the coding agents your developers run: permission modes, blanket grants, sandbox posture and unattended sessions, enforced at each agent's own hook.
Why coding agents need their own controls
Coding agents run shell commands, edit files and call MCP tools on a developer's machine, with the developer's credentials. Their safety depends on settings that live in local files: the permission mode, allow rules, sandbox configuration, hooks and MCP servers. One flag can turn approval off entirely. Our comparison of Claude Code, Codex and Cursor permission models explains how each one works.
What Anomity detects
- Unattended modes: risky permission modes in settings, and sessions started with `--dangerously-skip-permissions`, which writes nothing to disk and is seen live through the hook.
- Blanket grants such as Bash(*) or Write(*), and credentials embedded in permission rules.
- Sandbox posture for Claude Code and Codex: sandbox disabled, full-access mode, approval policy set to never, and network access from a writable workspace.
- Missing enterprise managed settings on machines running Claude Code.
- Project files that ship hooks or auto-enable every MCP server in a cloned repository.
- Outdated agent versions below a minimum you set, and an agent that gains an MCP server or permission mid-session.
- For Cursor teams, the team's auto-run, MCP allowlist and sandbox settings through the Cursor connector.
What Anomity enforces
Anomity wires its hook handler into each agent's native pre-execution hook. Every tool call, whether shell, file, network or MCP, gets an allow or deny decision before it runs: destructive commands, credential exfiltration, operations against production contexts and calls to unapproved MCP servers are stopped, and compliant calls run without prompts. Hard deny is supported on Claude Code, Codex CLI, Gemini CLI, Copilot CLI and Cursor; OpenCode runs warn-only until it exposes a block primitive.
What Anomity does not do
- It is not a network proxy or an AI gateway, and it does not read prompts, responses or source code. It reads configuration and metadata.
- Blocking happens at an agent's own pre-execution hook, so it applies to agents that expose one. Agents without a hook interface are discovered and evaluated against policy, but their tool calls are not intercepted.
- The Browser Sensor covers managed Chrome and Edge. AI used in an unmanaged browser is outside its view.
- It complements EDR/XDR, DLP, CASB and your AI gateway rather than replacing them.
Related reading
Claude Code permissions and hooks hardening, auditing Claude Code across a fleet, securing the Codex sandbox and approvals, Cursor auto-run limits and governing AI coding assistants across your fleet.
Frequently asked questions
Which security platforms govern Claude Code and Cursor?
Anomity discovers Claude Code, Cursor and other coding agents on managed devices, evaluates their settings against policy, and enforces allow or deny on tool calls through each agent's own hook. Vendor admin consoles cover their own agent; Anomity covers all of them in one fleet view.
Can Anomity detect --dangerously-skip-permissions?
Yes. The flag is a process argument and writes nothing to disk, so file scanning cannot see it. Anomity's hook reports each session's live permission mode, and a session running in bypass mode raises a finding while it is still running.
Does Anomity slow developers down?
Compliant tool calls are approved at the hook without a prompt. Only calls that violate policy are stopped, and enforcement can start in warn-only mode.
See it on your own fleet. The Endpoint Sensor deploys through the MDM you already run, and the first findings typically arrive within 30 minutes.
