AI Security Testing: Four Tools That Can Review Your Code

A feature can work perfectly in a demo and still expose another customer’s data. The page loads, the request succeeds, and the tests pass. The problem appears when someone changes an identifier and the application returns information they should never have been allowed to read.

That is the kind of question a security review needs to investigate: what can someone make this application do beyond its intended use?

The four tools

Anthropic, OpenAI, Cloudflare, and Google now offer tools or reusable workflows that help coding agents investigate those questions. Their documented capabilities include examining application structure, tracing suspicious code paths, checking findings, and, in some cases, proposing fixes. They come in different forms:

Tool	How you use it	A reason to consider it
Claude Security	A plugin inside Claude Code	Review code and request patch files within an existing Claude Code session
Codex Security	A plugin, standalone CLI, SDK, or cloud workflow	Choose an interactive review or integrate scans into development tooling
Cloudflare’s security-audit skill	A workflow installed into a compatible coding agent	Use a structured audit with separate discovery and verification work
Google Mantis	Skills and a configurable reference harness	Customize a research pipeline that can investigate and patch vulnerabilities

For a small team, these tools offer another opportunity to examine code before a release. Their value depends on the quality of the evidence they produce and what happens after someone reads the report.

The setup details below were checked against official documentation on October 22, 2026.

Claude Security

Claude Security brings a coordinated security review into Claude Code. Its agents examine architecture, identify threats, investigate code, and independently check candidate findings. You can review a repository, a narrower scope, or code changes.

With Claude Code open in your repository, enter:

/plugin install claude-security@claude-plugins-official
/reload-plugins
/claude-security

If the marketplace is missing, first run:

/plugin marketplace add anthropics/claude-plugins-official

The menu lets you choose a scan or request patches for findings. Suggested fixes arrive as patch files for review and application. The patch workflow can also report that it could not produce a sufficiently supported fix.

The plugin uses the permissions of its Claude Code session and adds no isolation. Anthropic recommends sandboxing the whole session when inspecting an unfamiliar or untrusted repository. Claude Security’s installation, permissions, and patch workflow.

Codex Security

Codex Security offers several ways to fit a review into your workflow. OpenAI recommends its plugin for a first local scan. In the ChatGPT desktop app, open Codex, install Codex Security, and open Security in the sidebar. A separate cloud offering handles connected GitHub repositories; the standalone CLI is useful for terminal workflows and automation. OpenAI’s Codex Security overview.

For the CLI, the current prerequisites are Node.js 24 or 26, or Node.js 22 starting at 22.13.0, plus Python 3.10 or later. Python 3.10 also needs tomli. Scans using OpenAI inference require Codex Security access; some full-repository scans may require Trusted Access for Cyber.

From the repository you want to review, check the package and sign in:

npx @openai/codex-security --version
npx @openai/codex-security login

Then run a scan, choosing a new, private results directory outside the repository:

npx @openai/codex-security scan . --auth chatgpt --output-dir ../codex-security-results

Replace the output path as needed. The report includes findings and coverage information; inspect both. Codex Security CLI quickstart.

The CLI also supports validation and patch commands. Its scans run with local operating-system permissions and do not pause for interactive approval. Processes can inherit environment variables, so remove unrelated credentials before starting. CLI commands and local scan permissions.

For automation, a successful exit alone needs careful interpretation: coverage gaps do not change a completed scan’s exit code, and a finding only fails the scan when it meets a configured severity policy. Configure that policy before using the result as a release check. CLI exit codes.

Cloudflare’s security-audit skill

Cloudflare’s security-audit skill supplies a method for a compatible coding agent. Its six phases cover reconnaissance, hunting, candidate validation, structured records, independent record verification, and reporting.

Install it with:

npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit

Start your agent in the target codebase and ask:

security audit this codebase

A candidate goes to a fresh verifier whose job is to challenge it. The records distinguish confirmed findings, unresolved leads that need validation, and rejected candidates. The audit also keeps a coverage ledger, making it possible to inspect what was examined and what remains.

The complete workflow requires a tool-using model, parallel sub-agents, Node.js for validators, and an OS-enforced sandbox for executing target-controlled code. Without the required isolation, execution-dependent leads stay unresolved.

This makes the skill worth considering when you want to inspect and adapt the audit procedure itself. Installation supplies instructions; the host agent and environment supply the capabilities needed to follow them. Cloudflare’s workflow, installation, and requirements.

Google Mantis

Google Mantis provides skills and a reference harness for vulnerability research. Its documented pipeline includes threat modeling, investigation, reproduction attempts, patching, and an adversarial review of fixes.

Google explicitly requires an isolated, restricted environment without access to production systems, sensitive data, or internal networks. The harness can generate and execute code.

Inside such an environment, with Git and the Python virtual-environment prerequisites available, the Linux shell setup begins with:

git clone https://github.com/google/mantis.git
cd mantis/reference
./install.sh
python3 scripts/configure.py --interactive
python3 scripts/configure.py --test --probe
./run.sh /path/to/your/repository

Configure the model provider and its authentication before launching; replace the final path with the code you intend to examine. The repository documents provider-specific setup.

A patch surviving Mantis’s adversarial loop is useful evidence to inspect. Google still requires expert verification of findings. Its current README also warns that the pull request scanning action has not been tested end to end against a live project and should not gate merges. Mantis setup, capabilities, and limitations.

What a finding establishes

The common challenge across these tools is deciding what a finding actually establishes.

Consider the customer-data example. A useful report should identify the request an attacker controls, the code that loads the record, the missing ownership check, and the conditions under which another customer’s information becomes accessible. A finding that merely says “possible authorization issue” leaves the central question unanswered.

A demonstration needs the same scrutiny: whether it exercises the original application, uses the permissions an attacker would have, and shows the claimed consequence. Cloudflare describes failures in which agents modify source to make a demonstration work or produce tests that establish something trivial. A working test can still support the wrong claim. Cloudflare’s experience validating findings.

Source analysis and runtime reproduction provide different evidence. Reading the code may establish an unsafe path; executing a suitable test may demonstrate its effect under particular conditions. A failed reproduction can also reflect a broken test environment. OpenAI’s guidance advises reading the evidence and unresolved prerequisites attached to each finding. Codex Security’s validation guidance.

How I would run one

For my own projects, I would make these reviews part of a short, repeatable process:

1. Describe the application and the intended scope. Explain who can use it, what data belongs to each user, which components are exposed, and which security rules matter. Record the commit being reviewed.
2. Start with a meaningful target. A new authentication flow, upload handler, or customer-data endpoint gives the review a concrete purpose. Include enough surrounding code to trace how the feature behaves.
3. Read coverage alongside findings. Check exclusions, unfinished work, and assumptions before deciding what confidence the scan adds.
4. Investigate the strongest findings. Verify the affected code and attacker prerequisites. Keep uncertain leads visible until the missing facts are resolved.
5. Review the patch and preserve a regression check. For the customer-data example, verify that the owner can still retrieve the record and another user cannot. Rerun the relevant checks after applying the fix.

Treat a proposed patch as a code change requiring review. Check that it addresses the cause, preserves intended behavior, and does not simply make the demonstration stop working.

Keep dependency scanning, secret detection, conventional static analysis, and human review in the process. Anthropic explicitly describes Claude Security as complementary to those practices. A report with no findings also has limits: OpenAI warns that a completed scan can still miss vulnerabilities. Anthropic’s review guidance, OpenAI’s guidance on empty results.

My starting point would be the tool that fits the development environment I already use, applied to a feature whose security rules I can explain. From there, I would judge the result by whether it helped me understand an exposure, confirm it, and verify the fix.

For an application handling user data, that creates a concrete goal before release: know what was reviewed, resolve the supported findings, and keep a record of the questions that remain.