AI agents for security remediation, and what they do for developer experience

Most large engineering organisations are not short of security findings. Scanners, SCA tools and cloud posture checks produce them by the thousand. What’s scarce is developer time to fix them. That gap is where AI agents are genuinely useful, and where a careless rollout can do real damage.

The problem is remediation, not detection

A typical finding travels a long way before anything changes: a scanner flags it, a ticket is filed, a team triages it, a developer works out the context, writes a fix, waits for review and CI, and ships it. Most of that is toil, not judgement. The same dependency bump or misconfigured policy gets fixed by hand in hundreds of repositories.

That repetitiveness is exactly what an agent is good at.

Where agents earn their keep

• Dependency and base-image upgrades. Read the advisory, pick the minimum safe version, update the manifest and lockfile, run the tests, open a pull request with the reasoning attached.
• Config and IaC drift. Overly broad IAM policies, public buckets, missing encryption flags: well-bounded fixes with a clear definition of “correct”.
• Code-level patterns. Parameterising a query, removing a hard-coded secret, swapping an insecure API call. The fix is local and reviewable.
• Triage and context. Even when it doesn’t fix anything, an agent can say whether a finding is reachable, who owns the code and what the blast radius is. That alone cuts noise.

Why this is a developer-experience win

Security tooling is usually experienced as a tax: a dashboard to check, a ticket to chase, a deadline that has nothing to do with the sprint. A remediation agent flips that. The developer receives a small pull request that already passes CI, with a plain explanation of why it matters. Reviewing a good change takes minutes; producing it from scratch takes an afternoon.

The measure of success is not “findings closed”. It is how often developers merge the agent’s pull request unchanged, and how long the fix takes from detection to production.

Guardrails that make it safe

An agent that can open pull requests across an enterprise needs the same discipline as any production system:

1. Least privilege. Short-lived, narrowly scoped credentials. It proposes changes; it never pushes to protected branches or deploys.
2. Humans keep the merge button. Every change goes through normal code review and CI. Auto-merge only for a small allow-list of low-risk change types, once there is evidence they’re safe.
3. Deterministic checks around a probabilistic core. Let the model draft the fix, then verify it with tests, linters, a re-scan to confirm the finding is actually gone, and policy checks. Never trust the model’s own claim that it worked.
4. Bounded blast radius. Rate limits, per-repository opt-in, a kill switch and staged rollout.
5. Audit and traceability. Record the prompt, the context it was given, the diff and the outcome, so a bad change can be explained and the system improved.
6. Treat inputs as untrusted. Code, issue text and dependency metadata can contain instructions aimed at the agent. Prompt injection is a supply-chain risk, so isolate what the agent reads from what it’s allowed to do.

What this looks like in my work

At Comcast I build cloud remediation tools, such as a Key Rotation Service, IMDS remediation and S3 policy updates, delivered through our Developer Marketplace (a Backstage app), plus the developer-experience pieces around them. Four things shape how I think about agents:

• Meet developers where they work. Putting remediation in a self-service marketplace turns a finding into a guided fix in one place. An agent can slot into that same flow and propose the change instead of leaving a ticket.
• Leaders need decisions, not data. The Leader Insights Engine answers three questions for an engineering leader: where are my teams exposed, what problems keep recurring, and what should each team do next? It also shows portfolio status. Agents are most useful when they start from that kind of prioritised, trustworthy context.
• Reusable beats bespoke. Templates and reusable skills mean a good fix or a good practice is written once and adopted many times. That is also what makes automated remediation tractable: the more consistent the codebases, the more predictable the fix.
• The data pipeline is the foundation. The ETL jobs behind these tools run on Concourse and AWS Batch. An agent is only as good as the data it reasons over, so reliable pipelines come first.

What doesn’t work

• Asking an agent to “fix all the vulnerabilities” with no scoping or verification.
• Optimising for volume of pull requests. Noisy PRs erode trust faster than anything, and once developers start ignoring the bot the programme is dead.
• Skipping the feedback loop. Merge rate, revert rate and review comments are the training signal for what to automate next.

Where I’d start

Pick one narrow, high-volume, low-risk class of fix. Make the agent excellent at it, with verification and clear pull request descriptions. Measure merge rate and time-to-fix. Only then widen the scope. The goal is a security programme that developers feel as help rather than friction, and agents are a good way to get there if you keep humans in charge of the decisions that matter.