Choose the Guard SDK when you control the MCP server or agent code and can add setup inside it. Choose the Guard Proxy when you want central enforcement in front of servers you do not control, or in a language without an SDK. Both enforce the same policy, and you can run both.
The difference is where enforcement happens
The SDK enforces inside your process, as middleware, before a tool call runs. The proxy sits on the network between your agent and the MCP server. You point the agent at a proxy URL instead of the upstream server, and the proxy evaluates every JSON-RPC call before it forwards the allowed ones.
| SDK | Proxy | |
|---|---|---|
| Needs code changes | Yes, a few lines | No, a URL and header change |
| Server you do not own | Not suitable | Suitable |
| Many servers, one place | Instrument each | One gateway |
| Extra services to run | None beyond your app | Proxy, API, worker, database, cache |
Status you should check first
Safeguard's documentation describes Guard as early access. It says the SDK packages are rolling out and install only from Safeguard's own registry with a pull token, and that nothing is published on public registries. Any public package claiming to be the Guard SDK did not come from Safeguard. Another page says plainly that there is no package to install today. Ask Safeguard about the current state before you plan on it.
That is also a good general habit: an MCP security tool is itself something you install, so apply the same scrutiny. See is there an npm package for the Safeguard MCP server.
How the proxy is put together
The documented deployment has several services. The proxy forwards allowed calls. An API service registers servers, agents and policies and shows audit history. A worker handles background jobs such as audit aggregation. A Postgres database stores servers, agents, policies and audit data. Redis handles caching and job coordination. An optional nginx handles routing and rate limiting.
The example Compose file ships with a placeholder JWT secret that must be replaced outside local testing. The bundled nginx listens on port 80 only and does not terminate TLS, so put TLS in front of it.
Proxy URLs
A registered server is not reachable until a proxy URL record binds a slug to it. A proxy URL can also bind to one agent, so calls are attributed to it, and to one policy, which overrides the default for that slug. One server can sit behind several slugs with different policies, for example lenient for a trusted internal agent and strict for the rest.
Revoking a proxy URL stops new requests resolving against it. Slug lookups are cached for five minutes, so a revoked slug can resolve for a short while.
Decision guide
- Do you write the server? SDK, once available to you.
- Is it third party or vendor hosted? Proxy.
- Do you have many servers and want one control point? Proxy.
- Are you unsure of the SDK timeline? Proxy, or wait.
- Mixed estate? Run both.
Limits to know
The event stream path applies output filtering but not the full request time pipeline of deny rules, rate limits and jailbreak checks. Those run on the message calls your agent posts.
Quick check
Can the proxy protect a vendor hosted MCP server?
That is the case it is designed for. It sits in front without changing the server.
Does it add a database to my stack?
The documented proxy deployment uses Postgres and Redis alongside the proxy, API and worker services.
Sources
- Safeguard docs: Guard proxy deployment
- Safeguard docs: Guard SDK
- Safeguard docs: MCP integrations overview
Last reviewed: 19 October 2026.
