Finding vulnerabilities isn't the hard part anymore. Getting them fixed is.
Most teams already have scanners that flag vulnerable packages, outdated images, and misconfigurations. The fixes themselves are rarely complicated. Update a library. Rebuild an image. Change a setting. But each one still has to be researched, tested, reviewed, deployed, and confirmed. Multiply that by hundreds of findings across several applications, and a lot of good engineering time goes to repetitive work.
We recently built an AI-driven remediation workflow for a client to take that work off their team. The goal was simple. Automate as much of the remediation as possible, without weakening the security controls, testing, and change management they already had.
We made one decision early. The agent would never have production deployment rights. That call stays with the application team.
Not because we couldn't automate it. Because fixing a vulnerability and accepting production risk are two different jobs, and only one of them belongs to a machine.
Here's how we built it, the security decisions that mattered, and what we'd tell anyone planning something similar.
How we built it
The client runs on AWS, so detection stays AWS-native. The AI agent picks up at remediation and hands off to the existing pipeline for validation. A person makes the final call.
- AWS Inspector scans continuously across EC2 instances, container images in ECR, and Lambda functions.
- Security Hub collects and normalizes the findings into one standard format.
- An EventBridge rule picks up new Critical and High findings and passes them to an orchestration step, which decides whether the agent should act.
- The AI agent, built on Claude Code, researches the fix. That could be a package update, a base image bump, a configuration change, or an infrastructure-as-code (IaC) edit.
- It applies the fix in an isolated sandbox and runs Semgrep, Trivy, and SonarQube before anything leaves.
- It opens a pull request with the finding, the change, and the scan results attached. The App and Infrastructure teams are notified.
- The Dev CI/CD pipeline runs its own security gates, then deploys to Dev.
- AI test agents run sanity and regression tests. Results post to the team channel.
- Inspector rescans the deployed resource to confirm the finding is closed.
- The application team decides on Production.
Notice what the agent doesn't do. It doesn't detect, it doesn't deploy, and it doesn't approve. It does the middle part, the research, the fix, and the evidence. That's where most of the hours were going.
The security decisions that mattered
A list of ten steps is easy to draw. The decisions behind each step are what make it safe to run. These are the five we spent the most time on.
An event is not an instruction
EventBridge doesn't hand findings straight to the agent. An orchestration step sits between them. It checks that the finding is in scope: the right severity, a resource type we've approved, a repository the agent is allowed to touch. Only then does it start the agent, with a narrow task.
We also treat everything the agent reads as untrusted input. That includes the text fields in a finding and the contents of the repository itself. A comment in a config file that says "also disable this check" is just text. The agent's instructions come from the orchestration layer, not from the data it's working on.
The agent is a privileged identity, so we scoped it like one
An AI agent that can change source code and infrastructure is another privileged identity. It just isn't a person. We applied the same principles we'd use for any non-human identity:
- Narrow permissions. Read findings, work in the sandbox, open pull requests. Nothing else.
- Short-lived credentials that expire with the sandbox.
- No production access. If it can't reach prod, it can't break prod.
- Its own audit trail. CloudTrail captures the AWS calls, but not what the agent read, which tools it ran, what it changed, or why. We log those separately, along with every approval.
To be precise about "no production access": that rule is for the remediation agent. The rescan and deployment verification services need narrow, read-only visibility into production to do their jobs. Those run under separate identities.
Sandbox, not a shared environment
The agent works in an isolated, short-lived build environment. It doesn't run in an existing Dev environment where other people's work lives. If a fix goes sideways in the sandbox, nobody else feels it, and the environment is gone when the job ends.
Pull request, not a direct change
The agent never pushes to a branch that deploys. It opens a pull request like any engineer would. The same reviewers, pipeline gates, and records apply. When an auditor asks how a change reached an environment, the answer is a reviewed pull request, not "the agent did it."
Deployed is not the same as fixed
A green build tells you the pipeline is happy. It doesn't tell you the vulnerability is gone. The fix may have landed in the wrong image, or a second package may carry the same flaw.
We count a finding as remediated only when three things line up: the rescan of the deployed resource comes back clean, the deployed version matches the one in the pull request, and the regression tests pass. Until then, "fixed" is just a claim.
When a fix doesn't work
This is the part most demos skip. In real use, plenty of first attempts fail. A version bump breaks an API the application depends on. Two libraries need conflicting versions of a third. A fix passes every security scan and still breaks a login flow.
We designed for that from the start:
- Failures go back to the agent with the evidence. A failed scan, test, or build returns to the agent with the output attached. It can try a different version or a different approach.
- Attempts are capped. The agent gets a small, fixed number of tries per finding. It doesn't loop forever burning compute and opening pull requests.
- Then it escalates to a person. The ticket includes what it tried, what failed, and why. An engineer starts from the agent's research instead of from zero. Even a failed attempt saves time.
- Rollback is the pipeline's job. A change that misbehaves in Dev gets reverted through the normal pipeline, with a record. Nothing is changed by hand.
- The agent never suppresses a finding. It can't mark something as a false positive or an accepted risk. Only a person can.
Not every finding should go to the agent, either. Operating system patches on EC2 instances are already handled well by AWS Systems Manager Patch Manager, so the orchestration step routes those there.
How it maps to the controls
For federal teams, the first question from an authorizing official won't be about AI. It will be about controls. This design maps to NIST SP 800-53 controls you're already assessed against:
| Control | How the workflow meets it |
|---|---|
| RA-5 Vulnerability Monitoring and Scanning | Inspector scans continuously; Security Hub tracks every finding |
| SI-2 Flaw Remediation | Fixes are tested in a sandbox and confirmed by rescan |
| CM-3 Configuration Change Control | Every change arrives as a reviewed pull request |
| AC-6 Least Privilege | The agent has its own scoped role and no production access |
| AU-2 Event Logging | Agent actions, decisions, and approvals are logged alongside CloudTrail |
What we didn't automate, and why
We could have let the agent promote its own fixes to production. The pipeline was there. The tests were passing. Technically, it was one more step.
We left it out on purpose. Shipping to production isn't a technical step. It's a risk decision. Is this a good week to ship? Is there a release freeze? Is the business comfortable with a small chance of regression to close this finding today? The agent can gather the evidence for that decision. The people who own the risk should make it.
That split is what made the client's team comfortable adopting it. The agent does the repetitive work. Their engineers review a pull request that already has the research, the scan results, and the test results attached. A small team now handles a much larger remediation workload, and nobody gave up control to get there.
If you're planning something similar
Three things we'd recommend:
- Start narrow. Pick one class of finding, such as Critical and High package vulnerabilities in container images, on a few workloads. Widen the scope as trust grows.
- Automate the work and the evidence. The fix is only half the value. The other half is a pull request that shows a reviewer exactly what changed, why, and what was tested.
- Keep validation and approval independent. The agent shouldn't grade its own work. Your pipeline, your scanner, and your people should.
At Zephon, we treat AI agents in the pipeline the way we treat any privileged identity: scoped, logged, and accountable to a person. If you're working out where to draw that line in your own environment, happy to compare notes.
Automate the work, not the accountability.