MCP Integrations

Safeguard ships its own remote MCP (Model Context Protocol) server, so you can connect your favorite AI assistant directly to your software supply chain security data and ask questions in plain language. Once connected, your assistant can query your vulnerabilities, SBOMs, packages, licenses, findings, and compliance data, generate AI remediation plans, compare SBOMs, manage SCM integrations, and enforce policy gates. The server registers 650+ tools and also supports MCP resources and prompts. Tool availability is governed per tenant — a curated set is enabled by default and administrators enable more per workspace (see Tool availability & gating). Agents can even onboard and procure Safeguard itself — create the account (pre-auth /mcp/onboarding endpoint), sign in, browse regional pricing, compare tiers, start a Stripe checkout, verify activation, and read the user's notifications (see Payments & procurement and the Agents & LLMs guide).

Choose your assistant

Pick your AI assistant below for step-by-step connection instructions. The guides span both US and European model companies. Every page uses an endpoint on the mcp.safeguard.sh host.

Authentication

You need a Safeguard account first. There are two ways to authenticate:

• Sign in with a Safeguard account at https://app.safeguard.sh, then click Approve when your assistant asks to connect. No keys to copy.

• Use an API key generated at https://app.safeguard.sh/settings/api-keys, supplied via the SAFEGUARD_API_KEY environment variable. This is recommended for desktop and headless setups:

  export SAFEGUARD_API_KEY=sg_api_your_key_here

Both paths ultimately hand your assistant a user API key — bound to whichever account approved the connection or generated the key, and inheriting that user's role and permissions (see RBAC & Teams). Two consequences worth knowing up front:

• Keys are short-lived by default. Per RBAC & Teams, user API keys are capped at a 1-hour lifetime unless you explicitly request a longer TTL when generating one. If a previously-working connection suddenly stops authenticating, an expired key is the first thing to check — see the FAQ below.
• Keys are revoked automatically on deprovisioning. If the teammate who generated the key later leaves the org, any assistant still configured with their key loses access at the same moment. For a shared or long-running integration, generate the key from an account that isn't tied to one person.

The server registers 650+ tools for vulnerability scanning, SBOM analysis, AI-powered remediation, SCM integration, and policy enforcement. Which of them your assistant can see and call is controlled per tenant — see Tool availability & gating.

Example prompts

Once connected, plain-language prompts work the same regardless of which assistant you picked above — this is the same starter list used across every per-assistant guide:

List my security projects
Find critical vulnerabilities
Show me all SBOMs
Generate a remediation plan for my npm project
Which packages violate my license policy?

Enforcing policy on MCP tool calls

Connecting an assistant to Safeguard's MCP server and gating which of Safeguard's own 650+ tools it can see (the previous section) is one layer of control, and it only governs Safeguard's own bundled tool surface. Guard is a separate product that adds a second, complementary layer: live enforcement on MCP tool calls in general — including MCP servers and agents you build or operate yourself, not just Safeguard's — evaluated against your organization's live Safeguard policy in real time rather than a fixed allow-list.

Tool gating and Guard are independent mechanisms. Disabling one of Safeguard's own tools under Feature Flags does not create or change a Guard policy, and a Guard policy does not touch Safeguard's tool feature flags. Use Feature Flags to control access to Safeguard's own MCP tools; use Guard when you need the same kind of discovery-time/call-time control over MCP servers and agents you build or operate.

There are two ways to add Guard enforcement to an MCP server or agent:

• Guard SDK — embed policy enforcement directly inside your own MCP server or agent process using the Python, TypeScript, or Go SDK. It authenticates with an organization secret key (generated from Settings → Developer), pulls your live policy in the background, and evaluates every request against an in-memory copy of that policy — no network round-trip to Safeguard on the request path, with decisions designed to complete well under 10ms:

  import os
  from safeguard_sh_guard import Guard
  
  guard = Guard(secret_key=os.environ["SG_SECRET_KEY"], guard_base_url="https://guard.safeguard.sh")
  result = guard.analyze_request(request_body_bytes)
  if result["action"] == "block":
      raise PermissionError(result["reason"])

• Guard Proxy — run Guard as a standalone reverse-proxy gateway in front of one or more MCP servers you don't control the code of (or that are written in a language without a Guard SDK yet). Point your agent's MCP client at a proxy URL instead of the upstream server — POST https://<your-guard-host>/p/{slug}/message — and Guard evaluates every JSON-RPC call before forwarding allowed ones on.

Both approaches enforce the same underlying policy, authored in your Safeguard workspace rather than as files you check into source control, and you can run both at once — the SDK inside servers you own, the proxy in front of the ones you don't. From there:

• Guard Policies covers how rules are authored: each one matches on method, tool name (glob wildcards), and/or agent ID, then resolves to allow, deny, or monitor, evaluated in priority order with first-match-wins. Rules can also carry input filters (block a pattern, cap request size, catch jailbreak phrasing) and output filters (mask PII in responses, redact fields, cap row counts) that run against tool traffic.
• Guard for servers & agents covers registering the MCP servers and agents in your environment as first-class records, so policy can target a specific server or agent, tool discovery can run against a registered server, and an individual agent can be blocked, unblocked, or quarantined directly.
• Guard Audit & Alerts covers the append-only trail Guard writes for every request it evaluates — allow, deny, and monitor alike — plus alert rules that watch signals like jailbreak score, anomaly score, and blocked-request ratio.
• Guard Webhooks covers delivering those alerts to your own endpoint as a signed HTTP webhook, separate from the platform-wide Webhooks & Events system.

FAQ & Troubleshooting

My assistant connects, but the tools menu is empty. First confirm the connection itself succeeded — you completed the Approve step (OAuth) or SAFEGUARD_API_KEY is set to a currently valid key (API key). If the connection is fine, remember tool visibility is gated per tenant too: a fresh workspace only exposes a small curated default set until an administrator enables more. See Tool availability & gating.

I only see a handful of tools, not the full 650+. That's expected, not a bug. Every tenant starts with a curated default set covering the core onboarding loop (add an SCM integration, scan a repository, list projects/vulnerabilities/findings); every other tool stays off until an administrator turns it on per tool under Feature Flags. See Tool availability & gating.

Should I use OAuth or an API key? Use OAuth for web clients like claude.ai where you can click Approve interactively — there's no key to copy, store, or rotate. Use an API key for desktop apps and headless/CI setups where there's no interactive browser step, supplied via SAFEGUARD_API_KEY.

My assistant authenticated fine yesterday, but every call fails today. Check whether the API key expired or was revoked before assuming an outage. Per RBAC & Teams, user API keys are short-lived by default (capped at 1 hour) unless you explicitly request a longer TTL when generating one, and a key is revoked automatically if the user who created it is deprovisioned. Generate a fresh key at https://app.safeguard.sh/settings/api-keys and update wherever SAFEGUARD_API_KEY is set.

Do I need Guard as well as connecting my assistant, or is one enough? They solve different problems. Connecting your assistant plus tool gating controls what Safeguard's own MCP server exposes to that one assistant. Guard is a separate product for enforcing live policy on MCP traffic in general, including servers and agents that have nothing to do with Safeguard's own tool surface. Most teams only need Guard once they're building or operating MCP servers/agents of their own — connecting an assistant to Safeguard alone doesn't require it.

Related

• Tool availability & gating — the per-tenant feature flags that decide which of Safeguard's own tools an assistant can see and call.
• Guard SDK — embed live policy enforcement directly inside an MCP server or agent process you control.
• Guard Proxy — enforce policy in front of MCP servers you don't control the code of.
• Guard Policies — how allow/deny/monitor rules and input/output filters are authored.
• Servers & Agents — register the MCP servers and agents Guard policy can target.
• Audit Trail & Alerts — every decision Guard makes, plus alert rules for jailbreak, anomaly, and blocked-ratio spikes.
• Guard Webhooks — deliver Guard alerts to your own endpoint over a signed webhook.
• RBAC & Teams — how the API keys and OAuth sessions used to connect an assistant are scoped, rotated, and revoked.
• SDKs — official REST SDKs, for teams that want to call the Safeguard API directly instead of through MCP.