Zero-Day Risk in AI Agents, MCP Servers and Skills: A Defender's Guide

A zero-day in an AI agent stack is dangerous for a simple reason: the bug inherits everything the agent can reach. An unpatched flaw in an MCP server, an agent framework or a skill runs with the agent's credentials, its tools and its network access. Defenders cannot predict the bug, so they prepare the blast radius instead: know every agent, MCP server and skill you run, keep their access narrow, and be able to contain and fix within hours.

This guide is written for AppSec, product security and incident response leads. It covers where unpatched flaws land in an agent stack, what public data and the platform vendors' own documentation say about the risk, a response plan for the first day, and where Safeguard helps on the response side. It does not cover finding zero-days. It covers being ready when one is disclosed in something your agents depend on.

Key takeaways

• The agent stack has more layers than most inventories track. A single assistant session can involve a model host, a client application, local and remote MCP servers, skills, plugins and an orchestration or proxy layer. A flaw in any of them is a flaw in the session.
• Public exploitation data already includes agent infrastructure. CISA's Known Exploited Vulnerabilities (KEV) catalog lists exploited flaws in agent builders, workflow tools and LLM proxies, including one in an MCP endpoint added on 2 September 2026.
• Anthropic and OpenAI both put trust decisions on you. Anthropic's docs say it reviews directory connectors against listing criteria but does not security-audit or manage any MCP server. OpenAI's docs say remote MCP servers "have not been verified by OpenAI."
• Readiness is mostly inventory and least privilege. If you cannot list which agents load which MCP servers and skills, at which versions, with which credentials, you cannot answer "are we exposed" on disclosure day.
• Safeguard covers the response side, all generally available (GA): SBOM generation and analysis (GA), AI-BOM discovery (GA), agent identity (GA), reachability with EPSS and KEV prioritisation (GA), policies and gates (GA), MCP Guardrail (GA), CSAF and VEX upload (GA), autonomous remediation (GA, ships switched off with every category set to Manual) and the free Gold Open Source directory (GA), which includes MCP server and agent skill listings.
• Safeguard does not patch hosted services you do not build. If the flaw sits in a vendor's hosted MCP server or a model provider's platform, the fix comes from that vendor. Your levers are disconnecting, narrowing scopes and rotating credentials.

What counts as a zero-day in an agent stack

A zero-day is a vulnerability that attackers know about, or exploit, before the people who maintain the software have shipped a fix. The "zero" is the number of days defenders have had a patch available. Once a fix ships, the same flaw becomes an n-day: the patch exists, but it is not yet running everywhere.

For agent stacks, both windows matter, and the second one is often longer than teams expect. MCP servers are frequently installed by individual developers through a configuration file, run as a local process, and never touched again. Skills are copied into a folder and forgotten. An agent framework gets pinned in a container image that nobody rebuilds.

So when this guide says "zero-day risk," it means the whole period in which you are exposed and cannot simply update: before a fix exists, and the stretch after a fix exists but before you know where the vulnerable copies are.

The layers an agent session depends on

It helps to name the layers, because each one is a separate piece of software with its own maintainers, release cadence and advisory channel.

1. The model host. The provider that runs the model. You do not patch it; the provider does.
2. The client or agent application. A desktop assistant, a coding agent in the terminal or IDE, or your own application built on an agent SDK. This is the process that decides which tools to call.
3. MCP servers. The Model Context Protocol lets a client connect to servers that expose tools, resources and prompts. Servers can run locally as a child process over stdio, or remotely over HTTP. Remote servers are often hosted by a SaaS vendor; local servers are usually open source packages from npm or PyPI.
4. Skills. Anthropic's Agent Skills are folders with a SKILL.md file plus optional scripts and resources that give the agent new procedures. Other agent platforms have similar packaged instructions.
5. Plugins and extensions. Bundles that can add servers, skills, commands and hooks in one install.
6. Orchestration and proxy layers. Agent builders, workflow automation tools, LLM gateways and MCP proxies that sit between users, models and tools.
7. The credentials and data the agent can reach. OAuth tokens, API keys, repository access, cloud roles, files on disk. This is not software, but it is what turns a bug into an incident.

A traditional application zero-day usually gives an attacker the privileges of one service. An agent-layer zero-day can give an attacker the union of every tool and token that the agent session holds. That is the core of the risk.

What the public record shows

Zero-day statistics are easy to misuse, so this section sticks to primary public sources and says exactly what each one measures.

The broad zero-day picture

Google Threat Intelligence Group (GTIG) tracked 75 zero-day vulnerabilities exploited in the wild in 2024, down from 98 in 2023 and up from 63 in 2022, according to its 2024 zero-day review. GTIG splits them into end-user platforms (mobile, operating systems, browsers) and enterprise technologies, and it reported a shift toward enterprise targets, particularly security and networking products. GTIG is clear that the figures reflect exploitation it tracked and may not reflect all of it.

Google Project Zero also publishes a public tracking spreadsheet of detected in-the-wild zero-day exploits, collected from public sources. It is a useful record for seeing which product categories get hit and how quickly vendors respond.

Neither source singles out AI agents as a category in the material fetched for this guide. That matters: you should not claim that agents are "the most targeted" zero-day surface. What the data does support is narrower and still important. Attackers favour enterprise software that sits on trust boundaries and holds credentials, and agent infrastructure is enterprise software that sits on trust boundaries and holds credentials.

Agent infrastructure in CISA KEV

The KEV catalog lists vulnerabilities CISA has evidence of active exploitation for. It is not a zero-day list: many entries were exploited after a fix existed. But it is the clearest public signal of what attackers actually use, and as of catalog version 2026.10.23 it includes several entries in agent and LLM infrastructure.

A few patterns stand out. Most entries are remote code execution or authentication bypass. Most hit software that teams self-host to build or route agent traffic. And the most recent one is squarely in MCP: an authentication flaw in an MCP transport endpoint of a widely used LLM proxy. If your organisation ran that proxy with its MCP endpoint exposed, an attacker did not need to compromise a model or trick a prompt. They needed a network path.

The KEV entry for CVE-2026-59822 also points to CISA's BOD 26-04, which replaced BOD 22-01 in June 2026 and moved federal remediation timelines to a risk-based model. Older KEV entries still carry BOD 22-01 wording in their required action text; treat that as history, not as the current federal deadline rule.

Disclosed flaws in the MCP layer itself

Beyond KEV, NVD records show the classes of bugs that appear in MCP clients, servers and tooling. These are not claims of in-the-wild exploitation. They show where the weak joints are.

• CVE-2025-6514, mcp-remote. NVD describes OS command injection when the tool connects to an untrusted MCP server, triggered by crafted input in the authorization endpoint URL the server returns. Published 9 July 2025. The lesson: a client that connects to a hostile server can be the victim.
• CVE-2025-49596, MCP Inspector. Versions below 0.14.1 allowed remote code execution because the Inspector client and proxy did not authenticate each other, so unauthenticated requests could launch MCP commands over stdio. Published 13 June 2025. The lesson: developer tooling for MCP runs with developer privileges.
• CVE-2025-68145, mcp-server-git. When started with a flag restricting it to one repository, versions before 2025.12.17 did not check that later tool calls stayed inside that path. Published 17 December 2025. The lesson: a server's own scoping is only as good as its validation.
• CVE-2025-54136, Cursor. In versions 1.2.4 and below, an attacker who could modify an already trusted MCP configuration file, for example in a shared repository, could swap a harmless server for a malicious command and get persistent code execution. Published 2 August 2025. The lesson: trust attached to a configuration file name is not trust in what the file says today.

None of these needed a novel model attack. They are ordinary bugs (injection, missing authentication, path validation, trust-on-first-use) in new places, so ordinary containment works if you know where the software runs.

What Anthropic, OpenAI and the MCP specification say about the risk

When you set policy for agent tools, use the platform vendors' own words. They are explicit that the trust decision sits with the customer.

The MCP specification

The MCP specification's tools page says that for trust and safety there SHOULD always be a human in the loop with the ability to deny tool invocations, and that applications SHOULD show which tools are exposed, signal clearly when tools are invoked and present confirmation prompts. It also says clients MUST treat tool annotations as untrusted unless they come from trusted servers. That last point matters for zero-days: a compromised server can describe a destructive tool as read-only.

The MCP security best practices page lists the attack classes implementers must handle, including confused deputy attacks through MCP proxies, token passthrough (which the authorization specification forbids), server-side request forgery, session hijacking, local MCP server compromise and scope minimisation. On local servers it notes that they run on the user's machine, may have direct access to the system and may be reachable by other local processes. On scopes, it describes how broad scopes granted up front increase the impact of a stolen token.

Anthropic

Anthropic's Claude Code security page says project-scoped MCP servers live in .mcp.json, which can be checked into source control, but that servers at other scopes, claude.ai connectors and plugins can add servers too, so reviewing .mcp.json does not show every server a session can load. It points administrators to managed MCP configuration to restrict which servers run in an organisation, recommends writing your own servers or using ones from providers you trust, and states that Anthropic reviews connectors against its listing criteria before adding them to the Anthropic Directory but does not security-audit or manage any MCP server. The same page describes a permission system in which sensitive operations require explicit approval in Manual mode, and it puts responsibility for reviewing proposed commands on the user.

Anthropic's help article on custom connectors advises connecting only to remote MCP servers built and hosted by organisations you trust, reviewing and limiting requested permissions during authorisation, and staying aware that malicious servers may include hidden instructions.

Anthropic's Agent Skills overview is direct: use Skills only from trusted sources, meaning ones you created or obtained from Anthropic. It explains that a malicious Skill can direct Claude to call tools or run code in ways that do not match its stated purpose, recommends auditing every bundled file (the SKILL.md, scripts, images and other resources), and flags Skills that fetch from external URLs as a particular risk, because fetched content can change after you review it.

OpenAI

OpenAI's documentation for connectors and remote MCP servers says developers must trust any remote MCP server they use, that a malicious server can exfiltrate sensitive data from anything that enters the model's context, and that remote MCP servers have not been verified by OpenAI. It recommends treating prompt injection as an important consideration when tools can reach sensitive data or take actions, and it points to the require_approval and allowed_tools parameters as the way to require approval for sensitive actions and limit which tools a model can call.

OWASP

The OWASP GenAI Security Project's Top 10 for LLM applications (2025 edition) names the risks that turn an agent-layer bug into real damage. LLM01:2025 Prompt Injection covers instructions smuggled in through content the model reads, which is how a compromised server or skill most easily steers an agent. LLM03:2025 Supply Chain covers third-party components such as models, packages and plugins. LLM06:2025 Excessive Agency covers systems granted more functionality, permissions or autonomy than they need, which is exactly what widens the blast radius of a zero-day. OWASP's separate Agentic AI threats and mitigations guide extends this thinking to autonomous agents and their tools.

What that means in practice

Read together, these sources say four things:

1. No directory listing is a security audit of the server.
2. Configuration can come from several places, not one file.
3. Human approval and tool allowlists are the platform's own containment controls.
4. Skills are code and instructions, and should be reviewed like code.

A zero-day plan for agent stacks should be built on those four points.

Where a zero-day lands, and what it buys an attacker

The table below maps each layer to the kind of flaw seen in public records, what an attacker gains if that layer is unpatched, and the first containment lever you control.

Two observations follow from the table. First, the "first lever" column is mostly about access and exposure, not patching. Patching is the end state; containment is what you do on hour one. Second, every row needs the same input: an accurate list of where that component runs.

Prepare before the disclosure

Most of the work that decides how a zero-day day goes happens weeks earlier. These are the preparations that pay off.

Build an agent inventory that answers four questions

For every agent deployment, you want to answer:

1. Which client or framework is it, at what version?
2. Which MCP servers can it load, from which configuration sources, at which versions, and are they local or remote?
3. Which skills and plugins are installed, from which source, at which version?
4. Which credentials and scopes does each server and the agent itself hold?

Questions 1 and 2 are partly a software composition problem. A local MCP server installed from npm or PyPI is a package; an agent application you build has a dependency tree that includes its SDKs and its server libraries. Question 4 is an identity problem. Question 3 sits in between: a skill is a folder of instructions and scripts, which you can track as an asset even if it is not a package.

Pin versions and know your sources

Unpinned installs make zero-day response slower because you cannot say which version is running. Pin MCP server packages and agent frameworks in lockfiles or image digests. Record where each skill came from. If a client lets you install a server by running a package runner with "latest," treat that as a finding.

Narrow scopes before you need to

The MCP security guidance on scope minimisation is the cheapest zero-day control you will ever deploy. A server that only holds a read scope on one project cannot leak write access to every project when it is compromised. Review OAuth grants for connectors, replace broad API keys with narrow ones, and avoid giving a single agent session both sensitive read access and an outbound channel it does not need.

Keep approvals on for actions that change things

Both platform vendors' docs describe approval controls. Use them for actions that write, delete, send or spend. A zero-day that hijacks a session is far less useful if the destructive tool call waits for a human.

Decide in advance who can pull the plug

On disclosure day, someone needs the authority to disconnect a connector organisation-wide, block a server in managed configuration, or take a self-hosted agent builder off the network. Write down who that is and how they do it before you need it.

A response plan for the first 24 hours

When a zero-day or a freshly disclosed critical flaw lands in an agent component, work through these steps in order. Times are a guide, not a promise.

1. Hour 0: confirm the advisory and the affected range. Read the vendor or maintainer advisory, the CVE record and the KEV entry if one exists. Note affected versions, fixed versions if any, the transport or feature involved (for example only the HTTP endpoint, or only when a certain flag is set) and whether exploitation is known.
2. Hour 0 to 1: find every copy. Search your SBOMs and asset inventory for the package or product and version. Check the agent configuration sources, not just repositories: managed client settings, user and project MCP configuration, installed plugins and skills, container images and self-hosted services.
3. Hour 1 to 2: decide what is exposed. For each copy, ask whether the vulnerable feature is enabled and reachable. A flaw in an HTTP endpoint matters less for a copy that only runs over stdio on a laptop; a flaw that needs a hostile server matters less if clients can only reach an allowlist. Use reachability and configuration facts, and write down the reasoning.
4. Hour 1 to 4: contain. Disconnect or block the affected server in managed configuration, remove network exposure for self-hosted components, turn on approval for affected tools, and narrow or revoke scopes. If the component held credentials and exploitation is plausible, plan to rotate them.
5. Hour 2 to 8: fix where a fix exists. Upgrade the package or image to the fixed version through your normal pipeline, with tests. Where no fix exists, apply the vendor's mitigation, or remove the component until one ships.
6. Hour 4 to 12: stop it coming back. Add a gate so builds that reintroduce the vulnerable version fail, and update the allowlist so the bad version cannot be installed again.
7. Hour 8 to 24: record and communicate. For products you ship to customers, decide whether each product is affected and say so in a machine-readable form, such as a VEX statement. Record what you changed, which credentials you rotated and why you judged a copy not exposed.
8. After 24 hours: review. Check logs for tool calls and sessions during the exposure window, close the loop on credential rotation and update your inventory gaps.

The steps are the same ones you would follow for any critical vulnerability. The difference with agents is step 2: the copies hide in configuration files and personal installs, not just in the build.

How Safeguard helps on the response side, step by step

Safeguard's role in this post is response: knowing where an affected component lives, prioritising, containing, fixing and recording. Every capability named here is generally available. This section follows the order of the response plan.

Step 1: Inventory what your agents are built from

SBOM generation and analysis (GA). For any repository or image that builds an agent application, a self-hosted agent builder or a local MCP server, Safeguard generates an SBOM in SPDX or CycloneDX and analyses it. MCP server libraries, agent SDKs and LLM proxy packages show up as components with versions, like any other dependency. When an advisory lands, you search components rather than repositories. The live post on finding every copy of a vulnerable component walks through the same lookup for an MCP server CVE.

AI-BOM discovery (GA). Safeguard's offering describes AI-BOM discovery as inventorying AI assets across code (SDK imports), cloud AI services, SaaS use and vector databases, with output as an ML-BOM in CycloneDX and the SPDX AI profile. For zero-day work, the useful part is the SDK import view: it tells you which codebases call which AI SDKs, which narrows the search when a flaw lands in an SDK or client library. There is a dedicated post on AI-BOM discovery.

AI assets as first-class objects (GA). The offering files describe Safeguard treating models, agent skill definitions and agent configurations with their tool access as assets in their own right, not just as code. That gives you a place to record which skills and agent configurations exist, alongside the packages.

Agent identity (GA). Safeguard tracks which agent holds what access, at what level. On disclosure day this answers question 4 from the inventory section: if a server is compromised, which agents held it, and with which scopes. That is the list of credentials you may need to rotate.

Step 2: Look up the component in Gold Open Source

Gold Open Source (GA) at gold.safeguard.sh is free and needs no login. Two of its directories are directly relevant here.

• MCP Servers at gold.safeguard.sh/mcp lists servers drawn from the official MCP registry and shows which ones have hosted remote endpoints. Use it to identify what a server is, who publishes it and whether you are dealing with a local package or a remote endpoint, which changes how you contain it.
• Agent Skills at gold.safeguard.sh/skills lists agent skills, from Anthropic's official skills to notable community skills, with their source and description. Use it to check where a skill you found in an inventory came from.

Gold Open Source also provides CVE intelligence with affected and fixed versions for open source packages, which helps with step 1 of the response plan when the vulnerable component is a package. Treat the directory as a starting point for your own review, in line with Anthropic's and OpenAI's guidance that the trust decision is yours. For the full walkthrough of the directory, see Gold Open Source in your workflow.

Step 3: Prioritise with reachability, EPSS and KEV

Reachability analysis (GA) checks whether your code actually calls the vulnerable function in a dependency, and Safeguard's vulnerability views show EPSS scores and CISA KEV status alongside severity. When a flaw lands in a library that dozens of services import, reachability tells you which services exercise the vulnerable path, so containment and fix pull requests start there. Reachability is about code paths. For agent components, also check configuration: whether the vulnerable endpoint or transport is enabled at all. The post on reachability, EPSS and KEV covers how the three signals combine.

Step 4: Contain agent tool traffic

MCP Guardrail (GA) generates guardrail proxy URLs for MCP servers, so agent tool traffic to a server goes through a policy point you control. In a zero-day, that gives you a single place to cut or restrict traffic to an affected server without waiting for every developer to edit their own configuration. It does not fix the server. It narrows what reaches it. See putting a policy proxy in front of MCP servers for setup.

Human approval for agent actions (GA). Safeguard's desktop and mobile apps let a person approve or deny commands that a Safeguard CLI session wants to run on a computer. The mobile demo at the end shows the Allow once, Allow for turn and Deny choices. This is approval for Safeguard's own agent workflows, and it follows the same principle as the MCP specification's human in the loop guidance.

Step 5: Stop vulnerable versions from shipping

Policies, gates and guardrails (GA). Policies generate findings, gates enforce at checkpoints, and gate actions are block, warn and notify, with approval handled through exceptions. Once you know the affected range, a gate that blocks builds carrying it stops a vulnerable MCP server package or agent framework from being reintroduced by a stale branch or a new service. You can describe a policy in plain English and have it turned into a rule; the live post on plain English policies and release gates shows how.

Step 6: Fix with pull requests, under your control

Autonomous remediation (GA) uses Safeguard's Griffin models to open tested, policy gated pull requests that move an affected dependency to a fixed version, on one repository or in bulk. It ships switched off, with every category set to Manual. For a zero-day in a package-based agent component, the useful pattern is to turn it on for the dependency category in the affected repositories only, review the pull requests, and merge in reachability order.

When no fix exists, see the Gold block below for the options, and the live post on what to do when upstream has no fix.

Step 7: Say what is and is not affected

CSAF and VEX upload (GA). If you ship software that bundles an agent framework or MCP server library, customers will ask whether your product is affected. A VEX statement records, per product and version, whether the vulnerability affects it and why. Safeguard ingests CSAF and VEX documents so that "not affected" decisions are tracked with their justification. See ingesting and sharing VEX and CSAF.

Step 8: Ask questions from Claude or ChatGPT

Safeguard's MCP server (GA) lets an assistant query your Safeguard data: projects, vulnerabilities, findings and products. In Claude, add Safeguard from the connector directory, where it is listed as a community connector; for ChatGPT, use the directory route described in Safeguard in your IDE and in the Claude and ChatGPT connector directories. On disclosure day you can ask "which projects include this package at an affected version" and get an answer scoped to your tenant. The same caution from Anthropic and OpenAI applies to Safeguard's connector as to any other: review the access you grant and keep approvals on for actions that change things.

Decision table: what to do, what Safeguard does, what you still own

What Safeguard does not do

Honest limits matter more than usual in zero-day work, because the cost of a false "we're covered" is high.

1. It does not patch hosted services you do not build. If the flaw is in a model provider's platform, a SaaS vendor's hosted MCP server or a desktop client binary, the fix comes from that vendor. Safeguard can help you see who used it and restrict traffic to it; it cannot ship the vendor's patch.
2. It does not see what it is not connected to. SBOMs cover the repositories and images you scan. A developer who installed an MCP server on a laptop through a client's own configuration flow, outside any scanned repository, will not appear unless that configuration is in your inventory. Anthropic's own docs warn that servers can come from several configuration sources.
3. It does not decide for you whether a third-party skill or server is trustworthy. Gold Open Source tells you what a server or skill is and where it comes from. Reviewing a skill's instructions and scripts, as Anthropic's docs recommend, is still your team's job.
4. It does not rotate your credentials. Agent identity shows which agent held which access. Revoking OAuth grants and rotating keys happens in the services that issued them.
5. It does not turn on autonomous fixes by default. Autonomous remediation ships switched off, every category set to Manual. If you want bulk fix pull requests on disclosure day, enable it deliberately for the categories and repositories you choose.
6. Reachability is not a configuration check. Reachability tells you whether code calls a vulnerable function. Whether a vulnerable MCP endpoint is enabled or exposed to the network is a deployment fact you still need to confirm.
7. It does not replace your incident response process. Log review, forensics, legal and customer notification decisions sit with your team and your obligations.

Common mistakes

Treating .mcp.json in the repo as the full list of servers. Anthropic's docs say servers can also come from other scopes, connectors and plugins. Inventory every source, and use managed configuration to restrict what can load.

Assuming a directory listing means a security review. Anthropic says it does not security-audit or manage MCP servers; OpenAI says remote servers have not been verified by it. A listing is a starting point.

Granting broad scopes "to make it work." The MCP security guidance describes how broad up-front scopes multiply the damage of a stolen token. Narrow scopes are a zero-day control you deploy in advance.

Leaving developer tooling running. CVE-2025-49596 in MCP Inspector shows that debugging tools can become remote entry points. Close them when you are done and update them.

Installing servers with an unpinned "latest." You cannot answer "which version are we on" if every launch can fetch a new one. Pin versions and update on purpose.

Treating skills as documents rather than code. Skills can include scripts and can fetch external content. Review and pin them like dependencies.

Patching before containing. If exploitation is known, remove exposure and restrict traffic first; an upgrade rollout that takes a day leaves a day of exposure.

Forgetting credentials after the fix. Upgrading a compromised server does not revoke the tokens it held. If exploitation was plausible, rotate.

FAQ

Can an MCP server have a zero-day?

Yes. An MCP server is software, and it can have flaws that are exploited before a fix exists. Public records already include authentication bypass, command injection and path validation flaws in MCP servers, clients and tooling, and CISA KEV lists an exploited authentication flaw in an MCP endpoint of an LLM proxy.

Are AI agents more likely to be hit by zero-days than other software?

The public sources reviewed here do not show that. GTIG's 2024 review reports a shift toward enterprise technologies, especially security and networking products. Agent infrastructure shares the traits attackers favour: it sits on trust boundaries and holds credentials. The bigger difference is blast radius, not likelihood.

What is the first thing to do when a zero-day affects an MCP server we use?

Find every copy and how it runs (local or remote, which transport, which version), then contain: disconnect or block the server in managed configuration, remove network exposure and turn on approvals. Upgrade when a fix exists, and rotate credentials the server held if exploitation was plausible.

Does Anthropic or OpenAI vet MCP servers for security?

Anthropic's Claude Code docs say it reviews connectors against listing criteria for its directory but does not security-audit or manage any MCP server. OpenAI's docs say remote MCP servers have not been verified by OpenAI. Both put the trust decision on the customer.

Are agent skills a zero-day risk?

A skill can contain scripts and instructions that run with the agent's access, so a vulnerable or malicious skill behaves like vulnerable code. Anthropic's docs recommend using skills only from trusted sources and auditing every bundled file. Pin skill versions and remove ones you do not use.

How do I find which agents use a vulnerable MCP server?

Combine three views: SBOMs for repositories and images that bundle the server package, your client configuration sources for personal and managed installs, and an identity view of which agents hold which access. In Safeguard that is SBOM analysis, AI-BOM discovery and agent identity, all GA.

Should we turn off all MCP servers when a zero-day is announced?

Usually not all of them. Disable the affected server and anything that shares its credentials, then use approvals and tool allowlists to limit the rest while you assess. Blanket shutdowns are a reasonable choice only if you cannot tell which servers are affected.

What does Safeguard's MCP Guardrail do during a zero-day?

MCP Guardrail (GA) generates guardrail proxy URLs for MCP servers, so agent tool traffic goes through a policy point you control. During an incident it lets you restrict or cut traffic to an affected server centrally. It does not patch the server.

Can Safeguard tell me if a vulnerability is a zero-day?

This guide covers response, not discovery. Safeguard's vulnerability views show CVSS, EPSS and CISA KEV status, which tell you how severe a flaw is, how likely exploitation is and whether exploitation is known. Use the vendor advisory and KEV to judge whether a flaw was exploited before a fix.

Does reachability analysis apply to MCP servers?

Reachability applies to code: whether your application calls the vulnerable function in a dependency. If you build an agent that imports an MCP library, reachability helps rank which services to fix first. For a server you only run, check whether the vulnerable feature or endpoint is enabled.

When a fix exists, and when it does not

Agent components are mostly open source packages and container images, so the gaps below apply to them directly: the time before a fixed MCP server or framework version reaches every copy you run, and the time before upstream ships a fix at all. For hosted servers and clients you do not build, the last paragraph of this section is the honest limit.

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 categories include dependencies, licenses, security posture and findings, and each one is set separately. 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.

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

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) 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. 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 connected to the Safeguard MCP server with OAuth, including choosing which tools Claude can use. Choosing tools deliberately is the same allowlist principle this guide recommends for every MCP server, and it is how you would query your exposure from an assistant on disclosure day.

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 Safeguard CLI, and a person approves the command on the phone with Allow once, Allow for turn or Deny. It shows the human in the loop control that the MCP specification recommends, applied to Safeguard's own agent workflow.

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

The third demo is a real CLI session: it reads a finding and its advisory, asks before any command that changes something, edits a dependency to the fixed version, runs install and tests with approval, prints a summary and pushes nothing. The same flow applies when the vulnerable package is an MCP server library or agent framework in a repository you own.

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

To try it on your own agent repositories, download Safeguard or start with the documentation.

Quick check

Sources

• Google Threat Intelligence Group: 2024 zero-day exploitation analysis
• Google Project Zero: 0day "In the Wild" tracker
• CISA Known Exploited Vulnerabilities catalog
• CISA KEV JSON feed
• NVD API record: CVE-2025-6514
• NVD API record: CVE-2025-49596
• NVD API record: CVE-2025-68145
• NVD API record: CVE-2025-54136
• Model Context Protocol specification: Tools
• Model Context Protocol: Security best practices
• Anthropic: Claude Code security
• Anthropic: Connect Claude Code to tools via MCP
• Anthropic: Agent Skills overview
• Anthropic Help Center: Getting started with custom connectors using remote MCP
• OpenAI: Connectors and MCP servers
• OWASP GenAI Security Project: LLM Top 10
• OWASP GenAI Security Project: Agentic AI threats and mitigations
• Gold Open Source: MCP Servers
• Gold Open Source: Agent Skills
• Gold Open Source
• Safeguard docs: MCP integrations
• Safeguard MCP

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