Policy Proxy for MCP Servers: Safeguard MCP Guardrail (Early Access)

Safeguard MCP Guardrail (early access) lets you put a policy proxy between your AI agents and the MCP servers they call, including servers you do not own. You point the agent at a Guard proxy URL instead of the server, and every JSON-RPC request is checked against your organization's live policy, then allowed, denied or let through and flagged for monitoring, with each decision written to an audit trail.

The caveats matter as much as the answer: a proxy governs only the traffic routed through it, parts of the feature are still being wired up, and an extra network hop has latency and availability costs.

Key takeaways

• MCP Guardrail is early access. In Safeguard's docs it is delivered by Guard, which runs as a self-hosted reverse proxy (Guard proxy, early access) or as an in-process library (Guard SDK, early access, packages rolling out to registry.safeguard.sh with a pull token).
• Agent identity is GA at the platform level. Inside Guard, a proxy URL can be bound to one registered agent so every call through it is attributed to that agent in policy, risk scores and audit events.
• The proxy applies one default policy per organization to each JSON-RPC call. Rules match on method, tool name (glob) and agent ID, and resolve to allow, deny or monitor. Input filters and output filters (for example PII masking and row limits) run when a rule matches.
• Monitor is the safe starting point. Unmatched requests fall through to monitor, and an organization with no default policy has all traffic flagged for monitoring rather than blocked.
• Every decision is an audit event, allow, deny and monitor alike, retained 90 days by default on a self-hosted deployment. Alert rules are defined in the schema but, per the docs, not yet evaluated or delivered.
• Tool-poisoning detection is not available yet, according to the Guard SDK docs.
• Enforcement covers only routed traffic. Local stdio servers, direct connections that skip the proxy, and actions an agent takes outside MCP are out of its sight.
• Related Safeguard capabilities named in this post: the Safeguard MCP server (GA), the CLI (GA), supply chain policies, gates and guardrails (GA), AI Gateway (early access), the desktop app and mobile apps (early access, beta).

What goes wrong when agents call MCP tools directly

The Model Context Protocol gives an AI application a standard way to discover and call tools exposed by a server. A client sends JSON-RPC 2.0 messages such as tools/list and tools/call; the server runs the tool and returns a result that goes back into the model's context. Three properties make this traffic riskier than ordinary API calls.

First, the caller is a model. The decision to call delete_record or send_email is produced by an LLM reading a context window that can contain web pages, tickets, file contents and earlier tool results. Anything in that context can steer the next call.

Second, the server holds real credentials. An MCP server that wraps a billing system, a database or a ticketing tool usually holds a credential with real reach. Safeguard's own use case page puts it plainly: MCP servers are a new class of privileged dependency.

Third, many servers are not yours. Teams increasingly connect agents to vendor hosted or community MCP servers. You cannot add checks to code you do not run, and you often cannot see what a remote server does with the arguments it receives.

The result is a control gap: the application team owns the agent, a vendor owns the server, and nobody owns the decision about which tool calls are acceptable for which agent.

What the MCP specification's security guidance lists

The MCP project publishes a Security Best Practices document alongside its authorization specification. The current version (protocol revision 2025-11-25) covers these attacks and mitigations:

Two points from the primary text are worth stating exactly. On token passthrough, the guidance says MCP servers "MUST NOT accept any tokens that were not explicitly issued for the MCP server." The authorization specification repeats this and adds that a server calling upstream APIs must use a separate token and must not pass through the one it received. It also requires clients to send the resource parameter defined in RFC 8707 (Resource Indicators for OAuth 2.0, February 2020) so tokens are bound to their intended audience. The Security Best Practices page tells readers to use it together with RFC 9700, the OAuth 2.0 Security Best Current Practice (BCP 240, January 2025).

On stdio, the guidance says the transport "is not inherently vulnerable", but a local proxy that spawns MCP servers as child processes can turn a client-side bug into code execution. The Guard proxy is a network reverse proxy with HTTP or SSE upstreams, a different shape, which also means it has no answer for stdio servers at all.

Where "tool poisoning" fits

The topic plan for this post assumed the MCP Security Best Practices page names tool poisoning. The current version does not use that term. The closest material is elsewhere:

• The MCP tools specification says clients must treat tool annotations as untrusted unless they come from trusted servers, and that there should always be a human in the loop able to deny tool invocations.
• Its security considerations say servers must validate inputs, enforce access controls, rate limit invocations and sanitize outputs, and clients should validate results and log tool usage for audit.
• The OWASP Agentic Security Initiative's guide describes a "Tool Misuse via Descriptive Exploitation" scenario, where misleading tool descriptions in a shared registry lead an agent to call a tool under false assumptions.

So tool poisoning is a real concern, framed as untrusted tool metadata. Safeguard's Guard SDK docs state that checking tool names and descriptions for hidden instructions is not available yet.

How OWASP frames the same risks

The OWASP Top 10 for LLM Applications 2025 lists LLM06:2025 Excessive Agency, defined as the vulnerability that lets damaging actions happen in response to unexpected, ambiguous or manipulated model output. OWASP names three root causes: excessive functionality, excessive permissions and excessive autonomy. Its mitigations read like a requirements list for a tool-call proxy:

• Minimize extensions and their functionality, so the agent can only reach the tools it needs.
• Minimize extension permissions in downstream systems.
• Require user approval for high-impact actions.
• Complete mediation: implement authorization in downstream systems rather than relying on the LLM to decide, and validate every request made through extensions against security policies.
• Log and monitor extension activity, and rate limit to slow down undesirable actions so monitoring can catch them.

LLM01:2025 Prompt Injection is the usual trigger. OWASP describes indirect prompt injection as instructions hidden in external content, such as websites or files, that change model behaviour when the model reads them. In an agent, the change shows up as a tool call.

The OWASP Agentic AI Threats and Mitigations guide (Agentic Security Initiative, version 1.1, December 2025) adds a threat model for agents. The entries that map to tool traffic are:

NIST's Generative AI Profile, NIST AI 600-1 (published 26 July 2024 as a companion to the AI RMF), lists Information Security and Value Chain and Component Integration among the twelve risks unique to or worsened by generative AI. The second one, untraceable integration of upstream third-party components, describes a fleet of unreviewed MCP servers well. NIST AI 600-1 also asks organizations to test and manage risks related to rollover and fallback technologies (GV-6.2-006), which is the right frame for the availability question a proxy raises.

What these documents agree on is the control pattern: a mediation point that sees each tool call, applies a policy the model cannot override, attributes the call to an identity and keeps a record.

What Safeguard MCP Guardrail does

In Safeguard's offering, MCP Guardrail (early access) is described as generating guardrail proxy URLs for MCP servers so you can govern agent tool traffic. In the product docs, that capability is delivered by Guard, which has two deployment modes that enforce the same policy:

• Guard proxy (early access): a standalone, self-hosted reverse proxy that sits between agents or MCP clients and your MCP servers. It applies your Safeguard policy to every JSON-RPC call as it passes through, with no change to the MCP server's code.
• Guard SDK (early access): a library that enforces the same policy inside your own application, MCP server or agent process, as middleware. The docs say the SDK packages are rolling out to registry.safeguard.sh, install only from there with a pull token from your Safeguard workspace, and are never published to public registries.

Do not confuse Guard policies with Safeguard's supply chain guardrails. The docs are explicit that Guardrails and Enforcement (policies, gates and guardrails, GA) gates CI, registries and deployment against SBOM, CVE, license and signing rules with BLOCK, WARN and AUTO_FIX effects. Guard policies are a separate system that governs live MCP tool calls at request time with allow, deny and monitor actions.

The request path, step by step

According to the Guard proxy docs, a request flows like this:

1. The agent sends a JSON-RPC request to a proxy URL path, /p/{slug}/message, with a bearer API key scoped to your organization.
2. The proxy resolves the slug to a proxy URL record, which names the upstream server, optionally a bound agent, and optionally a pinned policy.
3. If a bound agent's status is blocked, the call is rejected before policy evaluation.
4. The proxy evaluates the request against the policy: rules in priority order, first match wins, with input filters run on the request.
5. Allowed calls are forwarded to the upstream MCP server using the credential configured on the server record. Denied calls never reach the upstream.
6. The response comes back through the proxy, where output filters such as PII masking can apply.
7. The decision, the scores and the request details are published to an audit stream asynchronously.

Proxy URLs: one server, several policies

The proxy URL is the unit you hand to an agent. The docs describe it as a record with these fields: server_id (required), an optional agent_id, an optional policy_id that overrides the org default for every call through that slug, the slug itself, a human label such as claude-dev, and a status of active or revoked.

So one upstream server can sit behind several proxy URLs, for example a lenient policy for a trusted internal agent and a stricter one for everything else. Revoking a slug stops new requests without touching the server or agent records.

One detail to plan around: in the current release, proxy URLs are provisioned as their own record and are not created automatically when you register a server. The docs say to ask your Guard admin or deployment owner to create one and bind it to the right agent and policy.

What a policy can express

A Guard policy is an ordered list of rules, managed in your Safeguard workspace. There is no local policy file. The docs list what a rule can match on:

There is no separate server-name condition today. To scope a rule to one server's tools, match on that server's tool names or naming convention, or scope by agent ID if only one agent calls that server.

Each rule resolves to one action: allow, deny (with an optional reason returned to the caller) or monitor (let it through, flag it for review). A rule can also carry a rate limit, a jailbreak threshold and an anomaly threshold. If a rule does not set the thresholds it inherits organization defaults, which the docs give as 0.75 for jailbreak and 0.80 for anomaly unless your deployment is configured otherwise.

Filters do the content work:

The docs show this example of rules in a policy, which is the shape the workspace UI edits:

"rules": [
  {
    "id": "block-jailbreak-support-tools",
    "name": "Block jailbreak attempts against support tools",
    "description": "Deny anything that looks like a prompt-injection attempt on customer-support tool calls",
    "action": "deny",
    "deny_reason": "Request blocked: matched jailbreak/prompt-injection pattern",
    "match_methods": ["tools/call"],
    "match_tools": ["support_*"],
    "input_filters": [
      { "type": "jailbreak_check" },
      { "type": "max_length", "max_length": 8000 }
    ],
    "jailbreak_threshold": 0.75,
    "priority": 100
  },
  {
    "id": "default-pii-mask",
    "name": "Mask PII and limit exported rows",
    "action": "allow",
    "match_methods": ["tools/call"],
    "match_tools": ["export_*", "query_*"],
    "output_filters": [
      { "type": "pii_mask" },
      { "type": "column_redact", "columns": ["ssn", "internal_notes"] },
      { "type": "row_limit", "limit": 500 }
    ],
    "priority": 10
  }
]

Against OWASP LLM06, the first rule is complete mediation on a family of tools; the second limits excessive functionality on export, whatever the model decides.

How policy changes reach the proxy

The docs say both the SDK and the proxy continuously pull the live policy for your organization in the background, so a saved edit reaches every running instance within moments with no restart. If an instance cannot reach Safeguard to refresh, it keeps enforcing the last policy it fetched, rather than failing open or failing closed.

Only one policy is ever live: the one marked is_default: true for your organization. You can store others, but they are inert until made default. The docs warn that if more than one is marked default, which one loads is not guaranteed.

What a denied call looks like to the agent

A blocked call still returns a JSON-RPC error body rather than an HTTP error page, so a standard client can parse it. JSON-RPC 2.0 reserves the range -32000 to -32099 for implementation-defined server errors, and Guard's codes sit inside it:

The docs' example of a denial:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32000,
    "message": "request denied by policy: destructive tool calls require monitor review"
  }
}

Proxy or SDK: when the docs recommend each

The Guard proxy docs give a direct rule:

The SDK avoids a network hop, and the docs list packages for Node.js, Python, Java, .NET and Go. But it is still rolling out, and the docs tell you not to create the organization secret key it uses (sg_sk_... from Settings, Developer) until your packages are available, because an unused credential is only risk. The docs also warn that older revisions of the page gave install commands for public registries, that those packages were never published by Safeguard, and that anything installed that way should be removed and the machine reviewed.

The proxy, by contrast, needs no code change inside the agent. The docs note that most MCP clients need only a URL and header change.

Step by step: create a guardrail, route a client, test allow and deny

This walkthrough follows the Guard proxy, Guard policies and Servers and Agents docs. Guard is early access, so the deployment artifacts and proxy URL provisioning come through the early access program. Where the docs show the management API on your Guard host rather than a screen, this post describes the outcome instead of reproducing those calls.

1. Join the early access and get the deployment. Guard proxy deployments are self-hosted. The docs describe a Compose file at deployments/docker-compose.yml in the Guard repo, and the Guardrails and Enforcement page notes that Safeguard's Helm chart for Guard is an OCI chart at oci://registry.safeguard.sh/charts/guard, in early access, and requires a Safeguard pull token. Ask for access before you plan a date.

2. Bring up the stack. From the deployments/ directory the docs show:

   docker compose up -d
   

   This starts postgres, redis, the proxy (port 8080), the management API (port 8081), a worker for audit processing, and an optional nginx in front. Before anything except local testing, set your own JWT_SECRET; the bundled default is a placeholder named dev-secret-change-in-production. The bundled nginx config only listens on port 80, so terminate TLS in front of the stack yourself.

3. Register the upstream MCP server. You create a server record with a name, the real upstream URL, the transport (http or sse) and how the proxy should authenticate upstream (none, bearer, basic or api_key, with matching auth_config). Guard then runs tool discovery (tools/list) every 5 minutes and a reachability check every minute, by default.

4. Register the agent. Create an agent record with a name, description and metadata such as team and environment. It always starts active. This record gives the agent an identity inside Guard, with counters, scores and a status.

5. Get a proxy URL bound to that server, agent and policy. Proxy URLs are separate records. Have your Guard admin create one with a clear label and slug, bound to the server, to the agent, and if needed to a specific policy.

6. Write the policy in your Safeguard workspace, in monitor first. Start with a small set of rules on the tools you care about, with action monitor, distinct priorities, and the filters you plan to enforce later. Mark the policy as the default. Remember that unmatched requests are monitored anyway, so a missing rule is visible rather than silently allowed.

7. Point the client at the proxy. Replace the server URL in your MCP client configuration with the proxy URL path, and add the bearer key. The docs show the request shape:

   curl -X POST https://<your-guard-host>/p/billing-mcp/message \
     -H "Authorization: Bearer sg_live_..." \
     -H "Content-Type: application/json" \
     -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"..."}}'
   

   Keys are prefixed sg_live_ in production and sg_test_ in test; keep them in a secrets manager.

8. Test an allowed call. Call a tool your policy allows. The docs say an allowed call returns the upstream server's own JSON-RPC response, unchanged except for any output filters. If you set pii_mask or row_limit, check the response shows the masking or cap.

9. Test a denied call. Switch one rule to deny with a clear deny_reason, save it, wait a moment for the background policy pull, and call a matching tool. You should get HTTP 403 with code -32000 and your reason in the message. Then check that the upstream server's own logs show no call, because denied requests never reach it.

10. Read the audit trail. Within about a second, both calls should appear as audit events with action, rule_id, rule_name, deny_reason, the scores and the agent_id you bound. If they do not, check that the worker service is running.

How audit events and alerts are recorded

The Guard audit docs describe an append-only trail with one event for every request Guard evaluates, regardless of outcome. Each event records:

• identifiers for the organization, agent, server and proxy URL;
• the request ID, JSON-RPC method and tool name;
• the action (allow, deny or monitor) and the rule that matched, with any deny reason;
• a risk score, jailbreak score and anomaly score;
• the input parameters and output result as JSON, after output filters;
• PII types detected and fields redacted;
• latency, status code and any error.

The docs define the per-request risk score as a weighted blend of the jailbreak score (60%) and anomaly score (40%), capped at 1.0.

Writes are asynchronous: events go to a Redis stream and the worker batches them into Postgres every 100 events or every second by default, so logging adds no latency but a new event can take about a second to appear. Events are partitioned by month and deleted after 90 days by default (AUDIT_RETENTION_DAYS on a self-hosted deployment).

The audit views filter by action, method and date range, and a timeline gives hourly or daily counts by outcome with average latency and risk. There is no agent or server filter on the event query today, so filter those client-side.

Alerts are not live yet. The docs are unusually direct about this. An alert-rule schema exists (trigger types for jailbreak score, anomaly score, blocked ratio, server down and a blended risk score), and the intended delivery is a signed webhook. But as of the docs' writing there is no endpoint to create alert rules and no running Guard process evaluates traffic against them. Until that ships, alerting is your job: pull the audit timeline on a schedule, or ship events to your own monitoring, and alert there.

The Guard trail is separate from the workspace audit log under Settings, Audit Logs, which records administrative activity such as who changed a policy.

How this ties to agent identity

Safeguard's agent identity capability (GA) is about knowing which agent holds what access, at what level. Inside Guard, that becomes concrete in four places:

1. Registration. Agents are created explicitly. Guard does not discover agents on the network.
2. Binding. A proxy URL can carry an agent_id, so every call through that slug is attributed to that agent for policy targeting, risk scoring and audit. Without a binding, calls are not attributed to any specific agent.
3. Policy. Rules can match on agent ID, so the same tool can be allowed for one agent and denied for another.
4. Lifecycle. An agent can be blocked, unblocked or quarantined through dedicated actions. Status is checked before policy evaluation, so a blocked agent is rejected whatever the rules say.

This answers OWASP T8 and T9 in part: every decision carries a named agent and a matched rule. It does not prove who is behind a proxy URL. Anyone holding the organization API key and the slug is attributed to the bound agent, so use one proxy URL per calling agent, as the docs suggest, and revoke quickly.

Roll out in monitor first, then enforce

Guard's defaults already lean toward visibility. Unmatched requests are flagged for monitoring, and an organization with no default policy has all traffic monitored rather than allowed or blocked. Use that.

Jailbreak and anomaly signals are scores against thresholds, and jailbreak_check matches known phrasing, so expect misses and false positives and tune thresholds per rule.

For the same staged approach on LLM prompts and responses rather than MCP tool calls, see the companion post on Safeguard AI Gateway (early access) and the OWASP LLM Top 10, and the earlier piece on Guard runtime guardrails, monitor then enforce.

Latency and availability trade-offs to plan for

A proxy adds a hop and a dependency. Safeguard positions Guard's added latency as low, and the audit events record latency_ms for every call, so measure it in your own environment rather than relying on any marketed figure. These are the trade-offs the docs make visible:

• Policy evaluation is local to the instance. Policies are pulled in the background and the last fetched policy keeps being enforced if Safeguard is unreachable. A Safeguard outage should not stop enforcement, but a policy edit made during an outage will not take effect until the pull resumes.
• Audit does not sit on the hot path. Events go to Redis and are batched later. If the worker is down, traffic still flows and is enforced, but you lose the audit pipeline until it recovers.
• Slug resolution is cached for 5 minutes. A revoked slug can keep resolving for up to 5 minutes. Count that window in your incident response time for a leaked key.
• Default rate limits exist at the edge. The bundled nginx config limits /p/ to 300 requests per minute with a burst of 50, and the management API to 60 per minute. A busy agent fleet behind one deployment can hit these; adjust them deliberately.
• The proxy becomes a dependency for every routed agent. If the proxy is down, routed agents cannot reach their tools. Run more than one proxy instance behind your load balancer, monitor the unauthenticated /health endpoint, and decide in advance, as NIST AI 600-1 GV-6.2-006 suggests for fallback technologies, what the fallback is. Pointing agents straight at upstream servers during an outage removes the control, so make that a documented, approved break-glass step rather than a quiet default.
• Upstream errors are not policy errors. A 502 with code -32004 means Guard allowed the call and the upstream failed, often a wrong auth_config.

On transports: the proxy exposes a POST path for messages and a GET path for an SSE stream. The current MCP transport specification (2025-11-25) defines stdio and Streamable HTTP, which uses a single endpoint, and documents how servers can stay compatible with the older HTTP plus SSE transport from protocol version 2024-11-05. Test your specific client against the proxy URL during early access rather than assuming a URL swap is enough.

What a proxy cannot see

This is the section to read twice. A proxy enforces policy on the traffic routed through it, and nothing else.

• Local stdio servers. A server the client launches as a subprocess and talks to over standard input and output never touches the network. The proxy's upstream transports are http and sse; stdio is not among them.
• Direct connections. If the agent's configuration still has the upstream URL, or a developer adds a server locally, calls skip the proxy. Guard does not scan your network for MCP servers; the docs say server records are created explicitly. Pair the proxy with network egress rules so agents can reach MCP servers only through it.
• Actions outside MCP. An agent with a shell, a browser or direct API credentials can act without calling an MCP tool. The proxy never sees it.
• What the upstream server does with an allowed call. Once a call is forwarded, the server's own behaviour, its credentials and its downstream calls are outside Guard. Output filters see the response, not the side effects.
• The SSE stream's request checks. The docs say the /p/{slug}/sse stream applies output filtering, but deny rules, rate limiting and jailbreak detection run on the JSON-RPC calls posted to /p/{slug}/message.
• Tool metadata. Per the SDK docs, tool-poisoning detection on tool names and descriptions is not available yet. Tool discovery stores the tool list, but nothing yet flags a description that tries to instruct the agent.
• Your OAuth design. Confused deputy, session hijacking and authorization URL validation live in your MCP servers and clients. A tool-call proxy does not fix them.

Requirement vs what Safeguard does vs what you still own

What Safeguard does not do

Be clear on these before you plan a rollout.

1. It is not generally available. MCP Guardrail, the Guard proxy and the Guard SDK are early access. Some internal materials label MCP Guardrail as GA; this series uses the stricter early access label, and so should your procurement documents. The Guard Helm chart is early access and needs a Safeguard pull token.
2. It does not enforce on traffic that skips it. See the section above on what a proxy cannot see.
3. It does not discover MCP servers or agents for you. Servers and agents are registered explicitly. Tool discovery runs only for servers you have registered.
4. It does not alert yet. The alert-rule schema exists, but rule creation and evaluation are not wired up, per the docs. Build alerting on the audit trail yourself for now.
5. It does not detect tool poisoning yet. Checking tool names and descriptions for hidden instructions is listed as not available in the SDK docs.
6. It does not write good policy for you. Rules need tuning, and score thresholds and pattern checks will miss novel phrasing and flag some legitimate calls.
7. It is not a human approval step. The MCP tools spec says there should be a human able to deny tool invocations. The proxy returns allow, deny or monitor; approval prompts belong in your client or app.
8. It does not fix MCP server security. Session handling, OAuth consent, token audience checks and SSRF protections remain the server and client owners' job, per the MCP Security Best Practices.
9. It does not replace the supply chain guardrails. Guard policies govern live tool calls. Gating builds and deployments on SBOM, CVE, license and signing rules is the separate Policies, Gates and Guardrails capability (GA).

Common mistakes

• Leaving the upstream URL reachable. If agents can still reach the MCP server directly, the proxy is advice, not a control. Lock egress so the proxy is the only path.
• Marking two policies as default. The docs say which one loads is not guaranteed. Keep exactly one.
• Typos in rule fields. Unknown fields are silently ignored. A rule using match_tool instead of match_tools matches every tool. Check against the docs' example before you switch to deny.
• Equal priorities. Order among rules with the same priority is unspecified. Give every rule a distinct value.
• Shipping the placeholder secret. Override JWT_SECRET before anything beyond local testing, and terminate TLS in front of the bundled nginx.
• Treating revocation as instant. Slug resolution is cached for 5 minutes. Rotate the API key as well when a slug leaks.
• Forgetting what the audit trail stores. Events hold input parameters and output results as JSON, after output filters. Set pii_mask and column_redact with that in mind, and treat the audit store as sensitive data with its own access controls.
• Retrying 403s. A policy denial is final for that request. Retry loops burn tokens and fill the audit trail with noise.
• Installing a "Guard SDK" from a public registry. Safeguard does not publish Guard to public registries. The docs say any package there claiming to be it did not come from Safeguard.

FAQ

Is Safeguard MCP Guardrail generally available?

No. Treat MCP Guardrail, the Guard proxy and the Guard SDK as early access. Some internal materials list MCP Guardrail as GA, but the capability catalog and the Guard docs describe it as early access, and the stricter label applies.

Can I put a guardrail in front of an MCP server I do not control?

Yes, that is the case the docs recommend the proxy for. You register the vendor or community server as an upstream, provision a proxy URL, and point your agents at the proxy URL. The server's code is untouched. You still need to stop agents from reaching the server directly.

Does the Guard proxy work with local stdio MCP servers?

No. The proxy forwards to upstream servers over http or sse. A server launched as a local subprocess over stdio does not pass through it. For local servers, follow the MCP Security Best Practices guidance on consent and sandboxing.

Does Guard detect tool poisoning in MCP tool descriptions?

Not yet. The Guard SDK docs state that checking a tool's name and description for hidden instructions is not available yet. Guard does run tool discovery on registered servers, so you can see what tools exist, but reviewing their descriptions is still a manual task.

Can Guard send alerts when an agent is blocked repeatedly?

Not today. The docs describe an alert-rule schema, including a blocked-ratio trigger, and webhook delivery, but no endpoint to create rules and no process that evaluates them yet. Build alerts from the audit timeline in your own monitoring until that ships.

How does MCP Guardrail relate to agent identity?

Agent identity (GA) is Safeguard's record of which agent holds what access. In Guard, agents are registered records with a status, counters and scores. Binding a proxy URL to an agent attributes every call through it to that agent, lets rules target it, and lets you block or quarantine it in one action.

Is MCP Guardrail the same as Safeguard's MCP server?

No. The Safeguard MCP server (GA) is how assistants such as Claude query Safeguard and trigger actions in your workspace. MCP Guardrail governs traffic between your agents and other MCP servers. You might use both: one to operate Safeguard from an assistant, the other to police the tools your own agents call. The companion post on Safeguard in your IDE and in assistant connector directories covers the first.

Further reading on the blog

• How MCP Guardrail works
• What is an MCP guardrail, in plain language
• MCP Guardrail and agent identity
• MCP guardrail buyer questions: what to ask a vendor
• Human approval for agent actions in the Safeguard desktop and mobile apps

Keep the software behind the proxy patched

MCP servers are software too, built from open source dependencies and often shipped as container images, and the Guard proxy itself runs as containers you deploy. Governing what agents call does not remove the need to keep that software patched, so the remediation options below still apply to the servers and services behind your proxy.

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

None of these demos shows the Guard proxy itself. They show the agent-facing side of Safeguard: which tools an assistant may use, and when a human approves an action.

The first demo connects Claude to the Safeguard MCP server (GA) with OAuth and shows choosing which tools Claude can use. That is the client-side half of excessive agency: deciding up front which tools an assistant gets. MCP Guardrail adds the server-side half, a policy check on each call.

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

The second demo is a real desktop app session (early access, beta). The CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with the upgrade done and tests passing. It shows the human-in-the-loop control the MCP tools specification asks for, which a proxy does not provide on its own.

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

The third demo is a real Android session (early access, beta): send work to a computer running the CLI and approve the command on the phone with Allow once, Allow for turn or Deny. Those three choices are a useful model for deciding which agent actions need a person, and which can be left to a monitored policy.

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

To try Safeguard, download the apps and CLI at safeguard.sh/download, and read the Guard pages in the Safeguard docs before you plan a rollout.

Quick check

Sources

• Safeguard docs: Guard Proxy Deployment
• Safeguard docs: Guard SDK
• Safeguard docs: Guard Policies
• Safeguard docs: Audit Trail and Alerts
• Safeguard docs: Servers and Agents
• Safeguard docs: Guardrails and Enforcement
• Safeguard use case: MCP Server Security
• Model Context Protocol: Security Best Practices (2025-11-25)
• Model Context Protocol specification: Authorization (2025-11-25)
• Model Context Protocol specification: Transports (2025-11-25)
• Model Context Protocol specification: Tools (2025-11-25)
• JSON-RPC 2.0 Specification
• OWASP Top 10 for LLM Applications 2025: LLM06 Excessive Agency
• OWASP Top 10 for LLM Applications 2025: LLM01 Prompt Injection
• OWASP Agentic Security Initiative: Agentic AI Threats and Mitigations
• NIST AI 600-1: AI RMF Generative AI Profile
• NIST AI 600-1 full text (PDF)
• RFC 9700: Best Current Practice for OAuth 2.0 Security
• RFC 8707: Resource Indicators for OAuth 2.0

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