Security Operations with AI

Snyk just flagged 14 “critical” CVEs in your dependency tree. Eleven are in dev-only packages that never ship, two are unreachable from any code path you actually call, and the one that matters is buried at the bottom of the report. Your release is blocked while you triage by hand, again. The promise of “AI security” is rarely a new scanner — it is an assistant that reads the scanner output the way a senior engineer would: separating real exploitable findings from noise, and turning the real ones into reviewed pull requests instead of a 200-line JSON dump nobody opens.

This guide builds that loop with tools that exist today — Semgrep, npm audit, detect-secrets, Trivy, and the GitHub MCP server — driven from Cursor, Claude Code, or Codex.

What you’ll walk away with

• A triage prompt that turns a raw semgrep --config=auto dump into ranked, exploitable-vs-false-positive findings with minimal patches
• A dependency-CVE prompt that reads npm audit --json and tells you which CVEs are actually reachable in your code
• A secret-rotation prompt for when detect-secrets finds a live credential in history
• The per-tool mechanics for running this loop in Cursor (agent mode + MCP), Claude Code (headless -p in CI + hooks), and Codex (cloud automation + GitHub)
• A CI job that runs the scan-and-triage step on every PR and fails on genuinely new high-severity findings

The workflow: scan, triage, remediate

The mistake most teams make is wiring AI to replace the scanner. The scanner (Semgrep, CodeQL, Trivy) is deterministic, fast, and auditable — keep it. The AI’s job is the expensive part a human currently does: reading the findings, ruling out false positives, and proposing the smallest correct fix. The loop is three steps.

1. Run the deterministic scanners and capture machine-readable output. These are real commands, not prompts — paste them into a terminal:

   # Static analysis (registry rules)
   semgrep --config=auto --json --output semgrep.json .
   
   # Dependency CVEs
   npm audit --json > audit.json
   
   # Secrets in working tree + history
   detect-secrets scan --all-files > secrets.json
   
   # Container image (if you ship one)
   trivy image --format json --output trivy.json myapp:latest

   semgrep installs via pip install semgrep or brew install semgrep; detect-secrets via pip install detect-secrets; trivy via brew install trivy or its install script. None of these are npm packages — do not npm install them.

2. Hand the output to the AI for triage. This is where the value is. The scanner says “potential SQL injection at db.ts:42”; the assistant tells you whether db.ts:42 is reachable from untrusted input or is a parameterized query the rule mis-flagged. Use the triage prompt below.

3. Turn the real findings into a reviewed PR — never an auto-merged one. Let the AI draft the patch and the PR body, but a human (or a required CI gate) approves it. Auto-applying AI patches to a security-sensitive file is how you ship a regression with a green checkmark.

The mechanics of steps 2 and 3 differ per tool. The scanner commands in step 1 are identical everywhere.

Cursor

Open the repo in Cursor, run the scanners so semgrep.json / audit.json exist in the workspace, then drop into Agent mode (Cmd/Ctrl+I). Agent mode can read the JSON files directly and edit the flagged source files in place, showing each change as a checkpoint you accept or reject.

Add the GitHub MCP server so the agent can open the remediation PR without leaving the editor. In Cursor’s MCP settings (or .cursor/mcp.json), register the official remote server:

{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": { "Authorization": "Bearer ${GITHUB_PAT}" }
    }
  }
}

Now the agent reads semgrep.json, patches the two real findings, and calls the GitHub MCP create_pull_request tool — all from one prompt.

Claude Code

Claude Code shines for the headless, in-CI half of this loop. Run the scanners, then pipe the triage prompt through -p (print mode) with the JSON on disk:

semgrep --config=auto --json --output semgrep.json .
claude -p "Read semgrep.json. For each finding, classify exploitable vs \
  false-positive and output JSON: {file, line, verdict, reason, patch}. \
  Treat anything under test/ or scripts/ as non-shipping." \
  --allowedTools "Read,Grep" --output-format json > triage.json

Add the GitHub MCP server with the documented HTTP transport so Claude Code can open the PR locally or in CI:

claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \
  --header "Authorization: Bearer ${GITHUB_PAT}"

A PreToolUse hook is the right place to enforce the “no auto-merge of security fixes” rule — block any Bash(gh pr merge*) on a branch named security-* and require human review.

Codex

Codex (GPT-5.5 across App/CLI/IDE/Cloud) is strongest for the scheduled, hands-off variant. Run the triage from the CLI against captured output:

semgrep --config=auto --json --output semgrep.json .
codex exec "Read semgrep.json and rank findings by real exploitability; \
  propose a minimal patch for each genuinely exploitable one." \
  --ask-for-approval on-request

For the recurring scan, use Codex Cloud with its GitHub integration: point a Cloud task at the repo on a schedule, let it run the scanners and triage, and have it open the remediation PR through the connected GitHub app. Keep --ask-for-approval on-request (not never) so a destructive remediation still pauses for a human.

Copy-paste prompts

These are the recipes. They assume you have already captured the scanner JSON as described above.

Tip

Semgrep triage — separate exploitable from false-positive:

Here is semgrep.json from `semgrep --config=auto`. For EACH finding:
1. Classify it as EXPLOITABLE, FALSE_POSITIVE, or NEEDS_REVIEW. Treat any
   path under test/, tests/, scripts/, or *.spec.* as non-shipping code that
   cannot be a production vulnerability on its own.
2. For EXPLOITABLE findings, trace whether the tainted value reaches the sink
   from untrusted input (request body, query param, env, file). If it can't,
   downgrade to FALSE_POSITIVE and say why.
3. Propose the smallest patch that fixes each EXPLOITABLE finding without
   changing behavior — parameterized query, output encoding, auth check.
4. Rank the EXPLOITABLE findings by real risk (reachability x impact).

Output a markdown table: file:line | rule | verdict | reason | patch summary.
Do NOT include FALSE_POSITIVE findings in the patch set.

Tip

Dependency CVE triage — is it actually reachable?

Here is audit.json from `npm audit --json`. For each advisory:
1. State whether the vulnerable package is a direct or transitive dependency,
   and whether it's in dependencies or devDependencies.
2. Search the codebase for actual call sites of the vulnerable API surface
   (not just the package import). A CVE in a function we never call is not a
   production risk — say so explicitly.
3. For real, reachable CVEs: give the exact `npm install pkg@version` or
   `overrides` entry that resolves it, and flag any breaking-change risk.
4. Produce two lists: "Fix now" (reachable, shipping) and "Backlog"
   (dev-only or unreachable), with one-line justification each.

Tip

Secret found in history — rotate, don’t just delete:

detect-secrets flagged a live <TYPE> credential at <FILE>:<LINE>, committed in
<COMMIT>. Walk me through remediation in order, with exact commands:
1. Rotate the credential at the provider FIRST (assume the committed value is
   already compromised — deleting the line does not un-leak it).
2. Replace the hardcoded value with an env var / secret-manager reference and
   show the minimal code diff.
3. Purge it from git history (git filter-repo or BFG) and note the
   force-push + team re-clone consequences.
4. Add a detect-secrets pre-commit hook config so this class of leak is
   caught before the next commit.

Note

Why a guard prompt belongs in the loop: before applying any AI-proposed security patch, ask “Does this change alter behavior for legitimate inputs, and does it close the specific vector the scanner flagged — not a different one?” A patch that fixes nothing but turns the finding green is worse than no patch, because the next scan stays quiet while the hole stays open.

MCP servers and skills for this loop

Two extensibility options change this workflow, and they are not interchangeable.

• GitHub MCP server (github/github-mcp-server, remote at https://api.githubcopilot.com/mcp/) is the persistent connection: it lets the agent search code across the org, read Dependabot/secret-scanning alerts, and open the remediation PR. Use it when the agent needs to act on GitHub repeatedly. There is no @anthropic/* or one-string new MCPClient('github') convenience layer — MCP is connect(transport) then callTool({ name, arguments }). If you script directly against the SDK, the package is @modelcontextprotocol/sdk and the client lives at @modelcontextprotocol/sdk/client/index.js.
• The Semgrep skill (semgrep/skills, installable with npx skills add semgrep/skills) is the lighter-weight option: it teaches the agent to write custom Semgrep rules for your codebase and run scans, without standing up a server. Reach for the skill when the job is “author and run rules”; reach for the MCP server when the job is “operate on GitHub.”

Note

Rule of thumb: a skill augments how the agent does one thing (writing Semgrep rules); an MCP server gives it a durable connection to a system it keeps querying and changing (GitHub). When both exist, the skill is faster to install and the server is deeper.

Hardening the cluster (current Kubernetes)

If you ship to Kubernetes, the AI can draft your admission policy — but it must draft the current one. PodSecurityPolicy (policy/v1beta1) was removed in Kubernetes 1.25 and does not exist on any supported cluster. The supported successor is Pod Security Admission via namespace labels, paired with a NetworkPolicy for traffic isolation.

# namespace with Pod Security Standards enforced (replaces PodSecurityPolicy)
apiVersion: v1
kind: Namespace
metadata:
  name: payments
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/warn: restricted
---
# default-deny egress/ingress, then allow only what's needed
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: payments-isolation
  namespace: payments
spec:
  podSelector:
    matchLabels:
      app: payments-api
  policyTypes: [Ingress, Egress]
  ingress:
    - from:
        - podSelector:
            matchLabels: { app: api-gateway }
      ports:
        - { protocol: TCP, port: 8443 }
  egress:
    - to:
        - podSelector:
            matchLabels: { app: postgres }
      ports:
        - { protocol: TCP, port: 5432 }

Tip

Generate a current admission policy:

Generate Kubernetes manifests to harden the `payments` namespace for a 1.30
cluster. Use Pod Security Admission labels (enforce: restricted) — NOT
PodSecurityPolicy, which is removed. Add a default-deny NetworkPolicy that
only allows ingress from app=api-gateway on 8443 and egress to app=postgres
on 5432. Explain any workload change the restricted profile forces (no root,
no privilege escalation, read-only root FS).

Wiring it into CI

Run the deterministic scanners on every PR, then run the AI triage as an advisory step. The hard gate stays deterministic — the pipeline fails on genuinely new high-severity findings from Semgrep/Trivy, not on the AI’s opinion. Note actions/checkout@v5 (Node 24; v3 runners are end-of-life as of June 2026).

.github/workflows/security-scan.yml

name: Security Scan
on:
  pull_request:
  schedule:
    - cron: '0 */6 * * *'

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5

      - name: Semgrep (hard gate on new high-severity)
        uses: semgrep/semgrep-action@v1
        with:
          config: auto

      - name: Dependency audit
        run: npm audit --audit-level=high

      - name: Secret scan
        run: |
          pipx install detect-secrets
          detect-secrets scan --all-files | tee secrets.json

      # Advisory: AI triage summary posted to the PR, not a blocker
      - name: AI triage (advisory)
        if: github.event_name == 'pull_request'
        run: |
          semgrep --config=auto --json --output semgrep.json . || true
          claude -p "Summarize semgrep.json: rank exploitable findings, list \
            likely false positives, suggest the smallest fix for each real one." \
            --allowedTools "Read,Grep" --output-format json > triage.json
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}

When this breaks

Caution

semgrep --config=auto floods you with false positives. The auto ruleset is broad on purpose. Pin to focused rulesets for your stack (--config=p/owasp-top-ten --config=p/javascript) and feed the AI the project context (“this is an Express API; req.params is the only untrusted source”) so it can downgrade noise correctly. Do not let the volume push you toward auto-applying patches.

Caution

The GitHub MCP server rate-limits or 403s on large orgs. Code search across a big org hits GitHub’s secondary rate limits, and a fine-grained PAT may lack security_events scope so Dependabot/secret-scanning reads return empty. Scope the agent to one repo at a time, and grant the PAT explicit repo + security_events access before blaming the prompt.

Caution

An auto-applied AI patch breaks the build or fixes the wrong vector. This is why step 3 forbids auto-merge on security branches. If you must automate, gate it: require the full test suite plus a re-scan that confirms the specific finding is gone, and keep a human approval on security-* branches (a Claude Code PreToolUse hook or a GitHub branch-protection rule).

Caution

The “ai_classify_pii()” trap. SQL functions like ai_classify_pii() or ai_sensitivity_score() do not exist in Postgres or any standard database. PII classification happens in application code calling a real model API, or via a dedicated scanner — not as inline SQL. If a generated query calls a function the database doesn’t have, the AI hallucinated it; ask it to rewrite using information_schema plus an out-of-band classification step.

What’s next

Compliance Automation with AI Turn SOC2 / GDPR evidence collection and audit prep into a repeatable AI-driven workflow.

Security & Compliance for Enterprises Org-wide secret management, Semgrep tokens, and policy enforcement at scale.

Cost Optimization with AI Keep the scan-and-triage loop cheap by routing models and capping token spend per workflow.

CI/CD Pipelines The full pipeline these security gates plug into, across Cursor, Claude Code, and Codex.