Who Approves What in Safeguard Compliance, and Why the AI Never Does

In Safeguard's Compliance and GRC suite (GA), every decision that makes something count in your programme is made by a person who holds a compliance reviewer role: approving a policy version, accepting evidence, approving a test exclusion, accepting a high or critical risk, and approving a crosswalk mapping. The Auditor role alone is not a reviewer, and Safeguard's AI assistant and MCP clients such as Claude or ChatGPT can draft and submit work but can never accept, approve, launch or acknowledge anything, whoever is signed in behind them.

That split is deliberate. Auditors test management's decisions, so they cannot also make them. An AI model can prepare a decision quickly, but an auditor needs a named human who owned it. This post walks through each decision type in the suite, who may make it, what the record looks like afterwards, and where the platform stops and your own process takes over.

Key takeaways

• Compliance and GRC suite (GA). Policies, evidence, test exclusions, risk acceptance and crosswalk mappings each wait for a person. Every decision is stamped with who made it, when and why.
• Who is a compliance reviewer. An administrator (Super Admin, Tenant Admin or Org Admin), a holder of the GRC role or a compliance admin, manager or reviewer role, or anyone granted a compliance review, approve, admin or manage permission, per Safeguard's approvals documentation.
• The Auditor role alone is not a reviewer. An external auditor tests your decisions; they do not make them.
• The assistant never decides. Safeguard's in-app assistant, Griffin AI Search (part of in-app agentic search, early access), and MCP clients connected through the Safeguard MCP server (GA) can draft and submit. They cannot accept, approve, launch or acknowledge, even after a write is confirmed.
• Unknown roles are refused. If Safeguard cannot tell who is deciding, it refuses the decision and says why.
• Risk acceptance scales with the residual level. The owner can accept a low or medium residual risk; high or critical needs an admin approver and a review date within a year. A rise in residual risk flips the acceptance to "Needs re-approval".
• Crosswalk approvals are append-only. Only an approved equivalent mapping lets evidence count toward another framework's control.
• Agent identity (GA) and Trust Center (early access) sit around this model: the first tracks which agent holds what access, the second has its own reviewer-only access-request decisions.

Why frameworks care who made the decision, not just what it was

Most control frameworks ask two separate questions about any control. Was the right thing done? And can you show who had the authority to decide it, and that they did? A screenshot of a configuration answers the first. Only a decision trail answers the second.

SOC 2: authority and policy deployment

The AICPA's 2017 Trust Services Criteria, with the revised points of focus published in 2022, are the criteria a SOC 2 examination measures against. Two criteria in the Common Criteria series are about decision authority. CC1.3 maps to COSO principle 3: management, with board oversight, sets up structures, reporting lines and the authorities and responsibilities needed to meet objectives. CC5.3 maps to COSO principle 12: the entity deploys control activities through policies that say what is expected and procedures that put those policies into action.

ISO/IEC 27001:2022: roles, risk owners and documented information

ISO/IEC 27001:2022 makes the same demand in management-system terms. Clause 5.3 requires top management to assign and communicate the responsibilities and authorities for roles relevant to information security. Clause 6.1.3 requires the risk treatment plan to be formulated and the risk owners to approve it and accept the residual information security risks. Clause 7.5.3 covers control of documented information, including version control and protection against unintended change.

Read together, those clauses describe exactly the controls the Safeguard approvals model records: a named risk owner who accepts residual risk, a policy whose approved version is protected while a new draft is reviewed, and a record that shows which version a decision covered.

NIST CSF 2.0: Govern

NIST's Cybersecurity Framework 2.0 added the Govern function in February 2024. Its Roles, Responsibilities, and Authorities category, GV.RR, includes GV.RR-02: roles, responsibilities and authorities related to cybersecurity risk management are "established, communicated, understood, and enforced". The Risk Management Strategy category includes GV.RM-02 (risk appetite and risk tolerance statements are established, communicated and maintained) and GV.RM-06 (a standard method for calculating, documenting, categorising and prioritising risks). The Policy category includes GV.PO-02, which expects policy to be reviewed, updated, communicated and enforced as requirements, threats and technology change.

NIST SP 800-53, SP 800-37 and SP 800-39: who accepts risk

NIST's control catalogue and its risk management guidance are blunt about risk acceptance. SP 800-53 Rev. 5 control CA-6 (Authorization) requires a senior official to be assigned as the authorizing official and to authorise the system before it operates. SP 800-37 Rev. 2, the Risk Management Framework, explains that authorizing officials issue an authorization to operate and in doing so accept the security and privacy risks on the organisation's behalf. SP 800-39 puts it in one line: "clear assignment and accountability for accepting risk is essential".

AC-5 (Separation of Duties) asks organisations to identify duties that should be split between people and to define access authorisations to support that split. AU-10 (Non-repudiation) asks for evidence that an individual, or a process acting on their behalf, performed a given action. CA-7 (Continuous Monitoring) asks for ongoing control assessments. PM-9 (Risk Management Strategy) asks for a strategy that is applied consistently and reviewed.

OWASP LLM06: why the AI should not hold the pen

The OWASP Top 10 for LLM Applications 2025 lists Excessive Agency as LLM06. It describes harm that comes from giving a model-driven system too much functionality, too many permissions or too much autonomy. Two of its mitigations matter here. Require user approval: use a human in the loop to approve high-impact actions before they happen. Complete mediation: enforce authorisation in downstream systems rather than relying on the model to decide whether an action is allowed.

A compliance approval is a high-impact action. Accepting a critical risk or approving a security policy changes what your organisation is committing to. If an assistant could do it, the record would show the name of whoever was signed in, not the person who actually thought about the decision. That is the case Safeguard's rule closes.

Who counts as a compliance reviewer in Safeguard

Safeguard's approvals documentation defines a compliance reviewer as any one of the following:

1. An administrator: Super Admin, Tenant Admin or Org Admin.
2. A holder of the GRC role, or of a compliance admin, manager or reviewer role.
3. Anyone granted the compliance:review, compliance:approve, compliance:admin or compliance:manage permission.

The offering describes the underlying authorisation model as roles and permissions with tenant admin and org admin scopes, plus members management. Your identity provider and SSO setup decide who those people are; Safeguard decides what each role may do inside the suite.

Three rules sit above the role check.

An auditor does not decide your programme. Safeguard's general role model gives the Auditor role read-only access to audit records, findings and compliance evidence. The approvals rules make the consequence explicit: the Auditor role alone does not make someone a reviewer. The docs note one exception that runs the other way: in an audit engagement, the auditor accepts or rejects what your team submits against the auditor's own requests. That is the auditor testing your work, not deciding your programme.

The assistant never decides. A change made through Safeguard's AI assistant or an MCP client can draft and submit, but never accept, approve, launch or acknowledge, whoever is signed in behind it. A Tenant Admin who asks Claude to "approve the access control policy" gets a draft or a submission at most, never an approval.

Unknown roles are refused. If Safeguard cannot tell who is deciding, it refuses the decision and explains why, rather than assuming the person has authority. This matters during SSO or role-mapping changes, when a user can briefly have a role name the platform does not recognise.

Why the Auditor role is read-only

Independence is the reason. An auditor who approves your access control policy and then tests whether your access control policy is approved is testing their own work. An assurance report is only worth something if the person giving it stands apart from the decisions being tested. Keeping the Auditor role out of the reviewer set means you can give an external firm broad read access during fieldwork without any risk that a click in the wrong place turns them into a decision maker.

What the assistant and MCP clients can do, and what they never do

Safeguard is built to be used by AI agents as well as people. The MCP server (GA) lets external assistants query your tenant, and Griffin AI Search inside the app (early access) can prepare work for you. The approvals documentation sets two safeguards for both.

Writes wait for you. An MCP client runs a write only after you confirm it in that client. In Griffin AI Search, every write shows a Confirm or Cancel card and runs only after you choose Confirm.

Decisions stay with people. Even a confirmed write cannot approve, accept, launch or acknowledge anything. Those decisions are made by a person in the app.

The practical split looks like this:

What the directory connector exposes by default

When you add Safeguard to Claude through Claude's connector directory, where Safeguard is listed as a community connector, the tools a new workspace gets by default are read-only. Safeguard's tool gating docs say a new workspace starts with a small default set of reads (listing products and projects, reading a project, listing and reading vulnerabilities, listing findings), and every other tool ships disabled until whoever administers your tenant turns it on. Which tools appear for your account is resolved per tenant from your plan and administrator settings, so a missing tool means "not enabled here", not "Safeguard cannot do it". For the full walk through of that route, see the series post on Safeguard in your IDE and in the Claude and ChatGPT connector directories.

Even in a tenant where an administrator has enabled compliance write tools, the approvals rule does not change. The assistant can get a policy to "submitted". It cannot get it to "approved".

Where agent identity fits

Safeguard's agent identity capability (GA) tracks which agent holds what access, at what level. The offering frames this as an audit requirement that grows as enterprises deploy agents against their own systems. The approvals model and agent identity answer two halves of one auditor question: what could the agent touch, and what could it decide? In the compliance suite, the second answer is always "nothing that counts".

Policies: submit, approve one version, edit safely, review yearly

Policies are where most first audits start, and where version confusion causes the most findings. Safeguard's flow, from the approvals documentation:

1. Draft. Write the policy on Compliance › Policies, or start one from a framework template: open the framework on Compliance › Frameworks, go to its Policies tab, choose New policy, then Start from template. Lion, Safeguard's compliance and narrative model (GA), covers policy authoring and can help with the text.
2. Submit for review. Choose Submit for review. The policy now waits for a compliance reviewer. An assistant can take a policy this far, with your confirmation.
3. Approve. A reviewer approves it. The approval covers one version of the content, not the policy as an abstract object.
4. Effective and review dates. On approval, the effective date defaults to the approval day and the next review date to one year later.
5. Edit later without a gap. Editing an approved policy sends the new version to review while the approved version stays in force. Staff keep following the text they were asked to follow until the new one is approved.
6. Annual review. Marking the annual review done moves the review date on by a year without creating a new version. Use it when the reviewer reads the policy and decides nothing needs to change.

Step 5 is the one auditors notice. In many document tools, editing a policy changes the live text immediately, so there is a window where staff are bound by something nobody approved. In Safeguard, the approved version is the one in force until a reviewer approves its replacement.

Safeguard's docs also describe a policy acknowledgement campaign, launched by a reviewer, so staff acknowledge a specific approved version. Acknowledgement campaigns follow the same rule as everything here (the assistant cannot launch one or acknowledge on anyone's behalf); this post does not cover how they run.

Compliance policies are not security policies and gates

The word "policy" means two different things in Safeguard. Compliance policies are the written documents above. Security policies, gates and guardrails (GA) are rules that evaluate scan results and can block, warn, notify or require approval at a checkpoint such as CI or release. Plain English policy creation (GA) belongs to that second group. The approval flow in this post applies to compliance policies. For the release gate side, see plain English security policies to release gates in Safeguard.

Evidence: submitted, accepted or rejected, versioned, expiring

Evidence is what turns a control from a claim into something an auditor can test. Safeguard treats evidence acceptance as a decision with its own record.

1. Submitted. On Compliance › Evidence, evidence starts as submitted. That covers a file, a link or a note attached to a control.
2. Accept or Reject. A reviewer chooses Accept or Reject. The decision is stamped with who made it, when and why.
3. Automated test results. A result recorded by an automated test from its own run starts accepted on that basis. The reasoning: the test ran against the connected system, so no person typed the result in.
4. Changes make a new version. Changing accepted evidence, whether its file, link, note, dates or linked control, creates a new version that goes back to submitted. An acceptance covers only the version the reviewer saw.
5. Expiry. Accepted evidence with an end date becomes expiring inside its reminder window and expired from that date.

The versioning rule in step 4 closes a common gap. Without it, someone could replace an accepted penetration test report with a different file and keep the "accepted" status. In Safeguard, the replacement goes back to submitted and needs its own decision.

Once evidence expires, it stops backing its control until fresh evidence is accepted, which in turn affects the framework readiness score. For how that score treats evidence that is still waiting, see the series post on what a Safeguard readiness score counts.

Test exclusions: reason, approver, expiry, five states

Automated compliance tests check connected systems resource by resource. Some resources fail a test on purpose. The classic case is a break-glass account kept for emergencies, which may lack the single sign-on or MFA setup a test expects because it has to work when SSO is down.

Safeguard handles this with an exclusion request rather than a mute button:

1. Open the test's detail page under Compliance › Tests.
2. Choose Exclude for the resource you want to exclude.
3. Give a Reason. The app's own example is a break-glass account kept for emergency access whose use is alerted and reviewed monthly. The dialog asks for a reason of a minimum length, so a one-word reason will not pass.
4. Choose an Approver.
5. Set Expires on. The date must be in the future, and the app caps how long an exclusion can last.

Nothing is excluded until the approver approves. From approval until the expiry date, the resource counts as not applicable, with your reason shown as the evidence.

An exclusion is in one of five states, and the test's Exclusions tab lists them all:

Why "not applicable" needs an expiry date

An exclusion with no end date becomes a permanent blind spot. The break-glass account that was justified two years ago may now have a password nobody has rotated and an owner who has left. The expiry forces a fresh decision, and a fresh reason, on a schedule. It also gives an auditor what they need to test the exception: who decided, why, and for how long.

This is the same logic NIST CSF GV.PO-02 applies to policy and SP 800-53 CA-7 applies to monitoring: decisions decay unless something brings them back for review. For how exclusions sit next to a risk register, the post on exception registers versus risk registers is a useful companion.

Risk acceptance: who may accept, review dates, "Needs re-approval"

Accepting a risk means deciding to live with it rather than reduce it further. ISO/IEC 27001:2022 clause 6.1.3 puts that decision with the risk owner. NIST SP 800-37 puts it with an authorizing official for a system. Safeguard's Risks area combines both ideas by scaling the authority with the risk level.

On Compliance › Risks, accepting a residual risk depends on its level:

The app shows this rule on the risk itself. For a low or medium residual risk, it tells the owner they can accept it themselves and that it will be recorded with their name and reason. For a high or critical one, it says acceptance needs an admin approver and a review date within a year.

Which residual counts

The register records an inherent level and a residual level for each risk. The app also lets you record an assessed residual, with one guard: an assessed residual cannot be higher than the inherent risk. When deciding who may accept, Safeguard uses whichever of the assessed and computed residuals is worse. That stops a risk from being talked down to "medium" on paper so the owner can accept it alone.

"Needs re-approval"

If the residual risk later rises above the level it was accepted at, the acceptance shows Needs re-approval. The app's wording is that the residual risk has risen above the band it was accepted at, so you should re-approve or revoke the acceptance.

That flag is the platform doing what GV.OV-03 and PM-9 ask for: noticing when the facts behind a decision change, and putting the decision back in front of a person. It does not revoke the acceptance by itself and it does not change your controls. A person has to decide.

Crosswalk decisions: approve, reject, withdraw

A crosswalk maps a control in one framework to a control in another. If your SOC 2 access review evidence also satisfies an ISO/IEC 27001 Annex A control, a crosswalk saves you from collecting it twice. The risk is that a loose mapping lets evidence count somewhere it should not.

Safeguard's Compliance › Crosswalk view shows how the controls of the frameworks you use relate to other frameworks, where each mapping came from, and who has reviewed it. Each mapping carries a strength:

• Equivalent. Whatever meets the source control fully meets the target. Credits evidence once reviewed.
• Partial. Real overlap and a real gap. A suggestion: the target still requires what the residual says.
• Related. Worth knowing about. Does not move the target control at all.

Each mapping also says where it came from: an official published mapping, Safeguard's assessment of the control text, or a mapping composed through a pivot framework.

A reviewer decides whether a mapping holds for your programme:

1. Approve. For an equivalent mapping, approval makes accepted evidence for the source control count toward the target control in your programme. For a partial mapping, approval confirms the suggestion but makes nothing count.
2. Reject. The reviewer says why the mapping does not hold for you.
3. Withdraw decision. Takes back an earlier decision.

Decisions are never edited or deleted. Each is a new record, the latest one counts, and the full history stays readable. Each decision is also tied to the mapping's text. If a later crosswalk version changes the mapping, your approval no longer applies and the mapping shows as changed since your decision, so it needs another look.

For the wider idea of mapping one control to many frameworks, see map one control to many frameworks with a crosswalk.

Trust Center access requests (early access)

The Trust Center (early access) is a public page that shows your compliance posture and can share restricted documents, such as an audit report or a penetration test summary, with people you approve. Requests to see restricted documents are decided on Compliance › Trust Center › Access requests.

A visitor requests access, accepts your NDA and confirms their email. Only then does the request reach your team. A compliance reviewer approves or denies it, choosing full or limited access and when access ends, or an auto-approval rule you configured decides it. Domains you list under "Always review these domains" always wait for a person, whatever the rules say. Only a compliance reviewer or administrator can publish or take down the auditor's opinion on your Trust Center. The NDA acceptance records the version, the name the requester typed, when they accepted and the agreement's SHA-256, so you can prove what was accepted.

For the full setup, see set up a Safeguard Trust Center step by step.

A worked example: one week of approvals

Here is how the rules fit together for a mid-size engineering organisation preparing for its first SOC 2 Type II period. The names are roles, not people.

Monday. The security lead asks Claude, connected through the directory connector, to summarise which policies are past their review date. Claude reads the policies and lists three. The lead asks Claude to draft updated wording for the incident response policy to reflect a new on-call tool. Claude writes the text in the chat. Nothing in Safeguard has changed yet, and the old approved version stays in force.

Tuesday. The lead opens Compliance › Policies, pastes the new wording into the policy as a new version, fixes two lines and chooses Submit for review. The GRC manager, who holds a compliance reviewer role, approves it. The effective date is today and the next review is a year out. For the other two policies, the reviewer reads them, decides nothing changed and marks the annual review done.

Wednesday. An automated identity test fails on one account. It is the break-glass admin account. The platform engineer chooses Exclude, writes the reason (emergency access, alerted on use, reviewed monthly), picks the security lead as approver and sets an expiry six months out. The exclusion is Pending approval. On Thursday the security lead approves it.

Thursday. A new scan shows a critical vulnerability in a library used by an internal service with no fixed version yet. The risk owner records it on Compliance › Risks. Residual risk is high because the service holds customer data, so the owner cannot accept it alone. An admin approver accepts it with a review date in three months and links it to the relevant controls.

Friday. The external auditor, who holds the Auditor role, signs in and reads all of the above: each decision with who made it, when and why. They cannot approve anything, and they do not need to. Their job is to test whether these decisions were made by the right people under the right rules.

Two weeks later, a new advisory reports active exploitation of that library. The residual risk rises to critical, above the band it was accepted at, and the acceptance shows Needs re-approval. The admin approver now has to re-approve or revoke it.

Decision table: who approves what

What Safeguard does not do

The approvals model is a record of human decisions, not a replacement for them. Here is where it stops.

1. Safeguard records decisions; it does not make them. No model, rule or score in the suite approves a policy, accepts evidence or accepts a risk for you. The "Needs re-approval" flag tells you a decision is out of date; a person still decides what to do.
2. It does not decide your risk appetite or your risk method. The thresholds for "high" and "critical", and who in your organisation should be an admin approver, come from your own risk management strategy, as GV.RM-02 and PM-9 expect.
3. It does not confirm that evidence is true. Accepting evidence records that a reviewer looked at a specific version and decided it was sufficient. It does not prove the document is accurate. That is the reviewer's judgement, and then the auditor's test.
4. It does not carry out the real-world change. Approving an exclusion does not fix the break-glass account. Revoking access, rotating credentials and fixing a misconfiguration happen in the source system or through a ticket.
5. Crosswalk suggestions are not conclusions. A mapping from an official source or from Safeguard's text assessment is still a suggestion until a reviewer approves it, and only equivalent mappings move evidence.
6. It does not replace your auditor. Safeguard helps you prepare and keeps the trail; an accredited auditor or assessor tests the decisions and issues any report or certificate. Safeguard does not perform the audit.
7. It does not decide who your reviewers are. Role assignment comes from your administrators and identity provider. If too many people hold an admin role, every one of them can approve high and critical risk acceptances. Keep that list short.
8. The assistant's reach depends on your tenant. Which MCP tools a connected assistant can use is set per tenant by your plan and administrator. Expect a small read-only default set unless someone has turned more on.

Common mistakes

Giving everyone an admin role "to keep things moving". Admins are compliance reviewers and admin approvers for high and critical risk. A broad admin group defeats separation of duties (SP 800-53 AC-5) and makes the approver name on a record meaningless.

Treating the auditor as a reviewer. Some teams try to get the external auditor to "sign off" a policy inside the tool. Safeguard will not let the Auditor role do that, and you should not want it to. An auditor approving your policy compromises their independence.

Asking the assistant to approve. "Approve all pending evidence" will not work, by design. Use the assistant to summarise what is pending and what each item claims, then decide in the app.

Replacing an accepted file and assuming it is still accepted. Any change to accepted evidence makes a new submitted version. Plan the review time for re-submitted evidence before an audit window.

Exclusions with expiry dates far in the future. The app caps how long an exclusion can last, but even within that cap, a long exclusion is a long blind spot. Match the expiry to the review cadence in your reason ("reviewed monthly" suggests a short expiry and a renewal).

Ignoring "Needs re-approval". A stale acceptance is still on the register, so it is easy to leave. An auditor reading the register will see an accepted risk whose current level exceeds what was accepted. Re-approve or revoke promptly.

Approving partial mappings and expecting evidence to flow. Approving a partial mapping confirms the suggestion. It does not make evidence count. If the target control still shows gaps, read the residual text on the mapping.

Forgetting that crosswalk approvals go stale. When a new crosswalk version changes a mapping, your approval no longer applies. Check for mappings changed since your decision after each framework update.

FAQ

Can the Auditor role approve policies or accept evidence in Safeguard?

No. The Auditor role alone is not a compliance reviewer. Auditors can read audit records, findings and evidence. In an audit engagement, the auditor accepts or rejects what your team submits against the auditor's requests, which is part of testing, not running your programme.

Can Claude or ChatGPT approve compliance items through the Safeguard connector?

No. Safeguard's AI assistant and MCP clients can draft and submit, but never accept, approve, launch or acknowledge, whoever is signed in behind them. Even a write you confirm in the client cannot be an approval.

Who can accept a high or critical risk in Safeguard?

An approver with an admin role, and the acceptance needs a review date within a year. The risk owner can accept low and medium residual risks on their own, recorded with their name and reason.

What does "Needs re-approval" mean on a Safeguard risk?

The residual risk has risen above the level it was accepted at. Someone with the right authority for the new level must re-approve the acceptance or revoke it.

What happens when I edit an approved policy?

The new version goes to review and the approved version stays in force. Staff keep following the approved text until a reviewer approves the new one.

Does evidence from automated tests need manual acceptance?

A result recorded by an automated test from its own run starts accepted. Evidence a person uploads or links starts as submitted and needs a reviewer to accept or reject it.

How long can a test exclusion last?

Until the date you set in Expires on, which must be in the future and is capped by the app. Nothing is excluded until the named approver approves it.

Do crosswalk approvals let evidence count across frameworks?

Only for equivalent mappings. Approving an equivalent mapping makes accepted evidence for the source control count toward the target control. Approving a partial mapping confirms the suggestion and makes nothing count.

Can I delete a crosswalk decision I made by mistake?

No. Decisions are never edited or deleted. Choose Withdraw decision; that adds a new record, the latest one counts, and the history stays readable.

What if Safeguard cannot tell which role I have?

It refuses the decision and says why. Fix the role mapping with your administrator and try again.

Fewer risks to accept

Every risk acceptance in this post exists because a fix is either not available yet or not worth the cost today, and the cleanest way to shrink a risk register is to give the owner fewer risks to accept. The block below describes how Safeguard closes the gap between a vulnerability and a fix in the open source code you ship, which is where many accepted software risks come from.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo shows Claude being connected to Safeguard with an OAuth sign-in and choosing which tools Claude may use. The same idea underpins this post: the assistant only gets the access your tenant grants, and nothing it does through those tools can approve a compliance decision. In practice, add Safeguard from Claude's connector directory rather than setting up a custom connection.

Click through it at your own pace, or open it full screen.

The second demo is a real Android session in the Safeguard mobile app (early access, beta): work is sent to a computer running the Safeguard CLI (GA), and the person approves the command on the phone with Allow once, Allow for turn or Deny. It is a different surface from the compliance suite, but the principle is the same one the approvals model enforces: the agent proposes, and a named person decides.

Click through it at your own pace, or open it full screen.

For more on human approval of agent actions across Safeguard's apps, see human approval for agent actions in the Safeguard desktop and mobile apps. For the day-to-day view of a compliance programme in the suite, see continuous compliance in Safeguard, and for how to hand an auditor a dated, scoped evidence summary, see one dataset, four audiences.

To try it, download the apps at safeguard.sh/download and read the documentation at docs.safeguard.sh.

Quick check

Sources

• Safeguard docs: Approvals
• Safeguard docs: Requests and approvals
• Safeguard docs: RBAC, Teams and Organizations
• Safeguard docs: Trust Center access requests
• Safeguard docs: MCP tool availability and gating
• Safeguard docs: Claude
• Safeguard docs: Compliance frameworks
• AICPA: 2017 Trust Services Criteria (with revised points of focus, 2022)
• NIST CSWP 29: The NIST Cybersecurity Framework (CSF) 2.0
• NIST SP 800-53 Rev. 5 control catalog (OSCAL, NIST)
• NIST SP 800-37 Rev. 2: Risk Management Framework
• NIST SP 800-39: Managing Information Security Risk
• OWASP Top 10 for LLM Applications 2025: LLM06 Excessive Agency

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.