Hand Your Security Findings to a Coding Agent: Claude Code, Codex and opencode

Why this workflow suddenly makes sense

Look at what an external scanner actually reports: Strict-Transport-Security missing, SameSite absent on a session cookie, SPF ending in ~all instead of -all, TLS 1.0 still answering, a CSP that was never promoted from report-only. Almost none of these are "investigate for a week" problems. They are small, well-understood edits to nginx or Caddy config, framework middleware, a CDN behavior, or a DNS record in Terraform — files that sit in version control next to everything else.

That is precisely the shape of work coding agents handle well: a bounded task list, a codebase to search, config formats they have seen thousands of times, and a clear definition of done. The bottleneck was never knowing the fix for a missing nosniff header. It was that the finding lived in a PDF someone filed away, three steps removed from the repo where the fix goes.

What a good handoff contains

Pasting "here's our scan report, fix it" under a 40-page attachment produces wandering. The handoffs that work give the agent four things:

• The findings as a list, worst first. Severity, title, the affected module (headers, TLS, DNS, exposed services), and the scanner's evidence. The agent should burn its effort on the high finding, not the informational one it happened to read first.
• The suggested fix from the scanner. Not because the agent can't derive it, but because it anchors the change to what the re-scan will actually check.
• Permission to say "not in this repo." Some fixes live at the registrar, in a managed-hosting dashboard, or on a load balancer console. An agent told this up front will flag those with exact instructions instead of hallucinating a file to edit.
• A verification step per finding. The curl -sI that shows the header, the dig TXT that shows the record, the openssl s_client that shows the protocol. "Do not mark a finding resolved without stating how to verify it" is the single highest-leverage line in the prompt.

Bastion generates this pair for you: every completed scan has a Hand off to agent button that downloads the PDF report and produces a paste-ready prompt built from the live findings — sorted by severity, with evidence and suggested fixes inline, findings your team has muted or accepted already removed, and the verification rule included. (On the free trial the prompt is a one-finding preview; the complete hand-off comes with any paid plan.) But the structure above works with any scanner's output if you assemble it by hand.

The handoff, agent by agent

Claude Code

Anthropic's terminal agent runs inside your repo and can read the PDF directly: drop the report in the project (or anywhere reachable) and reference it by path in the prompt. Claude Code will open the PDF for evidence, grep the codebase for where headers or TLS settings are configured, make the edits, and — because it can run shell commands — execute the verification steps itself against a staging deploy (curl -sI https://staging.example.com | grep -i strict-transport). Paste the prompt, attach the path, review the diff it proposes.

OpenAI Codex

Codex runs as a CLI in your terminal or as a cloud agent working against your repository. The CLI flow mirrors Claude Code: put the PDF in the working tree, paste the prompt, let it propose changes locally. In the cloud flow you hand it the task and it returns a pull request — which suits this workflow well, since a PR per scan is a natural unit of review, and the findings list from the prompt becomes the PR description more or less verbatim.

opencode

The open-source terminal agent, bring-your-own-model. Same mechanics — repo, PDF, prompt — with one practical note: whether the agent can read the PDF itself depends on the model you've wired in. This is why a good handoff prompt duplicates the findings as text rather than saying only "see attached": with the list inline, the PDF becomes supporting evidence instead of a required capability, and the handoff works even with a model that can't open it.

What agents fix well — and what stays with you

Expect an agent to genuinely close out: security headers and cookie flags (framework middleware or proxy config), TLS protocol and cipher settings (nginx/Caddy/ALB config in the repo), SPF, DMARC and CAA records when DNS is managed as code, and redirect-to-HTTPS behavior. That covers the bulk of a typical first scan.

Expect it to hand back, clearly flagged: DNS managed by clicking in a registrar dashboard, settings that only exist in a hosting provider's console, anything requiring a business decision — retiring a subdomain, choosing a DMARC enforcement date, whether that database port is exposed on purpose. An agent that has been told "say so explicitly and give the exact change" turns these into a short human checklist instead of silently skipping them.

Keep the loop honest

Two rules make this safe rather than reckless. First, the agent proposes, a human merges — security config diffs are short, and reading them is minutes; letting an agent push header changes to production unreviewed trades one class of risk for another (a malformed HSTS or an over-tight CSP is a same-day outage). Second, verify from outside, not from the diff — the fix is real when the response over the public internet shows it. Run the verification commands after deploy, then re-scan. The next report — findings resolved, score up — is your closed loop, and if you keep it, an audit-ready record that the issue was found, fixed and confirmed. The failure mode that remains is drift, which is what the continuous re-scanning is for.

Frequently asked questions