Semgrep for coding agents

When a coding agent edits a repository, Semgrep can scan the changed code for patterns covered by security rules. Semgrep reads source files and reports matches, such as calls to risky functions. Each rule describes a code structure to look for, so Semgrep can recognize a pattern in context instead of searching only for a text string. The Semgrep Community Edition documentation describes it as an open source static analysis tool that finds insecure coding patterns and security vulnerabilities in source code.

An agent can run Semgrep after making a change and use each finding to guide a review. A finding does not prove that an attacker can exploit the code, and a clean scan does not prove that the code is secure. The example below uses a local rule and a small Python file, so it does not require an account or rules from an online source.

Install the CLI

Semgrep’s quickstart installs the CLI with pipx or uv, two tools that install Python command-line programs in their own environment:

pipx install semgrep
# or
uv tool install semgrep

semgrep --version

The installation command needs access to the package index. The quickstart also lists Homebrew for macOS, but says that formula is maintained on a best-effort basis and often lags behind the latest release. The Semgrep repository lists python3 -m pip install semgrep for Linux and macOS and a Docker image as other options.

A local scan with a rule file does not require Semgrep account credentials. Semgrep also supports scans and reporting through its hosted platform; for CI use, follow the official CI setup documentation. Keep any platform token in an environment variable or another secret store, not in an agent prompt or checked-in file.

Run a local rule

This example asks Semgrep to flag calls to Python’s eval function. It creates two local files: a Python file to scan and a file that tells Semgrep what code to flag.

mkdir -p /tmp/semgrep-agent-demo
cd /tmp/semgrep-agent-demo

cat > example.py <<'PY'
def parse_value(value):
    return eval(value)
PY

cat > semgrep.yml <<'YAML'
rules:
  - id: python-eval-call
    languages:
      - python
    message: Review eval calls because they can execute input as code.
    severity: MEDIUM
    pattern: eval($EXPR)
YAML

semgrep scan --config semgrep.yml example.py

semgrep scan runs the scanner. --config semgrep.yml tells it to use the local rule, and example.py names the file to scan. The rule’s pattern matches a call to eval and records its argument as part of the match; the message tells the reviewer what to examine. MEDIUM is one of the current severity levels in the rule syntax documentation. The older WARNING level still works and maps to MEDIUM. Semgrep’s text report names the matching rule and shows where the match appears in the file. This demonstrates how a rule matches code; it does not test whether the example is exploitable.

For an agent, the JSON report is easier to parse. The CLI reference documents --json for Semgrep’s JSON format and --error to exit with status 1 when there are findings:

semgrep scan --config semgrep.yml --json --error example.py

This command scans the local file with the local rule. Installing Semgrep requires network access, but the example does not fetch rules from Semgrep’s online registry or upload results to its hosted platform. A command such as semgrep scan --config auto uses Semgrep’s registry configuration and makes a network call to get rules. The CLI reference says --config auto uses your project URL to log in to the registry. With the default --metrics=auto, Semgrep sends usage metrics when the config comes from the Semgrep server or when you are logged in. --metrics=off turns them off.

Give the agent a bounded task

An agent can run the same scan after editing a file and report any findings before proposing a patch. A focused prompt might be:

Run semgrep scan --config semgrep.yml example.py. If it reports a finding, explain what code matched and why it deserves review. Do not change the file unless I ask.

For a real repository, point the command at the changed file or directory you want to check, and choose rules that fit the project’s language and risks. Review the rule messages and scope before asking an agent to treat every match as a defect.

Treat findings as review leads

Semgrep checks code against the rules it receives. It does not execute the program to demonstrate how an attacker might reach or exploit a finding. As a result, a match needs human or agent review in context, and a clean scan leaves risks outside the selected rules unexamined. The Semgrep CI documentation describes full and diff-aware scans. A diff-aware scan only reports findings introduced after a baseline, an earlier reference point like a commit or branch. A full scan checks the entire codebase.

For agent-assisted changes, use Semgrep to surface specific patterns and ask the agent to explain each result. Keep tests, code review, and runtime checks in place for behavior that static rules cannot establish.