Autonomous Remediation: The Eight Categories Explained
Most security teams know the feeling. A scanner finds a thousand issues, a dashboard turns red, and then nothing happens for weeks because someone still has to triage each finding, figure out the right fix, write the patch, and get it reviewed. The finding was never the hard part. The fixing was.
Safeguard's Autonomous Remediation is built to close that gap, and it does it across a wider surface than most teams expect. Rather than treating "remediation" as one button that only touches vulnerable dependencies, Safeguard breaks it into eight distinct categories, each with its own logic for what a fix looks like and how cautious or ambitious that fix should be.
The eight categories
Dependencies. Outdated or deeply nested packages get updated, with strategies ranging from conservative patch bumps to full major version upgrades.
License. Risky or unknown licenses in your dependency tree get handled by swapping to an equivalent permissive license where one exists, dropping the component, or opening a tracked item for your legal team to review.
Security Posture. Control gaps get closed, and you choose whether the highest risk items go first, every missing control gets addressed, or the system prioritizes low effort, high impact work.
Findings. Open security and compliance findings get worked down, ordered by severity, by effort, or against your SLA commitments.
Attestation. Coverage gaps in SLSA levels and attestation get raised a level at a time, or pushed toward the highest achievable level.
Provenance. Commit signing and build provenance get established, whether that means signed commits in CI, SLSA build provenance, or both together.
Compliance. Framework gaps get closed, starting with your highest risk frameworks or working through every failing requirement.
Code Quality. Technical debt gets paid down, whether that means fixing blocker and critical issues first, broader refactoring, or adding tests to under covered code.
Each category carries its own strategy options, and the two most fix oriented categories, Dependencies and the underlying vulnerability remediation work, use a shared vocabulary worth understanding on its own: Safest applies only backward compatible fixes that will not break existing functionality. Balanced takes minor version updates and patches with minimal breaking change risk. Aggressive takes every available fix, including major version updates. Smart lets the model choose per item based on context, risk, and impact, rather than applying one blanket rule across an entire category.
That is a meaningfully different design than a single "auto-fix everything" switch. A team can decide that dependency updates should run on Balanced while license remediation stays on the more conservative "open a tracked item for legal" path, and compliance work runs Smart. The categories do not have to move together, because in a real organization they never should. Legal has different risk tolerance than platform engineering, and a security posture gap in a customer facing service is not the same conversation as a code quality issue in an internal tool.
Why it ships off, and why that is the right call
Here is the part worth saying plainly rather than burying in fine print: Autonomous Remediation ships off by default. Every one of the eight categories starts on Manual. Nothing gets applied automatically until an organization turns on the master toggle and chooses, category by category, how much autonomy to grant.
It would be easy to read that as a hedge, a capability that is not quite ready. It is not that. It is a deliberate design choice, and it is the correct one for a system that can open pull requests against your production code on its own initiative.
Autonomy has to be earned, not assumed. A security team adopting an autonomous fix engine needs time to see what Griffin proposes before they let it act without a human in the loop. Manual mode by default means the first several fixes are visible, reviewable, and gated exactly like any other proposed change, so the team can build confidence in the model's judgment before widening its authority. Once that trust exists, dialing up from Manual to an automated strategy on a specific category, say Dependencies on Safest, is a small, deliberate, reversible decision rather than a leap of faith made on day one.
This also respects the reality that different categories carry different blast radii. Turning on Aggressive dependency updates without ever having watched Safest fixes land cleanly would be reckless. Starting everyone at Manual, category by category, is what lets a security leader say yes to autonomy in the place where it earns trust first, typically low risk dependency patches, and hold off longer on categories like Compliance or Security Posture where a wrong automated move has bigger consequences.
What this means day to day
In practice, this gives a team a dial, not a light switch. A platform team might turn on Dependencies at Balanced within the first week, because patch level updates are low risk and high volume. A compliance team might leave Compliance and Attestation on Manual for months while they build a track record of how the recommendations look before they let anything apply on its own. Both are using the same system correctly.
That is the honest story: eight categories of real, working autonomous remediation, each configurable independently, each starting from zero trust and earning more as the organization is ready to grant it. It is a platform built to fix things, not just find them, but it does not assume you want it fixing things unsupervised on day one.
If you want to see what Autonomous Remediation looks like on your own dependency tree, or talk through which categories and strategies make sense for your organization's risk tolerance, safeguard.sh is the place to start that conversation.
