Executive summary:
Most automated fix pull requests never get merged, and Green AI remediation in Phoenix is built to change that. Typical fix tools start from the repository instead of your priorities, don’t show their evidence, and open pull requests nobody actually decided to open. Phoenix Green AI Remedy is now generally available. It starts from the findings you picked, shows the cost before any model runs, and leaves the pull request to a person.
Key takeaways
- Give the agent a short list you already prioritized. A list built from the repository hides the findings that matter under routine version bumps.
- Get a cost estimate before any model runs. Set a cap for one run.
- Read the status of each finding first, then the diff. When the reviewer can see what a change covers, approval takes minutes.
- If the base branch moved, assess again. A fix built on yesterday’s code needs a fresh review.
- Close findings on the next scan. A merge says the change landed. The scan says the vulnerable version is gone.
The problem: fix pull requests nobody merges
Every vulnerability management team knows this one. On Monday a batch of automated fix pull requests shows up. By Friday a few are merged. Some conflict with the base branch. The rest just sit there, because nobody can tell which upgrade will break the build.
The tool did its job. It found a vulnerable version and proposed a newer one. But the developer who owns the service had no reason to trust it. The pull request didn’t say which findings it fixed, which ones it skipped, or what the upgrade does to the code that calls the library.
This keeps happening, and it costs more than it looks. You pay for model calls on changes that never ship. You pay again in reviewer hours on pull requests that get closed. Then developers start closing security pull requests without reading them, and that includes the one that actually matters. That part hurts the most.
Security teams already have plenty of data. What’s missing is context, and a clear owner for the code. A tool that adds more pull requests without those two just sends more noise to a developer who never asked for it.
Where AI remediation loses the developer
The model is rarely the problem. Four choices around it decide if a fix gets merged.
Scope comes from the repository. Most fix tools work per repository or per manifest. They propose an upgrade for everything they can see. A security engineer works from a short list: findings that are reachable, in CISA KEV or high on EPSS, and owned by a known team. When the tool ignores that list, the important findings get lost among routine bumps.
Repository identity is guessed. Picking a library across a whole portfolio is messy. The same package can sit in two repositories, on two branches, with a shared lockfile in one of them. If you match findings to repositories by package name, sooner or later you edit the wrong file or target the wrong branch.
Evidence sits behind a green tick. A minor version bump looks safe. Whether it is safe depends on how the service uses the library, and on whether the build still resolves. Give reviewers a green tick instead of evidence, and they stop reading.
Approval happens as a side effect. A pull request writes to a repository someone else owns. Opening one is a decision. When pull requests open as a side effect of analysis, the person who is accountable for the code never gets to make it.
Put these together and you can guess the ending. The team decides AI remediation doesn’t work. What actually went wrong is that remediation started before the context was there.
The Phoenix approach: Green AI Remedy
Phoenix Green is the agentic remediation pipeline in Phoenix Security. Its SCA remediation flow, AI Remedy, is now generally available. We built it on one rule: context first, then prioritization, then the agent. The agent gets a short list with owners and priorities. A person decides what goes into the repository.
There are six steps. Only step five writes to your repository.
- Select the exact findings, libraries, or build files you want fixed.
- Preview the repositories, any exclusions, and the cost in US dollars.
- Assess each repository at a pinned commit, within a spend cap.
- Review the diff, the deferred candidates, and a status for every finding.
- Publish: a person clicks Push branch & create pull request.
- Verify on the next scan, which closes the finding.
Start from the findings you chose
A plan starts from something you select in Phoenix platform. That can be the Libraries view, a build file, an asset, a team dashboard or the remediation details of a library. The selection is exact. Pick two library and asset pairs, and only their findings go into the plan.
Phoenix resolves the selection with your organisation’s own permissions. It groups findings by repository, branch and build file. If it can’t map something to a repository with confidence, it lists it as an exclusion with a reason. That list is useful by itself. Every exclusion points to a gap in who owns what.
See the price before anything runs
The first screen shows the number of findings, the repositories and build files, the exclusions, and an estimate in US dollars next to your remaining budget. The estimate comes from pricing data, so nothing is charged yet. The first model call happens when someone presses Start assessment.
Green runs on your organization’s own model key, with a monthly spend cap for all of its AI usage. If the scope or the pricing changed since the estimate, Phoenix asks for a new one before it starts.
Assess the repository as it is now
The agent assesses each repository at a pinned commit. It resolves direct and transitive dependencies, compares upgrade candidates, prepares the edits, and checks compatibility. You see each step while it runs. You can close the panel, and the run keeps going. The plan waits for you under Security > Remediation plans.
The result is laid out for the person who has to approve it:
- the changes in the diff, with versions and the findings each one covers
- the candidates the agent looked at and deferred, each with a reason
- a status for every selected finding, so the ones that need a human decision stand out
- the validation that ran, and the diff itself
A person opens the pull request
Assessment never writes to your repository. Publishing is a separate step: push branch & create pull request. You choose one pull request per repository or one per build file. Phoenix builds the change on the exact commit it assessed. If the base branch moved since then, it asks for a new assessment first. Clicking twice lands on the same branch and the same pull request.
Starting an assessment and publishing need a dedicated permission. By default, organisation administrators, security administrators and security developers have it. Seeing the page isn’t enough to write to a repository. You can also close a plan as reviewed without opening a pull request, and every plan stays visible to the team.
A merged pull request doesn’t close a finding in Phoenix. The next scan does. Only the scan shows the vulnerable version is really gone.
What a plan looks like in practice
A vulnerability manager filters the backlog to reachable findings listed in CISA KEV. One library shows up in three Java services, so that’s the pick. The scope screen shows the findings, the three repositories and one exclusion: a repository with no owner mapped in Phoenix. The manager fixes the mapping, refreshes the estimate, checks it against the budget and starts the assessment.
The panel closes and the run keeps going. When the owning team opens the plan, it shows which upgrade covers which findings, and why one candidate was put aside. Two findings need a decision from someone who knows the service. They’re flagged at the top.
The team lead reads the status of each finding first, then the diff. The two flagged findings go to the right engineer. The lead publishes one pull request per repository. Reviewers open a pull request that already says what it changes and why, and merge it the usual way. The next scan closes the findings in Phoenix.
Now go back to that Monday batch from the start of this post. It’s the same library upgrade. The difference is that every claim in this pull request can be checked. So a developer can merge it on a Tuesday afternoon.
Why context comes first
An agent is worth its cost on the findings left after context is applied. So volume is the first thing to fix. ClearBank, a Phoenix customer, cut container vulnerabilities by 98% once Phoenix applied that context. Green then works on a list a team can actually own.
Practical guidance for Monday morning
With Phoenix or without it, these are the checks to run before you hand any fix to an agent.
- Start with selection. Filter your list by reachability, CISA KEV and EPSS, and pick one library with findings in two or three repositories. That’s a better first plan than “everything critical”.
- Read the exclusions, not only the total. An exclusion for a missing repository mapping means nobody owns that code in your tooling. Fix it once and every later plan gets better.
- Agree on the price before the run. Set a cap per run and a monthly budget. If the estimate is stale, stop and refresh it.
- Read the status of each finding before the diff. Send the findings that need a decision to the owning team as a decision, not as a bug.
- Send the review to the owner. If a repository has no owner, fix that before you publish. A pull request nobody owns is the same noise as before, just with better notes.
- Let the scanner close it. After the merge, wait for the next scan to confirm the vulnerable version is gone.
Next steps
- Ask your Phoenix administrator to accept the AI terms and add your organization’s model key under Settings > Organization > AI settings.
- Run one AI Remedy plan on a single library this week, and review its exclusions with the service owners.
- Book a demo to see Green turn a prioritized selection into a reviewed pull request, with the cost on screen before anything runs.
