Security Operations Automation

Your scanner just flagged 412 “critical” findings across 50 container images, the on-call channel is on fire, and your SOC 2 auditor wants the access-review evidence by Friday. The findings are real, but most are noise — and you have no fast way to tell which three actually matter. This is where an AI agent wired to your real security tooling earns its keep: not by inventing magic, but by reading scanner output, correlating it with your code, and drafting the evidence you’d otherwise assemble by hand.

What you’ll walk away with

• A pattern for piping real scanner output (Trivy, your cloud security tool) into Cursor, Claude Code, or Codex so the agent triages instead of you.
• Verified MCP setups for AWS and Azure security data, plus the one MCP-hygiene scanner you should actually run.
• Copy-paste prompts for vulnerability triage, a security-gated CI pipeline, and SOC 2 / GDPR evidence drafting.
• A Kubernetes hardening prompt that uses current APIs (Pod Security Admission, not the removed PodSecurityPolicy).
• A clear-eyed “when this breaks” 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. The durable pattern is: a deterministic tool produces machine-readable output, and the agent reasons over that output — prioritizing by exploitability, mapping a finding to the exact line in your repo, and drafting the fix or the evidence.

# Trivy is a real CLI. Scan an image to JSON, then hand the JSON to your agent.
trivy image --severity HIGH,CRITICAL --format json -o scan.json myorg/api:latest

That scan.json is the input the agent is genuinely good at. Everything below builds on this shape: run the real tool, then prompt the agent over its output.

MCP servers for security context

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 shown below, 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"
      }
    }
  }
}

Note

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 (shown below) 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.

Vulnerability triage: from 412 findings to 3 that matter

Run the scanner, then let the agent do the prioritization a human would otherwise grind through. The agent reads the JSON, cross-references your code to see whether a vulnerable path is actually reachable, and ranks by real exploitability rather than raw CVSS.

Cursor

Open the repo, drop scan.json into the Composer context, and run the triage prompt. With the @aws-security MCP server connected, add @aws-security to let it check whether an affected service is actually internet-exposed.

Tip

Copy-paste prompt for vulnerability triage:

Read scan.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.

Claude Code

From the repo root, pass the scanner output as context. Claude Code can run grep/rg itself to confirm reachability, which makes its prioritization concrete rather than guessed.

claude "Read scan.json and the codebase, then triage the HIGH/CRITICAL findings"

Tip

Copy-paste prompt for a one-shot triage report (headless, e.g. in CI):

claude -p "Read scan.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 > triage.json

Codex

Run inside the Codex TUI so you can review each command before it runs. Codex defaults to a sandbox; keep approvals on for anything that touches credentials or cloud APIs.

codex "Read scan.json and triage the HIGH/CRITICAL findings against our source"

Tip

Copy-paste prompt for Codex with explicit per-action review:

Launch with codex -a untrusted (asks before each action), then paste:

Read scan.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.

What good 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.

Security-gated CI pipeline

The highest-leverage move is to put the scanner in front of deploys so a critical vulnerability 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.

Tip

Copy-paste prompt for a security-gated pipeline:

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 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, plus continuous registry scanning for images already deployed, plus an admission policy at the cluster (next section) 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 was removed in Kubernetes 1.25 — any guide still telling you to “implement pod security policies” is out of date. The current built-in mechanism is Pod Security Admission enforcing the three Pod Security Standards (privileged / baseline / restricted).

Tip

Copy-paste prompt for Kubernetes hardening:

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.

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.

Tip

Copy-paste prompt for SOC 2 evidence drafting:

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.

Tip

Copy-paste prompt for GDPR data-flow mapping:

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/"

Tip

Copy-paste prompt for a compliance gap report:

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 this breaks

• False-positive storms. Scanners flag hundreds of “criticals” that are unreachable transitive deps or unfixable base-image noise. Always pass ignore-unfixed where appropriate and make the agent confirm reachability before it calls something a P0 — otherwise you’ve automated alert fatigue.
• Scanner / cloud auth failures. If the agent’s triage looks 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.
• Admission-controller lockouts. Switching Pod Security Admission straight to enforce: restricted, or 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.
• Fabricated CVEs or evidence. The single biggest risk: an agent confidently citing a CVE number, CVSS score, or compliance artifact that doesn’t exist. Never accept a finding you can’t trace to scanner output or a real artifact. Make “cite the source or flag it as unknown” a standing instruction in every security prompt.
• 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.

What’s next

• Deployment Operations overview — where security gating fits in the broader deploy pipeline.
• The MCP Ecosystem — how to wire up, scope, and audit MCP servers safely.
• Pipeline Automation with AI — building the pipeline your security gate plugs into.