Can AI Agents Modify BIOS or UEFI Firmware? What Actually Stops Them

An AI agent can only do what the process and account it runs under can do. Writing BIOS or UEFI firmware needs administrator or root rights plus a vendor update path, and modern platforms add signed update checks, SPI flash write protection, Secure Boot and hardware roots of trust to block unsigned writes. Run agents unprivileged, isolated and behind deny rules, and the firmware stays out of reach.

"Below the OS" sounds like a place where nothing applies. Some of that worry is fair: firmware updates lag, a host firewall does not see what firmware does, and attackers have planted code in UEFI. But the path from "an agent is running on my laptop" to "the agent rewrote my firmware" crosses several gates, each one you can check and close. This guide walks through them using vendor and NIST documentation.

Key takeaways

• An AI agent is a program. It inherits the user account, the groups and the sandbox it runs in. It gets no special access to hardware because it uses a language model.
• Firmware changes go through a small number of paths: UEFI capsule updates delivered by Windows Update or fwupd, Apple's signed macOS updates, vendor flash utilities, and the firmware setup screen. Every path except the setup screen needs administrator or root rights, or an authorization prompt.
• NIST SP 800-147 (2011) and SP 800-193 (2018) define the protections: signed updates only, write protected flash, no bypass routes, plus detection and recovery.
• What an agent with an admin shell could plausibly do is narrower than a full firmware rewrite: install an older but genuinely signed firmware, change UEFI variables such as boot order, queue Secure Boot key or shim changes, or switch off operating system protections such as memory integrity.
• Real UEFI implants (LoJax, MosaicRegressor, CosmicStrand) and the BlackLotus bootkit all needed privileged or physical access first. None of them involved AI agents.
• The practical guardrails are boring and effective: no admin rights for the agent, a sandbox or VM, deny rules for firmware tools, a firmware admin password, write protection and Secure Boot left on, and a weekly look at firmware versions and Secure Boot state.

What "BIOS", "UEFI" and "firmware" mean in this question

When people say "the BIOS", they usually mean the code that runs when the machine powers on, before Windows, macOS or Linux loads. On almost every PC sold in the last decade that code is UEFI firmware, though the old name stuck. It lives in a flash chip on the motherboard, usually connected over the SPI bus, which is why security documents talk about "SPI flash".

Next to the code sits configuration: boot order, Secure Boot keys, the list of revoked boot loaders, passwords and feature toggles. UEFI stores much of this as variables in non volatile memory. NIST SP 800-193 calls this "critical data" and lists the Secure Boot configuration as one example. That distinction matters for this question, because changing a variable is a much lower bar than replacing the firmware image.

A common worry is that firmware "does not update or firewall". Both halves are partly right:

• Firmware does not patch itself the way a browser does. It updates when the operating system or a tool hands it a signed update, and many machines never receive one after the first year or two.
• A host firewall filters network traffic for the operating system. It has no view into what firmware does at boot, and firmware does not consult it.

Neither point means any program can write firmware. The write path is guarded separately, and that guard is what this post is about.

An agent is just a process with an account

Coding agents work by running tools: read a file, edit a file, run a shell command. When an agent runs a shell command, the operating system sees an ordinary child process owned by the user who started it. There is no special channel to the hardware.

So the real question is: what can that user account do?

What an unprivileged agent can and cannot touch

If the agent runs as a normal user, with no sudo rights and no local administrator membership, it cannot:

• Open the raw SPI flash interface. On Windows and Linux this needs a kernel driver or root access to platform registers.
• Write UEFI variables. On Linux the efivarfs file system under /sys/firmware/efi/efivars is writable only by root. On Windows, the Secure Boot cmdlets require an elevated PowerShell session, and Microsoft's documentation for Confirm-SecureBootUEFI notes that even reading the state fails with "Access was denied" outside administrator mode.
• Install a driver, which is how a signed but vulnerable driver would be loaded.
• Run a vendor flash utility, which almost always demands elevation.

It can still do damage in user space, such as deleting files or leaking credentials it can read, which is what permission prompts and sandboxes mainly address. Firmware is not in that list.

One nuance on Linux desktops: fwupd, the Linux firmware update daemon, exposes a D-Bus interface that the LVFS documentation says "can be used by unprivileged clients", with PolicyKit deciding when authorization is needed. Depending on your distribution's policy, an unprivileged session may be able to ask fwupd to install a vendor signed update after an authorization prompt. The image still has to be signed and accepted by the platform, so this is a path to an official update, not to arbitrary code.

What changes with administrator or root

Give the agent sudo, run it as root, or run it in an elevated Windows terminal, and the picture changes. It can now call the same update tools you can, write UEFI variables, change Windows security registry settings, load drivers and stage files on the EFI System Partition. Whether it can go further and rewrite the firmware image itself then depends on the platform protections described below.

That is why "no admin rights for agents" is the first control. Anthropic's docs make a related point: on Linux and macOS, Claude Code refuses to start with its skip all prompts flag when running as root.

How firmware updates actually happen

Every legitimate firmware change uses one of a few delivery paths. Knowing them tells you which commands and tools are worth watching.

Windows: UEFI capsules delivered as driver packages

Microsoft's Windows UEFI Firmware Update Platform guide describes the mechanism. OEMs ship system firmware as a driver package (an INF file plus the firmware binary). The package is not really a driver. Once it is on the machine, Windows calls the UEFI UpdateCapsule function and hands the payload to the platform firmware, which validates and applies it on the next restart.

The platform must publish an EFI System Resource Table (ESRT) entry for each updatable component with its current version and last update status, and because firmware ships as a driver package, it moves through the same servicing channels as drivers.

The decision to accept the image happens in firmware, not in Windows. Microsoft's Secure Boot requirements for OEMs state that all firmware components must be signed with at least RSA-2048 and SHA-256, and that the system "must protect against rollback of firmware to older versions." Windows can deliver a capsule; it cannot make the firmware accept an unsigned one.

macOS: firmware is part of the signed macOS update

On a Mac with Apple silicon, the boot chain starts in the Boot ROM, which Apple's Platform Security guide describes as the first step in the chain of trust. The Low Level Bootloader verifies signatures before loading system paired firmware, and iBoot then loads macOS paired firmware. Any signature failure drops the Mac into recoveryOS.

Apple's update process personalizes each installation: the device sends the bundle's measurements, its unique chip ID and a nonce, and Apple's server signs the result for that device. The signed bundle includes iBoot, older firmware from one device cannot be copied to another, and Apple can stop signing vulnerable older versions. The boot security policy lives in a LocalPolicy file signed by the Secure Enclave and can only be lowered from recoveryOS. On Intel Macs without a T2 chip, a firmware password blocks alternate boot modes; Apple says one "isn't required on a Mac with Apple silicon".

In practice, an agent on macOS cannot flash firmware separately from a macOS update. The most it could do with admin rights is install an Apple signed macOS update, which would bring its own signed firmware.

Linux: fwupd and the LVFS

Vendors upload firmware to the Linux Vendor Firmware Service (LVFS), which checks the metadata and signs it. The fwupd daemon matches devices to available firmware, verifies the signed metadata and, for system firmware, stages the capsule on the EFI System Partition, reboots and calls UpdateCapsule. The LVFS documentation says over one hundred vendors use the service and millions of devices update through it each month.

As with Windows, fwupd is the courier. The platform firmware still decides whether the capsule is authentic.

Vendor flash utilities and the setup screen

OEMs also ship their own flash tools for Windows, Linux or a bootable USB stick, and most firmware setup screens include a built in updater that reads an image from a USB drive. NIST SP 800-147 calls the physical path a "secure local update" and expects it to require physical presence, optionally plus an administrator password or a motherboard jumper. Those utilities need administrator rights when run from the operating system, and the setup screen needs someone at the keyboard.

The protections designed to block unsigned writes

Even an agent with full admin rights has to get past the firmware's own protections to replace the firmware image. These protections are defined in standards and implemented in silicon.

NIST SP 800-147: signed updates, write protection, no bypass

NIST published SP 800-147, BIOS Protection Guidelines, in April 2011. It sets out four ideas that every later design builds on:

• Authenticated update mechanism. The firmware verifies a digital signature on every update image before applying it, using a public key held in a protected Root of Trust for Update.
• Secure local update. An optional path for recovery that relies on physical presence instead of signatures.
• Integrity protection. The flash regions holding the firmware are protected by a mechanism "that cannot be overridden outside of an authenticated BIOS update", ideally enforced in hardware.
• Non-bypassability. No other component, including DMA from a device or a microcontroller on the board, may write firmware except through those two paths.

The guide notes that rollback to an authentic but vulnerable version is "particularly insidious" because the image is genuinely signed, and treats rollback protection as a recommended control.

NIST SP 800-193: protect, detect, recover

SP 800-193, Platform Firmware Resiliency Guidelines, followed in May 2018. It widens the scope from the main BIOS to other platform firmware, naming components such as the baseboard management controller or management engine and network interface controllers. It organizes the work into three principles: protect firmware and critical data from unauthorized change, detect when a change happens, and recover to a known good state.

Two points from SP 800-193 are useful here. First, it separates authentication from authorization: the manufacturer's signature proves an image is genuine, but the owner decides whether it may be installed. Second, it treats configuration such as Secure Boot settings as critical data that also needs protection, because changing it can weaken the platform without touching a line of code.

SPI flash write protection on the chipset

On Intel platforms, the chipset has control bits that decide whether software can write the BIOS region of SPI flash. The fwupd Host Security ID (HSI) specification lists the checks plainly. The BIOSWE bit must be unset, otherwise user space can write to the SPI chip. The BLE bit must be set so that BIOSWE cannot be flipped back. The SMM_BWP bit must be set to keep the BIOS region read only outside System Management Mode. The SPI descriptor must be locked. All four are required for the lowest passing level, HSI-1.

When these bits are set correctly, an operating system process, even one running as root, cannot write the firmware region directly; writes are left to the firmware's own authenticated update code. When they are not set, a privileged process can write the chip, which is what made LoJax possible on some machines.

Hardware roots of trust: Intel Boot Guard and AMD Platform Secure Boot

Boot Guard and AMD Platform Secure Boot move verification into the processor itself. The HSI specification describes Boot Guard as a processor feature that prevents the machine from running firmware images not released by the OEM, and AMD Platform Secure Boot as forming "a root-of-trust by fusing in cryptographic keys into the processor itself." AMD platforms can also enforce SPI bus control and replay protection, which HSI checks at levels 2 and 3. HSI also checks for BIOS rollback protection at level 2.

With these enabled, a tampered firmware image fails verification before it can run. The original LoJax research noted that a properly configured system with Boot Guard would have refused to boot after the compromise.

Secure Boot

Secure Boot verifies what the firmware hands control to: option ROMs, EFI applications and the operating system loader. Microsoft's OEM documentation describes the databases: db lists trusted signers, dbx lists revoked ones, KEK holds the keys allowed to update both, and the Platform Key (PK) can update KEK or turn Secure Boot off. Microsoft's boot process guide adds that turning Secure Boot off or trusting a new boot loader is done in the firmware menus, and "Software can't change the Secure Boot settings." Signed variable updates, which is how Microsoft ships dbx revocations, are the exception.

Secure Boot does not verify the firmware image itself. The researchers later corrected their LoJax write-up to say Secure Boot does not protect against that implant, while still recommending it. Separately, Microsoft is replacing the Secure Boot certificates it issued in 2011, which begin expiring in June 2026.

Measured boot with a TPM

Measured boot records what loaded instead of blocking it. Microsoft explains that the firmware stores hashes of the firmware, boot loader and boot drivers in the TPM, and a remote attestation service can check that signed log. If firmware or the boot path changes, the measurements change, which is the "detect" half of SP 800-193.

Windows memory integrity and the vulnerable driver blocklist

Memory integrity, also called hypervisor-protected code integrity (HVCI), runs kernel code integrity checks inside a hypervisor protected environment. Since the Windows 11 2022 update, Microsoft's vulnerable driver blocklist is on by default and is enforced whenever memory integrity, Smart App Control or S mode is active. That matters here because the classic route from Windows to the SPI chip is a kernel driver, and attackers increasingly use vulnerable but legitimately signed ones. Memory integrity can also be set "with UEFI lock", so turning it off later requires the firmware menu.

What an agent with an admin shell could realistically do

Suppose someone runs an agent in an elevated terminal or with passwordless sudo, with prompts switched off. Without exploit details, the realistic firmware level list looks like this.

Install a signed but older firmware

Update tools often allow downgrades for recovery. If the platform lacks rollback protection, an admin process could install an older image that is genuinely signed by the vendor but carries a known vulnerability. Both NIST guides flag this risk, and HSI checks for rollback protection.

Change UEFI variables

With root on Linux, the efivarfs file system lets a process create, modify and delete variables. The kernel documentation explains that non standard variables are created as immutable files because removing some of them has caused firmware "to fail to POST". The immutable flag stops accidents, not a determined admin process. Changing boot order, adding a boot entry or deleting the wrong vendor variable are all possible, and the likeliest outcome of a confused agent here is a machine that does not boot, not a stealthy implant.

Queue Secure Boot or shim changes

On Linux systems that boot through shim, the mokutil tool manages Machine Owner Keys and can disable shim's own validation. These requests are tied to a MokManager password, and shim's design has a person confirm them at the console on the next boot, so an agent can stage the request but should not be able to complete it alone. Firmware level Secure Boot keys follow the same pattern: authenticated variables or the firmware menu.

Weaken operating system protections

BlackLotus is instructive here. Microsoft's guidance of 11 April 2023 says the bootkit needed existing "privileged access or physical access". From there it switched off memory integrity through the registry, disabled BitLocker tamper protection and stopped Microsoft Defender. An admin agent could make the same kind of registry and service changes by mistake or under a malicious prompt, with no bootkit involved. Memory integrity with UEFI lock and a managed policy make that harder.

Load a signed but vulnerable driver

LoJax wrote to SPI flash through a legitimately signed kernel driver from a low level hardware utility. An admin process could install such a driver. On current Windows builds the vulnerable driver blocklist and memory integrity are designed to stop known ones.

Decision table: action, privilege, what blocks it, how you notice

Real UEFI threats, as context

None of the cases below involved an AI agent. They are useful because they show which gates attackers actually had to pass.

Every case started from a compromised system or physical access, and BlackLotus never touched the flash chip. The controls that stop these attackers (no standing admin rights, locked flash, current firmware, Secure Boot and memory integrity on) also stop an over eager or manipulated agent.

Guardrails for running AI agents near firmware

Ordered by how much risk each removes for the effort:

1. Run the agent without admin rights

Use a standard account for agents, with no passwordless sudo and no elevated Windows terminal. If a task needs elevation, run that one step yourself. This removes almost every row of the table above.

2. Put the agent in a sandbox, container or VM

Anthropic documents several isolation options for Claude Code, and the ideas apply to any agent:

• Sandboxed Bash tool. Shell commands run inside an operating system sandbox (Seatbelt on macOS, bubblewrap on Linux and WSL2) that by default can write only to the working directory, a per user temp directory and directories you add. It is off by default; turn it on with /sandbox. On native Windows, Claude Code runs commands unsandboxed, so use WSL2, a container or a VM.
• Sandbox runtime. Wraps the whole Claude Code process, including file tools, MCP servers and hooks. Anthropic labels it a beta research preview.
• Containers. Dev containers or custom containers put the whole environment in a container with your project mounted.
• Virtual machine. Anthropic calls a dedicated VM the strongest separation, with its own kernel and virtualized hardware. The agent then sees virtual firmware, not your laptop's flash chip.

Anthropic also says isolation reduces impact but "does not eliminate risk".

3. Keep permission prompts on and add deny rules

Claude Code's permission system has modes. Manual mode (named default in settings) prompts on first use of each tool; acceptEdits, plan, auto, dontAsk and bypassPermissions change what is approved automatically. In auto mode, a classifier reviews actions before they run and blocks, by default, things like downloading and executing code, destructive actions and flags that disarm a safety guard. Anthropic states that auto mode "does not guarantee safety".

Rules are evaluated deny first, then ask, then allow, and a broad deny cannot be overridden by a narrower allow. Managed settings sit above user and project settings and cannot be overridden, and disableBypassPermissionsMode can lock the skip all prompts mode out. Anthropic also notes two limits that matter here: permission rules are enforced by Claude Code rather than by the model, and a Bash deny rule does not match the same program called by full path or inside sh -c. Pair deny rules with the sandbox when a restriction must hold.

4. Lock the firmware itself

• Set a firmware administrator (supervisor) password so Secure Boot, boot order and flash settings need it.
• Leave Secure Boot on. Check whether your machine trusts third party boot loaders it does not need; Microsoft notes that Secured-core PCs distrust the third party UEFI CA by default.
• Enable any "BIOS write protection", "flash lock" or "downgrade protection" setting your OEM exposes. Names vary by vendor.
• On Windows, turn on memory integrity, and consider UEFI lock on managed fleets.
• Apply firmware updates from the vendor's channel on a schedule, not only when something breaks.

5. Monitor versions and boot state

Record firmware version, Secure Boot state and memory integrity state per machine, and compare them after any session where an agent had elevated rights. The commands below do this.

Step by step: check and lock down one machine

These commands only read state, except where noted. Run them on your own machine first.

Windows

Run in an elevated PowerShell window, since the Secure Boot and Device Guard queries need administrator rights:

# Firmware vendor, version and release date (SMBIOS data)
Get-CimInstance -ClassName Win32_BIOS |
  Select-Object Manufacturer, SMBIOSBIOSVersion, ReleaseDate

# Secure Boot: True = on, False = off; errors on non-UEFI systems
Confirm-SecureBootUEFI

# VBS and memory integrity status
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
  Select-Object VirtualizationBasedSecurityStatus, SecurityServicesConfigured, SecurityServicesRunning

In the Device Guard output, VirtualizationBasedSecurityStatus of 2 means VBS is enabled and running, and a 2 in SecurityServicesRunning means memory integrity is running. Save the output to a dated file and compare it over time.

For BlackLotus style tampering, Microsoft's guidance points at recently modified boot loader files on the EFI System Partition, the memory integrity registry value set to 0, and Defender service stop events. Those are signs to investigate, not things to change.

macOS

# Shows model, chip and System Firmware Version
system_profiler SPHardwareDataType

On Apple silicon, check the startup security policy in recoveryOS with Startup Security Utility if you need to confirm it is still Full Security. Firmware updates arrive with macOS updates, so keeping macOS current keeps firmware current.

Linux

# Firmware version from SMBIOS (needs root)
sudo dmidecode -s bios-version

# Devices fwupd can update, with current versions
fwupdmgr get-devices

# Host Security ID report: SPI locks, Boot Guard / PSB, Secure Boot, rollback protection
fwupdmgr security

# Secure Boot state as shim sees it
mokutil --sb-state

# Snapshot UEFI variable names and hashes for later comparison (read only)
sudo sh -c 'cd /sys/firmware/efi/efivars && sha256sum * ' > ~/efivars-$(date +%F).txt

The fwupdmgr security command, available from fwupd 1.8.4, gives recommendations for each failed test. A system that fails HSI-1 has missing basic protections such as SPI write locks, which is worth raising with the OEM or replacing the hardware for sensitive use.

To compare variable snapshots, use diff on two dated files. Some variables change on every boot, so expect noise and look for new or removed names.

CHIPSEC, carefully

CHIPSEC is an open source framework, licensed under GPL-2.0 with a contact address at Intel, for analysing PC platform security, including firmware and hardware configuration. It runs on Windows, Linux and the UEFI shell. Its README says it is "for security testing purposes. Use at your own risk." Run it on a test machine of the same model first, read its WARNING file, and treat it as an audit tool for checking flash protection and related settings, not as something to run across a fleet unattended.

Claude Code: deny firmware tools and keep the sandbox strict

The example below is a user or managed settings file. It denies the common firmware and boot tools, keeps the sandbox on without an unsandboxed fallback, and locks out the skip all prompts mode. Adjust the list for your platform.

{
  "permissions": {
    "deny": [
      "Bash(sudo *)",
      "Bash(fwupdmgr *)",
      "Bash(fwupdtool *)",
      "Bash(flashrom *)",
      "Bash(mokutil *)",
      "Bash(efibootmgr *)",
      "Bash(chattr *)",
      "Bash(bcdedit *)",
      "Bash(chipsec_main *)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false,
    "failIfUnavailable": true
  }
}

Note that fwupdmgr get-devices and fwupdmgr security are read only, so if you want the agent to report firmware state, move those exact commands to an allow rule and keep the broad deny for everything else. Remember the limit from Anthropic's docs: a deny rule does not catch the same binary through a full path or sh -c, so the sandbox and an unprivileged account are what make this hold.

Where Safeguard fits, honestly

Safeguard does not scan, monitor or protect firmware, and it is not endpoint protection or device management. Nothing in this post about SPI locks, Secure Boot or capsule updates is something Safeguard does for you.

Where Safeguard is relevant is the agent itself and the code it touches. The Safeguard CLI includes an assistant that can edit code and run commands, and it asks before each command unless you choose otherwise. Its /permissions setting offers Ask, Accept edits, Plan, Auto (the default) and Strict modes, so you can keep a human approval on every shell command when the agent works near system tools. The desktop and phone apps can send work to a computer running the CLI and approve each command remotely. On the software supply chain side, Safeguard scans repositories, container images and SBOM files for vulnerable dependencies, which matters because agents install packages as part of their work and a rebuilt or reimaged machine pulls everything again.

Common mistakes

• Running the agent as admin "just for this task" and never dropping it. Elevation is the gate for nearly every firmware relevant action. Grant it per step, by a person.
• Assuming a container isolates firmware. A container shares the host kernel. If the container runs privileged or as root with host devices mounted, it can reach the same interfaces the host can. Use a VM when you need kernel level separation.
• Treating Secure Boot as firmware protection. Secure Boot verifies boot loaders and drivers, not the firmware image in flash. You still need write protection and a hardware root of trust.
• Leaving bypass mode on outside isolation. Anthropic's docs say to use bypassPermissions only in containers or VMs. Lock it out in managed settings.
• Relying on deny rules alone. Deny rules do not match every spelling of a command. Combine them with the sandbox and an unprivileged account.
• Never checking firmware versions. A rollback or a missed update is invisible unless you record versions and compare.
• Deleting UEFI variables to "clean up". The kernel marks non standard variables immutable because deleting some of them has made machines fail to start.

FAQ

Can ChatGPT, Claude or another AI agent flash my BIOS?

Not by itself. The agent can only run commands as the account it runs under. Flashing needs administrator or root rights and a vendor signed image, and the platform's flash protections reject unsigned images. If you give the agent admin rights, it could start a legitimate vendor update, which is why you should not.

Can malware or an agent modify UEFI firmware from inside Windows?

Only with administrator rights and, for an unsigned image, a platform whose flash protections are missing or broken. LoJax did this in 2018 on machines where write protection was absent or misconfigured. Modern platforms with locked SPI flash, Boot Guard or AMD Platform Secure Boot, and the vulnerable driver blocklist make it much harder.

Does Secure Boot stop firmware rootkits?

No. Secure Boot checks what the firmware loads next, such as boot loaders. The LoJax researchers corrected their write-up to say Secure Boot does not protect against that implant. Firmware integrity relies on signed updates, flash write protection and hardware roots of trust.

Can an AI agent turn off Secure Boot?

Not from software on a correctly built PC. Microsoft states that software cannot change Secure Boot settings; turning it off is done in the firmware menu. Signed key updates are the exception. On Linux, an admin process can queue shim changes with mokutil, but those are confirmed at the console on next boot.

Does a firewall protect the BIOS?

No. A host firewall filters operating system network traffic. Firmware runs before the operating system and is protected by signatures, flash locks and measured boot, not by firewall rules.

Is it safe to let an AI agent install firmware updates?

It is safer to let the agent report what is available and apply the update yourself. Updates need a restart, can fail on battery or interrupted power, and are best scheduled. A read only command such as fwupdmgr get-devices is fine for an agent to run.

Does running an agent in Docker protect my firmware?

It helps if the container is unprivileged and runs as a non root user without host devices mounted. A privileged container shares much of the host's access. Anthropic describes a VM as the strongest option because it has its own kernel and virtual hardware.

Can a firmware implant survive reinstalling the operating system?

Yes. Implants in SPI flash, such as LoJax and CosmicStrand, survive a reinstall and even a disk replacement. The LoJax research noted that removal generally means reflashing a clean image or replacing the motherboard. Bootkits on the EFI partition, such as BlackLotus, are removed by reformatting the OS and EFI partitions.

Fix it without waiting for upstream

Firmware is outside what Safeguard covers, but the agents you run near it spend their day installing packages, and a machine rebuilt after a firmware scare pulls every dependency and container image down again. Those open source components are where the following controls apply.

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

None of these demos touch firmware. They show how an AI assistant can work with a person approving each step, which is the habit this post recommends for any agent near system tools. If you want to try the CLI, download it from https://safeguard.sh/download and read the setup guide at https://docs.safeguard.sh/docs/cli . For more on how agents get misused, see CERT-In's advisory on AI agent attack vectors, and for rebuilding after a suspected compromise, resetting and rebuilding a developer machine.

This first demo is a real CLI session. After install, safeguard opens the interactive terminal, you ask it to fix the lodash CVE in a repo, and it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. It ends with /permissions, /model and /scan, which is where you would pick a stricter mode before letting the assistant near anything system level. More background is in the Safeguard CLI overview.

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

The second demo is a real Android session: work is sent to a computer running the CLI, and the command is approved on the phone with Allow once, Allow for turn or Deny. That is the same principle as keeping permission prompts on: a person sees the exact command before it runs, even when away from the desk.

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

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Choosing tools per connection is the MCP version of the deny rules above: give the agent the narrowest set it needs.

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

Quick check

Sources

• NIST SP 800-147: BIOS Protection Guidelines and PDF
• NIST SP 800-193: Platform Firmware Resiliency Guidelines and PDF
• Microsoft Learn: Windows UEFI Firmware Update Platform
• Microsoft Learn: Secure boot (OEM requirements)
• Microsoft Learn: Secure the Windows boot process
• Microsoft Learn: Enable memory integrity
• Microsoft Learn: Microsoft recommended driver block rules
• Microsoft Learn: Win32_BIOS class
• Microsoft Learn: Confirm-SecureBootUEFI
• Microsoft Security Blog: Guidance for investigating attacks using CVE-2022-21894, the BlackLotus campaign
• Apple Platform Security: Boot process for a Mac with Apple silicon
• Apple Platform Security: Boot process for an Intel-based Mac
• Apple Platform Security: Secure software updates
• Apple Platform Security: Firmware password protection
• LVFS documentation: Introduction
• fwupd: Host Security ID specification
• Linux kernel documentation: efivarfs
• Debian manpage: mokutil
• CHIPSEC on GitHub
• MITRE ATT&CK: LoJax (S0397)
• MITRE ATT&CK: Pre-OS Boot, System Firmware (T1542.001)
• Claude Code docs: Configure permissions
• Claude Code docs: Permission modes
• Claude Code docs: Sandboxing
• Claude Code docs: Choose a sandbox environment

Last reviewed: 23 October 2026. Firmware features, update channels and agent permission settings change between versions; check the linked vendor and Anthropic pages for current behaviour.