Security Operations Automation

Security operations automation pairs deterministic scanners — Semgrep, npm audit, detect-secrets, Trivy — with an AI agent in Cursor, Claude Code, or Codex that reads their output, separates exploitable findings from false positives, opens the fix as a reviewed pull request, gates CI on fixable HIGH and CRITICAL vulnerabilities, and drafts SOC 2 and GDPR evidence citing real artifacts.

Your scanner just flagged 412 “critical” findings across 50 container images and 14 dependency CVEs. Eleven of the CVEs are in dev-only packages that never ship, two are unreachable from any code path you call, and the one that matters is buried at the bottom of the report. Meanwhile the on-call channel is on fire and your SOC 2 auditor wants access-review evidence by Friday.

The promise of “AI security” is rarely a new scanner. It is an assistant that reads scanner output the way a senior engineer would — correlating a finding with your code, ruling out what is unreachable, and turning what is left into a reviewed pull request instead of a 200-line JSON dump nobody opens.

What you’ll walk away with on security operations automation

• A triage prompt for each scanner class: Semgrep SAST findings, npm audit CVEs, Trivy container images, and a live secret found in history
• The per-tool mechanics for running the loop in Cursor (agent mode + MCP), Claude Code (headless -p in CI + hooks), and Codex (sandboxed CLI + Cloud automation)
• A CI workflow that runs the scanners as a hard gate and the AI triage as an advisory step, plus a Trivy job that blocks merges on fixable HIGH/CRITICAL
• Verified MCP setups for AWS and Azure security data, the GitHub MCP server for opening remediation PRs, and the one MCP-hygiene scanner you should actually run
• Kubernetes hardening that uses current APIs (Pod Security Admission, not the removed PodSecurityPolicy)
• A clear-eyed failure-mode list so you don’t ship false confidence

The workflow: agent on top of real tools

The mistake most “AI SecOps” writeups make is asking the model to be the scanner. It isn’t. Semgrep, CodeQL, and Trivy are deterministic, fast, and auditable — keep them. 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.

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 --severity HIGH,CRITICAL --format json -o trivy.json myorg/api: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.

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 scanner commands in step 1 are identical everywhere. The mechanics of steps 2 and 3 differ per tool.

Cursor

Run the scanners so semgrep.json / audit.json / trivy.json exist in the workspace, then drop into Agent mode (Cmd/Ctrl+I). Agent mode reads the JSON directly and edits the flagged source files in place, showing each change as a checkpoint you accept or reject. With the @aws-security MCP server connected, add @aws-security to the prompt so it can check whether an affected service is actually internet-exposed.

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. Claude Code can run grep/rg itself to confirm reachability, which makes its prioritization concrete rather than guessed:

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

The same shape works for container findings, where the useful output is a priority ranking rather than a patch set:

claude -p "Read trivy.json (Trivy JSON). For each HIGH/CRITICAL: name the CVE and package, use Grep to check if the vulnerable path is reachable in our source, and assign P0/P1/P2 with a one-line justification. Output a markdown table sorted by priority." --output-format json > container-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.6 Sol across App/CLI/IDE/Cloud) is strongest for the scheduled, hands-off variant, and its sandbox defaults make it a safe place to review each command before it runs:

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 an interactive pass with per-action review, launch codex -a untrusted (it asks before each action) and paste:

Read trivy.json. For each HIGH/CRITICAL finding, check whether the vulnerable
package is actually imported and reachable in this repo, classify it P0/P1/P2
by real exploitability, and propose the smallest dependency bump that resolves
the P0s. Show me the diff before applying anything.

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.

Triage prompts, one per scanner class

These are the recipes. They assume you have already captured the scanner JSON above. Each targets a different input, and the difference matters: Semgrep findings need taint reachability, CVEs need call-site reachability, container findings need exposure, and a leaked secret needs rotation before anything else.

Copy-paste prompt: Semgrep triage, exploitable vs 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.

Copy-paste prompt: 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.

Copy-paste prompt: container image triage from 412 findings to 3

Read trivy.json (Trivy output for our container images) and the codebase. For
each HIGH/CRITICAL finding: (1) state the CVE and affected package; (2) grep
the repo to determine whether the vulnerable code path is actually reachable in
our app, or only present in an unused transitive dependency; (3) check whether
the affected service is internet-exposed; (4) assign a real-world priority
(P0 fix-now / P1 this-sprint / P2 backlog) and justify it in one sentence.
Output a ranked table, most urgent first. Do not just repeat CVSS scores —
tell me what to fix first and why.

Copy-paste prompt: a secret found in history, rotate before you 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.

What good triage output looks like

A real, reachable finding rather than a fabricated one:

P0 — CVE-2026-42945 (nginx, ngx_http_rewrite_module heap overflow, CVSS 9.2). Affected: nginx:1.30.0 base image in 3 services. Reachable: yes — all three use rewrite directives. Internet-exposed: yes (edge ingress). Fix: rebuild on nginx:1.31.0 (or 1.30.1), which ships the patch. Patch within 24h.

That CVE is real (introduced in 2008, disclosed 2026, fixed in nginx 1.31.0 / 1.30.1) — use verifiable findings in security work; never let the agent present an invented CVE number as fact.

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 or 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 }}

For images, the highest-leverage move is a scanner in front of deploys so a fixable critical blocks the merge automatically. Trivy ships a maintained GitHub Action; the agent’s job is to wire it into your pipeline and set the gate correctly.

Copy-paste prompt: add a security gate to the deploy workflow

Add a security gate to our GitHub Actions deploy workflow. Use the
aquasecurity/trivy-action to scan the image we just built. Configure it to FAIL
the job on HIGH or CRITICAL findings with an available fix (ignore-unfixed: true
so we don't block on unfixable noise), upload results as SARIF to the Security
tab, and run before the deploy job. Show the full job YAML and explain the
exit-code and severity settings you chose.

A correct gate looks roughly like this — note that it scans the built image and fails the build, rather than just reporting:

- name: Scan image with Trivy
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: myorg/api:${{ github.sha }}
    severity: HIGH,CRITICAL
    ignore-unfixed: true
    exit-code: '1'        # fail the build on a fixable HIGH/CRITICAL
    format: sarif
    output: trivy.sarif

The pattern generalizes: build-time scanning in CI, continuous registry scanning for images already deployed, and an admission policy at the cluster so a vulnerable image can’t be scheduled even if it slips past CI.

Container and Kubernetes hardening

Real-world container security workflow

The challenge: your team deploys 50+ images weekly. Manual review is a bottleneck; unscanned images are a risk. The fix is layered, automated gates — and an admission policy that uses current Kubernetes APIs.

Use the agent to:

1. Wire Trivy into CI as a blocking gate (prompt above).
2. Enable continuous registry scanning for already-deployed images.
3. Enforce Pod Security Standards at the cluster via Pod Security Admission (the built-in successor to the removed PodSecurityPolicy), or a policy engine like Kyverno / OPA Gatekeeper for richer rules.
4. Audit live workloads against the CIS Kubernetes Benchmark.

PodSecurityPolicy (policy/v1beta1) was removed in Kubernetes 1.25 and does not exist on any supported cluster — any guide still telling you to “implement pod security policies” is out of date. The current built-in mechanism is Pod Security Admission via namespace labels, enforcing the three Pod Security Standards (privileged / baseline / restricted), 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 }

Two prompts cover the two situations you will actually be in. The first is for one namespace whose traffic you already know — it produces manifests you can apply today. The second is the cluster-wide plan, including the RBAC and policy-engine decision the first one skips.

Copy-paste prompt: current admission policy for one namespace

Generate Kubernetes manifests to harden the `payments` namespace for a 1.36
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).

Copy-paste prompt: cluster-wide hardening plan

Harden our EKS cluster (Kubernetes 1.36). Produce, with YAML I can apply:
1. Pod Security Admission labels enforcing the `restricted` standard on
   application namespaces (NOT PodSecurityPolicy — it's removed).
2. NetworkPolicies for default-deny plus the specific allows our services need.
3. RBAC with least-privilege ServiceAccounts.
4. A short note on whether Kyverno would buy us anything beyond PSA for our case.

For each manifest, add a one-line comment explaining what it blocks. Flag
anything that would break existing workloads on apply.

Caution

The restricted Pod Security Standard rejects a lot of common-but-sloppy workloads (root containers, host mounts, missing seccompProfile). Roll it out in warn/audit mode first, read what would have been rejected, fix the workloads, then switch to enforce. Going straight to enforce on a live namespace is how you lock yourself out of your own deployments.

MCP servers and skills for this loop

A few security data sources are worth wiring in as MCP servers so the agent can query live cloud posture instead of working from a stale export. The server (command, args, env) is the same everywhere — only the config file and its format differ: Cursor and Claude Code (.mcp.json) use the JSON mcpServers shape, while Codex (~/.codex/config.toml) expresses the same fields as a TOML [mcp_servers.<name>] table.

AWS security posture — the aws-security-mcp package (real, on npm) exposes Security Hub, GuardDuty, and IAM findings:

{
  "mcpServers": {
    "aws-security": {
      "command": "npx",
      "args": ["-y", "aws-security-mcp"],
      "env": {
        "AWS_REGION": "us-east-1"
      }
    }
  }
}

The same server in Codex’s ~/.codex/config.toml — identical fields, TOML syntax:

[mcp_servers.aws-security]
command = "npx"
args = ["-y", "aws-security-mcp"]

[mcp_servers.aws-security.env]
AWS_REGION = "us-east-1"

Do not hardcode AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY as literals in a config you might commit. Let the server pick up credentials from the standard AWS chain — an assumed IAM role, SSO, or ~/.aws/credentials — the same way the AWS CLI does.

Azure security posture — Microsoft’s first-party @azure/mcp server covers Defender for Cloud and resource queries:

{
  "mcpServers": {
    "azure": {
      "command": "npx",
      "args": ["-y", "@azure/mcp@latest", "server", "start"],
      "env": {
        "AZURE_SUBSCRIPTION_ID": "your-subscription-id",
        "AZURE_TENANT_ID": "your-tenant-id"
      }
    }
  }
}

GitHub MCP server (github/github-mcp-server, remote at https://api.githubcopilot.com/mcp/) is the persistent connection for the remediation half: it lets the agent search code across the org, read Dependabot and secret-scanning alerts, and open the PR. Use it when the agent needs to act on GitHub repeatedly. There is no @anthropic/* package and no one-string new MCPClient('github') convenience layer — MCP is connect(transport) then callTool({ name, arguments }), and if you script directly against the SDK the package is @modelcontextprotocol/sdk with the client at @modelcontextprotocol/sdk/client/index.js.

On the skills side, 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.

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, AWS Security Hub). When both exist, the skill is faster to install and the server is deeper.

There is no canonical trivy-mcp-server on npm, and snyk-agent-scan (formerly mcp-scan) is not a container scanner — it is a hygiene tool for your own MCP setup. Keep container scanning on the Trivy CLI / GitHub Action and treat any “container security MCP” claim as something to verify before you paste it.

Scan your MCP setup itself

If you’re adding MCP servers to a security workflow, audit them. snyk-agent-scan (run via uvx) statically inspects your installed MCP servers for prompt injection, tool poisoning, and rug-pull attacks — the supply-chain risks specific to MCP. This is Invariant Labs’ former mcp-scan, renamed after Snyk acquired Invariant Labs in June 2025; the old mcp-scan package on PyPI is now just a redirect shim that installs and forwards to snyk-agent-scan, so use the canonical name:

# Scan all installed MCP server configs for malicious tool descriptions
uvx snyk-agent-scan@latest scan

# Inspect the exact tool descriptions your model is being fed
uvx snyk-agent-scan@latest inspect

This is a real, current command — and a genuinely good habit once you depend on third-party MCP servers for security data.

Compliance evidence: SOC 2 and GDPR

Compliance is mostly evidence assembly, and that is exactly the kind of structured-collation work an agent is good at — provided you point it at real artifacts (access logs, IaC, config exports) rather than asking it to assert compliance from nothing.

Cursor

Drop your access-review export and IaC into context, connect @aws-security for live config, and ask for an evidence package mapped to specific controls.

Using `access-review.csv` (our quarterly IAM export) and the Terraform in
`infra/`, draft a SOC 2 evidence package for controls CC6.1 (logical access),
CC6.3 (network access), and CC8.1 (change management). For each control: cite
the specific file/line or log entry that demonstrates it, and flag any control
where the evidence is missing or weak. Do NOT claim a control is satisfied
without pointing to the artifact that proves it.

Claude Code

Claude Code can read the repo, run git log for change-management evidence, and assemble the package in one pass.

Map our personal-data flows for a GDPR Article 30 record. Search the codebase
and `infra/` for: where PII is collected, which datastores hold it (grep for
schema/migrations), where it crosses a service or third-party boundary (Stripe,
SendGrid, analytics), and where retention/deletion is implemented. Output a
table of data category -> store -> lawful basis (mark "UNKNOWN — needs legal
review" if not evident) -> retention. Be explicit about gaps; do not invent a
lawful basis.

Codex

Use Codex with read-only sandboxing for an evidence pass — it should read and report, not modify infrastructure.

codex --sandbox read-only "Assemble SOC 2 CC6.1 access-control evidence from access-review.csv and infra/"

Then ask for the gap report, which is the part an auditor actually acts on:

Read `access-review.csv` and `infra/`. For SOC 2 CC6.1/CC6.3/CC8.1, produce a
gap report: control, current evidence (with file/log citation), and the single
most important gap to close. Rank gaps by audit risk. Flag any control with no
supporting artifact as a blocker.

The discipline that makes this trustworthy: every “satisfied” claim must cite a real artifact. An evidence package the agent fabricated will fail the moment an auditor asks to see the underlying log — so prompt explicitly for citations and gap-flagging, as above.

When AI-assisted security automation breaks

Caution

False-positive storms. semgrep --config=auto is broad on purpose, and container scanners flag hundreds of “criticals” that are unreachable transitive deps or unfixable base-image noise. Pin to focused rulesets for your stack (--config=p/owasp-top-ten --config=p/javascript), pass ignore-unfixed where appropriate, and feed the agent project context (“this is an Express API; req.params is the only untrusted source”) so it downgrades noise correctly. Make it confirm reachability before it calls anything a P0 — otherwise you have automated alert fatigue.

Caution

Scanner or cloud auth failures look like a clean bill of health. If the triage comes back suspiciously empty, the MCP server or CLI probably failed to authenticate (expired SSO, wrong region, missing role) and returned nothing. Verify the underlying tool runs standalone (aws sts get-caller-identity, trivy image …) before trusting the agent’s summary.

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 and 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 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

Admission-controller lockouts. Switching Pod Security Admission straight to enforce: restricted, or applying a too-broad Kyverno policy, can block your own deploys and even cluster system pods. Stage with warn/audit, exempt kube-system, and test on one namespace first.

Caution

Fabricated CVEs, evidence, and APIs. The single biggest risk is an agent confidently citing a CVE number, CVSS score, or compliance artifact that does not exist — or calling a database function that does not exist, like ai_classify_pii() or ai_sensitivity_score() in a generated SQL query. PII classification happens in application code calling a real model API or a dedicated scanner, never as inline SQL. Never accept a finding you cannot trace to scanner output or a real artifact, and make “cite the source or flag it as unknown” a standing instruction in every security prompt.

Caution

MCP supply-chain risk. A malicious third-party MCP server can poison the agent’s context. Run uvx snyk-agent-scan@latest scan after adding any server, and pin versions.

Where to go next with security operations

Compliance Automation with AI Turn SOC 2 and GDPR evidence collection into a repeatable AI-driven workflow.

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

Operate: the deployment stage Where security gating fits in the broader deploy and run pipeline.

The MCP Ecosystem How to wire up, scope, and audit MCP servers safely.

CI/CD Pipelines Building the pipeline your security gate plugs into.

Cloud Cost Optimization Keep the scan-and-triage loop cheap by routing models and capping token spend.