Safeguard in Your IDE, Claude's Connector Directory and ChatGPT

Safeguard puts security findings in two places developers already work: an IDE extension for VS Code, Cursor and JetBrains IDEs (GA), and a hosted MCP server (GA) that Claude, ChatGPT, Cursor and other assistants connect to with OAuth. In Claude you can add it straight from the connector directory, where Safeguard has a community listing; in ChatGPT you add it as a custom MCP server. Either way, the assistant acts as the signed-in user and can only call the tools a Safeguard administrator has switched on for the tenant.

That last sentence is the part security teams care about. A finding that lands in a dashboard nobody opens does nothing, and an assistant that can call every tool on a security platform unchecked is a new risk of its own. This post covers how the IDE extension and the MCP server work, step by step from Safeguard's docs, and what an administrator should check before turning either on for a team.

Key takeaways

• IDE extensions (GA). One extension for VS Code and Cursor (Cursor installs it from Open VSX) and a separate plugin for JetBrains IDEs. Both scan dependency manifests as you work, show vulnerabilities inline and offer fix suggestions. Sign-in uses the OAuth 2.0 device flow.
• MCP server (GA). Hosted at mcp.safeguard.sh. Claude uses a dedicated connector URL; ChatGPT, Cursor, VS Code and other clients use the generic endpoint. Nothing to install: Safeguard publishes no npm package or local bridge for it.
• Claude connector directory. Safeguard is listed as a community connector. That is a directory listing, not a partnership with Anthropic.
• ChatGPT. Safeguard's docs describe adding it as a custom MCP server under ChatGPT Plugins, with OAuth, or as a Custom GPT Action with an MCP key. They do not describe a ChatGPT directory listing.
• Tool gating. A new Safeguard workspace exposes six read-only tools. Every other tool stays off until an administrator enables it per tenant under Feature Flags.
• Identity and roles. The assistant acts as you, inside your Safeguard role. Roles, organisations and audit logging come from Safeguard's RBAC model. Agent identity (GA) tracks which agent holds what access.
• In-app Skills, Workspaces and Connectors (early access). These run the other direction: Safeguard's own assistant calling external MCP servers.
• MCP Guardrail (early access). A separate policy layer for MCP servers you build or run yourself. You do not need it just to connect Claude or ChatGPT to Safeguard.
• Also mentioned: SBOM generation (GA), autonomous remediation (GA, ships off with every category on Manual), the Safeguard CLI (GA), Zero AI mode and bring your own model (GA), SAST (early access) and Package Firewall (early access).

Why placement matters: SSDF PW.7 and PW.8 in the editor

NIST's Secure Software Development Framework, SP 800-218 version 1.1 (published February 2022), is the reference most US federal software attestations point back to. Two of its practices deal directly with finding flaws before release.

PW.7 covers reviewing and analysing human-readable code. Task PW.7.1 asks the organisation to decide whether code review, code analysis or both should be used. Task PW.7.2 asks teams to perform that review or analysis against the organisation's secure coding standards and to record and triage every discovered issue and recommended remediation in the development team's workflow or issue tracking system. Among NIST's implementation examples are using a static analysis tool with a human reviewing what it reports, and using automated tools continuously as code is checked in. Example 1 under PW.7.1 notes that the scope may include third-party code.

PW.8 covers testing executable code. Task PW.8.1 asks whether testing should find issues earlier reviews missed. Task PW.8.2 asks teams to scope, design and run the tests, then document results, again recording and triaging issues in the team's workflow.

A third task matters most for dependency findings. PW.4.4 asks teams to verify that acquired commercial, open source and other third-party components comply with the organisation's requirements throughout their life cycles. Its second example is to build automatic detection of known vulnerabilities in software components into the toolchain.

Notice the repeated phrase: in the development team's workflow. The SSDF does not say "in a security dashboard". It says the issues and the remediations belong where developers already do their work. That is the argument for an IDE extension and for an assistant connector, and it is also the test you should hold them to.

Placement changes three things in practice.

1. Time to fix. A vulnerable version flagged on the manifest line where you just typed it costs a minute to change. The same finding discovered in a nightly scan costs a context switch, a ticket and a pull request someone has to schedule.
2. Who sees the finding. Dashboards are read by security staff. Editors are read by the people who can change the code.
3. Evidence. PW.7.2 and PW.8.2 both ask for issues to be recorded and triaged. An inline warning that a developer dismisses leaves no record; a finding that also lives in the platform, with a policy and an owner, does. The editor is where the fix happens. The platform is where the record lives.

The editor alone does not satisfy the SSDF, which also asks for an organisational decision about what gets reviewed and for results to be documented. An IDE extension is one tool inside that process.

What the Safeguard IDE extension does

Safeguard's IDE support (GA) comes as two separately built products. The docs are explicit that they have independent codebases, release cadences and version numbers, so feature coverage differs slightly.

Which IDEs are supported

Cursor installs from Open VSX rather than the VS Code Marketplace. If your organisation mirrors or allowlists extension registries, add Open VSX for Cursor users, or they will not find the extension.

What it scans

Both products scan the same dependency manifest families:

In VS Code and Cursor, any of package.json, requirements.txt, pom.xml, go.mod, Cargo.toml or Gemfile in the workspace activates the extension automatically. Scanning on open and on save are both on by default.

This is the honest scope: the extension is built around dependency manifests. That maps most directly to SSDF PW.4.4 (known vulnerabilities in third-party components) and to the third-party part of PW.7. Safeguard's first-party SAST is a separate engine, labelled early access, and this post does not treat the IDE extension as a replacement for it.

What you see

• VS Code and Cursor. A Safeguard view in the activity bar with Vulnerabilities, SBOM, Compliance and Recommendations panels. Hovering a flagged dependency shows a quick summary and a lightbulb fix. Any panel can export a report for an audit.
• JetBrains. A Safeguard tool window in the bottom panel shows a tree of vulnerable packages. Expand a package to see its CVEs; double-click one for CVSS and CWE details. Vulnerable lines are highlighted inline and colour-coded by severity: red for critical, orange for high, yellow for medium, blue for low.

The VS Code and Cursor extension also generates and exports SBOMs in CycloneDX and SPDX. The JetBrains plugin's documentation does not list SBOM export, so do not plan around it there. SBOM generation as a platform capability is GA.

Fix suggestions in the editor

Both products offer fix suggestions using one of three strategies:

In VS Code and Cursor you hover the dependency, open the lightbulb menu and pick a fix, or run Safeguard: Auto-Fix Vulnerability (Bump Version) or Safeguard: Fix All Vulnerabilities. In JetBrains you place the cursor on the dependency, press Alt+Enter, choose "Fix with Safeguard AI", pick a strategy and review the diff before applying.

Two defaults are worth knowing. The setting safeguard.autoFixOnSave is off by default, and the docs say to enable it with caution. Telemetry (safeguard.enableTelemetry) is opt-in and off by default.

These editor fixes are developer-initiated version bumps. They are not the same thing as Safeguard's autonomous remediation (GA, ships off), which opens pull requests across repositories and ships with every category set to Manual. The Gold block near the end of this post covers that.

The assistant panel in VS Code and Cursor

The VS Code and Cursor extension includes a chat panel for asking security questions in plain language, analysing selected code and inserting a suggested snippet at the cursor. The docs give example questions such as "Why is this package vulnerable?" and "Should I upgrade React to v19?" The JetBrains plugin's documentation does not describe an equivalent chat assistant.

Treat the assistant's suggestions the way PW.7.2 Example 4 treats tool output: a person reviews what the tool reports and decides what to change.

Settings an admin should know

The VS Code and Cursor extension reads its settings from settings.json. Three matter for rollout. safeguard.remediationStrategy sets the default fix strategy (the docs' stricter example uses safe). safeguard.severityThreshold defaults to low, which shows everything. safeguard.includeDevDependencies is on by default; whether it stays on is a policy call, since dev dependencies run on developer machines and in CI. The settings also include toggles for Package Firewall, a separate capability labelled early access that this post does not cover.

How sign-in works in the IDE

Both products authenticate with the OAuth 2.0 device flow, the grant defined in RFC 8628 for clients that cannot easily host a browser sign-in themselves. There is no tenant ID to type in.

1. Run Safeguard: Login from the Command Palette in VS Code or Cursor, or Tools › Safeguard › Login in JetBrains.
2. A browser tab opens at app.safeguard.sh/activate showing a verification code.
3. Sign in and approve the device.
4. Return to the IDE. Your tenant ID is filled in automatically, and tokens are stored in the IDE's secure credential storage.

Device codes expire after a fixed window, 10 minutes according to the extension's own documentation. If you miss it, run the login command again. You can copy the activation link to a different browser or machine if the IDE opened the wrong profile, and approving it there completes sign-in in the original IDE. Each IDE instance holds its own token, so logging out of one does not affect others. Safeguard: Logout clears the stored credentials.

Public-package scanning works without signing in. Features that depend on the Safeguard backend, such as server-side notifications in the IDE, are silently disabled or fall back to local behaviour until you sign in. That matters for rollout: a developer who never signs in still sees some results, but not the ones tied to your tenant.

Installing it

From the docs, exactly:

code --install-extension Safeguard-sh-Inc.SafeguardshIdeExtension

cursor --install-extension Safeguard-sh-Inc.SafeguardshIdeExtension

For JetBrains, open Settings › Plugins, search "Safeguard", install and restart. You can also download the plugin ZIP from the JetBrains Marketplace and use Install Plugin from Disk.

For a longer tour of each panel, see what you see in VS Code, Cursor and JetBrains and which Safeguard IDE extension to install.

The MCP server: Safeguard inside the assistant

The Model Context Protocol (MCP) is an open protocol for connecting AI applications to tools and data. Anthropic's help centre describes it as an open standard created by Anthropic. A remote MCP server exposes tools over HTTP; an assistant that supports MCP can discover those tools and call them during a conversation.

Safeguard runs its own remote MCP server (GA). The docs say that once connected, an assistant can query vulnerabilities, SBOMs, packages, licenses, findings and compliance data, generate remediation plans, compare SBOMs in CycloneDX and SPDX, manage SCM integrations for GitHub, GitLab, Bitbucket and Azure DevOps, run risk scoring and compliance reporting, and run policy gate checks for deployment readiness. The server also supports MCP resources and prompts.

How many tools? Safeguard's docs say "hundreds", and the public pages give different figures, so this post does not quote a number. What matters more for an admin is how few are on by default, covered below.

Endpoints

Safeguard publishes no npm package or local bridge for its MCP server, and the server never reads environment variables such as SAFEGUARD_API_KEY from your machine. The docs say to treat any package that claims to be the Safeguard MCP server as untrusted. Older instructions that start a local bridge with npx are out of date.

How Safeguard is listed in the Claude connector directory

Claude has two ways to add a remote MCP server. Anthropic's own connector documentation describes them: a user or organisation Owner can add any server as a custom connector by entering its URL, with no review by Anthropic; or a server can appear in the Connectors Directory, which Anthropic lists after review so people can find it inside Claude.

Safeguard is listed in Claude's connector directory as a community connector. Be precise about what that means:

• It means you can find and add Safeguard from inside Claude without pasting a URL.
• It does not mean Safeguard and Anthropic have a partnership. There is no partnership agreement, and you should not describe it as one.
• It does not mean Anthropic vouches for what the tools do in your tenant. Anthropic's help article on custom connectors tells users to connect only to servers they trust and to watch for changes in tool behaviour. That advice applies to any connector, directory or custom.

Safeguard's docs note that the directory lives inside Claude and needs you signed in to claude.ai. Opened without a session, the directory link lands on the Claude home page. If the directory is not available on your Claude plan or in your workspace, the manual custom connector steps always work.

Which Claude plans can use connectors

From Anthropic's help centre, as of October 2026:

• Custom connectors using remote MCP are available on Claude, Cowork and Claude Desktop for Free, Pro, Max, Team and Enterprise plans. Free users are limited to one custom connector.
• On Team plans, only Owners and Primary Owners can add custom connectors. On Enterprise plans, Owners, Primary Owners and people with a custom role that includes Manage access to Libraries can add them.
• Once a connector is added to a Team or Enterprise organisation, each user connects to it individually.

Check Anthropic's current help pages before you plan a rollout. Plan rules are Anthropic's to change.

Step by step: add Safeguard to Claude

These steps follow Safeguard's Claude guide and Anthropic's help article on custom connectors.

Route A: from the connector directory

1. Sign in to claude.ai.
2. Open the Safeguard entry in Claude's connector directory. Anthropic's help article describes browsing it from Customize › Connectors and the "+" button, or from the "+" menu in a chat under Connectors › Manage connectors.
3. Select Safeguard and connect.
4. Claude sends you to Safeguard's sign-in page. Sign in at app.safeguard.sh, check the app name and the host the page says the authorisation code will be sent to, then click Authorize access.

Route B: as a custom connector (Pro and Max, and the Free plan's one slot)

1. Create a Safeguard account at app.safeguard.sh, or sign in.
2. In Claude, open Customize › Connectors, click + Add, then Add custom connector.
3. Enter the name Safeguard Security and the URL https://mcp.safeguard.sh/mcp/anthropic, then click Continue.
4. Claude detects that Safeguard signs in with OAuth. Click Continue. Under Authentication, choose Sign in now or Sign in when needed.
5. Under OAuth client, choose Register automatically. Safeguard's docs say Safeguard accepts only client IDs it issued itself. Click Add.
6. When Claude sends you to Safeguard, sign in, check the app name and the authorisation code host, and click Authorize access.

Route C: Team and Enterprise organisations

1. An Owner or Primary Owner opens Organization settings › Connectors, clicks Add, hovers over Custom, and selects Web.
2. They enter the same name, URL and settings as Route B.
3. Members then open Customize › Connectors, find Safeguard Security and click Connect. Each member signs in to Safeguard as themselves.

That last point is the important one for access control. Anthropic's help article explains that because each user connects individually, Claude can reach only what that user can reach, unless the connector uses a shared credential such as an API key, in which case everyone gets that credential's access. With Safeguard's OAuth route there is no shared key, so each person's Claude session is limited by their own Safeguard role.

Claude Desktop

Claude Desktop uses the connectors in your Claude account, so once Safeguard Security is added as above it is available there too. Do not add Safeguard to claude_desktop_config.json; that file is for local servers. Anthropic's help article also notes that Claude reaches remote MCP servers from Anthropic's cloud, not from your device, even in Claude Desktop.

For a longer walkthrough, see connect Claude to the Safeguard MCP server and add the Safeguard connector on a Claude Team or Enterprise plan.

Step by step: add Safeguard to ChatGPT

Safeguard's ChatGPT guide recommends adding Safeguard as a custom MCP server and signing in with OAuth. OpenAI's developer docs describe the same flow under ChatGPT Plugins.

Route A: custom MCP server with OAuth (recommended)

1. Create a Safeguard account at app.safeguard.sh, or sign in.
2. In ChatGPT, open Plugins, select the plus button, then Add custom MCP server.
3. Enter a name (for example Safeguard Security) and a description.
4. Under Connection, enter https://mcp.safeguard.sh/mcp.
5. Configure authentication with OAuth. ChatGPT registers itself with Safeguard, so there is no client ID or key to copy.
6. Review the risk warning, select I understand and want to continue, then Create as a plugin.
7. When ChatGPT sends you to Safeguard, sign in, check the app name and the authorisation code host, and click Authorize access.

OpenAI's docs say account and workspace policies apply to adding and using custom MCP servers. If you do not see the option, the ChatGPT workspace administrator has to enable it. OpenAI's docs also describe a refresh step: after a server's tools change, open the connection under ChatGPT Plugins and select Refresh so ChatGPT sees the current tool list.

Route B: Custom GPT Action with an MCP key

1. In ChatGPT, create a Custom GPT, open Configure, then Actions, then Create new action.
2. Choose Import from URL and enter https://mcp.safeguard.sh/openapi.json.
3. Under Authentication, select API Key, Auth Type Bearer, and paste a Safeguard MCP key.
4. Save the GPT.

Safeguard's docs flag the cost of Route B plainly. The action uses the one key you paste for everyone who can use that GPT, and the key acts as you. Keep the GPT private. The OpenAPI schema also exposes a smaller set of tools than the MCP route.

For more detail, see connect ChatGPT to the Safeguard MCP server.

How OAuth sign-in works, and when to use an MCP key instead

OAuth: what happens under the hood

The MCP specification's authorisation section (current version dated 28 July 2026) treats a protected MCP server as an OAuth 2.1 resource server and the assistant as an OAuth client acting for the user. In plain terms:

1. Discovery. The assistant asks the MCP server where its authorisation server is. The specification requires MCP servers to publish OAuth 2.0 Protected Resource Metadata (RFC 9728) for this.
2. Client registration. The assistant needs a client ID. The specification allows three routes: Client ID Metadata Documents, pre-registration, or Dynamic Client Registration (RFC 7591). Safeguard's docs describe the registration route for both assistants: in Claude you choose Register automatically, and ChatGPT "registers itself with Safeguard".
3. Authorisation code with PKCE. You are sent to Safeguard's sign-in page and approve access. PKCE (RFC 7636) protects this step. The RFC explains that public clients using the authorisation code grant are open to code interception, and PKCE binds the code to a secret only the original client holds. OpenAI's docs say ChatGPT runs the authorisation code flow with PKCE using the S256 method.
4. Audience binding. The specification requires clients to name the MCP server they want a token for (RFC 8707 resource indicators), and requires servers to accept only tokens issued for them. That stops a token for one server being replayed against another.

One standards detail: the July 2026 MCP specification marks Dynamic Client Registration as deprecated and kept for backwards compatibility, with Client ID Metadata Documents preferred. OpenAI's docs say ChatGPT uses Client ID Metadata Documents where the authorisation server supports them, and Dynamic Client Registration otherwise. Safeguard's current docs describe the registration route, which is why the Claude steps say Register automatically.

The step a human must not skip is the consent screen. Safeguard's sign-in page shows the app name and the host the authorisation code will be sent to. Read both. If the host is not the assistant you expected, stop.

MCP keys: for clients that can only send a fixed header

Some MCP clients cannot run an OAuth flow. For those, Safeguard accepts an MCP key:

1. In Safeguard, open Settings › Developer and create a key of the type MCP key.
2. Send it as Authorization: Bearer sg_sk_....

The key is shown once. If you do not see the Developer tab or the MCP key type, API-key access to MCP is turned off for your workspace; it is enabled per workspace by an administrator.

Two properties matter for an admin:

• An MCP key acts as the member who created it, across the whole workspace. Anyone holding it acts as that person.
• Revocation takes effect within a minute. The server checks each key at least once a minute. A revoked key, a key whose owner's account is closed, or a key in a workspace whose API-key access has been switched off stops working within that window.

Which to choose

The short version from Safeguard's docs: use OAuth wherever the client supports it. More detail is in OAuth or MCP key for Safeguard MCP.

Step by step: choose which tools the assistant may use

Tool gating is where an administrator decides how much the assistant can do. There are two layers, and they are independent.

Layer 1: Safeguard's per-tenant tool gating

Every MCP tool on Safeguard's server has its own feature flag of the form mcp:tool:<tool_name>. When an assistant connects, the server works out which tools are enabled for the tenant and uses that same set for two things:

• Discovery. Only enabled tools appear when the assistant lists tools.
• Execution. A call to a tool that is not enabled is rejected.

Because both come from the same source, the docs say an assistant can never see a tool it cannot call, or call a tool it cannot see. A disabled tool does not appear in the list at all.

The default set. A new workspace starts with six read-only tools:

None of these can create, change or delete anything, or handle a credential. Everything else, including tools that add an integration or start a scan, ships disabled. Workspaces created before the default was narrowed may still have four extra tools switched on: safeguard_add_integration, safeguard_scan_repository, safeguard_get_current_context and safeguard_switch_organization. Check yours.

To enable more:

1. Open the Safeguard admin console and go to Feature Flags.
2. Search by tool name, or filter to the mcp category.
3. Toggle the tool on and save. This creates a tenant-specific override.
4. To undo, toggle it back or use Reset to Defaults. The tenant then inherits the platform default again.

Changes reach connected sessions in roughly a minute. If a newly enabled tool still does not show up, the assistant has probably cached its tool list; reconnect or restart the assistant. In ChatGPT that is the Refresh step described above.

What a rejected call looks like. The server returns a normal tool result with an error flag rather than dropping the connection, with text such as: Tool "safeguard_scan_manifest" is not enabled for this tenant. Most assistants show the message as is. Copy the tool name and search for it under Feature Flags.

Two safety properties are worth repeating to an auditor. If tool resolution fails, the server falls back to the small default set rather than exposing more. And gating is scoped to tenant, organisation and product context, so one workspace never affects another.

One limit. Tool gating applies per tenant, not per user. Everyone connecting under the same tenant and context sees the same tool set. Per-user differences come from Safeguard roles (next section), not from tool flags.

Layer 2: the assistant's own tool controls

Both assistants add their own controls on top.

In Claude, Anthropic's help centre describes Tool permissions for a connector, grouped by type such as read-only tools and write or delete tools. Each category or tool can be set to Always allow, Needs approval or Blocked. On Team and Enterprise plans, Owners can set these restrictions organisation-wide, and individual users cannot override them. Anthropic notes these restrictions only narrow access; they never grant more than the source system allows. Users can also switch connectors on and off per conversation from the "+" menu.

Anthropic's guidance on tool approvals is direct: review approval requests carefully and only choose "Allow always" for a server and tool you trust to run unsupervised. One feature deserves particular care. Anthropic's help article says that during Research, Claude can invoke connector tools automatically without further approval, and recommends disabling tools that can write to external applications when using Research with custom connectors.

In ChatGPT, OpenAI's docs say account and workspace policies govern custom MCP servers. Ask your ChatGPT workspace administrator what confirmation behaviour applies to write actions.

The right setup uses both layers. Safeguard's flags decide what exists for the tenant. The assistant's controls decide what runs without a human clicking approve.

What the assistant can see and do: roles, organisations and agent identity

Safeguard's docs put the rule in one line: your assistant acts as you. It can see and do only what your Safeguard role allows, within the tools your workspace has turned on. So the effective permission of any assistant session is the overlap of three things: the tools enabled for the tenant, the signed-in user's role and scope, and whatever the assistant's own tool controls allow.

The organisation hierarchy

Safeguard's RBAC model is a hierarchy of Organization, then Team, then Project, then Asset. The organisation is the top-level tenant boundary, where billing, SSO, the audit log and compliance settings live. Teams group users; projects are units of ownership inside a team; assets are the concrete things such as repositories, images, SBOMs, vendors and workloads. A user can belong to several teams with a different role in each.

Built-in roles

Custom roles can be built from a permissions matrix with restrictions, for example limiting a role to production environments. Permissions can also be sliced by asset labels, which the docs suggest for contractors who should see only one service.

So a developer who connects Claude sees findings on their assigned assets, not the whole organisation's, and an auditor gets read-only answers. An Owner's assistant, with many tools enabled, is the case to think hardest about.

Audit trail

Safeguard's audit log records every state-changing action with who, what, when, where (including client type) and why. It is append-only and cryptographically chained, kept for 90 days by default and configurable up to 7 years for Enterprise, and can be streamed to a SIEM by webhook, S3 export, OpenTelemetry logs or Splunk HEC. That gives you a record of what an assistant session changed, attributed to the user it acted for.

Deprovisioning

When a user is deprovisioned, their sessions and user API keys are revoked. MCP keys follow the same owner rule: the MCP docs say a key whose owner's account is closed stops working within a minute. Service tokens and organisation secret keys are not tied to a user and are not touched by deprovisioning; revoke those separately during offboarding.

Agent identity

Agent identity (GA) is Safeguard's record of which agent holds what access, at what level. As teams connect more assistants and agents to more systems, "which agents can touch this platform, and as whom" becomes an audit question in its own right. Pair it with the per-tenant tool flags and the audit log when you answer that question for a reviewer.

The other direction: Skills, Workspaces and Connectors in the app

Everything above is about outside assistants calling Safeguard. Safeguard's own in-app assistant can also call outside MCP servers. Those features, Skills, Workspaces and Connectors, are early access. Skills are reusable prompts with an optional MCP tool allowlist. Workspaces group conversations with a default model, files, skills and members. Connectors attach external MCP servers as live tools with per-tool permissions. If your team uses them, apply the same review this post describes to each external server you attach.

What an admin should review before turning this on

The OWASP Top 10 for LLM Applications 2025 gives the clearest checklist for this decision. Two entries apply directly.

LLM06:2025 Excessive Agency describes damage done when an LLM-based system acts on unexpected, ambiguous or manipulated output. OWASP names three root causes: excessive functionality, excessive permissions and excessive autonomy. Its mitigations include minimising extensions and their functionality, minimising extension permissions, running extensions in the user's own context, requiring user approval for high-impact actions, and enforcing authorisation in downstream systems rather than trusting the LLM to decide. OWASP calls the last one complete mediation.

LLM02:2025 Sensitive Information Disclosure covers models exposing data they should not. Among its mitigations, OWASP lists enforcing strict access controls on the principle of least privilege and restricting the data sources a model can reach.

Here is how those map to the controls described above, and what stays with you.

A review checklist

1. Decide which assistant vendors are approved. Tool results become part of the conversation with that assistant, under that vendor's terms. If your data rules forbid sending vulnerability data to a given vendor, do not connect it. Safeguard's Zero AI mode and bring-your-own-model options (GA) govern Safeguard's own AI features; they do not change what an external assistant receives once you connect it.
2. Review Feature Flags before the first connection. Confirm the tenant has only the six default tools, or the ones you chose. Check older workspaces for the four legacy tools listed above.
3. Enable write tools one at a time, and only with a named reason. Tools that add integrations, start scans or change settings are where excessive agency becomes real.
4. Pick roles before you pick tools. A developer's assistant should run with the Developer role, not an Admin's.
5. Prefer OAuth. Turn on API-key access to MCP only for a workspace that needs it.
6. Set the assistant's approval controls. In Claude Team or Enterprise, set write and delete tools to Needs approval or Blocked organisation-wide.
7. Check the consent screen host on first sign-in, and watch the audit log for the first few weeks.
8. Plan offboarding. Revoke MCP keys and service tokens explicitly when people leave.
9. Write the decision down. SSDF PW.7.1 and PW.8.1 both ask for an organisational decision on what review and testing happens. Your connector policy belongs in the same record.

Which other assistants can connect

Safeguard's MCP docs list setup guides for these assistants, all using an endpoint on mcp.safeguard.sh:

• Claude (Anthropic)
• ChatGPT (OpenAI)
• Le Chat (Mistral)
• Aleph Alpha
• Microsoft Copilot
• Meta AI (Llama)
• Perplexity
• Cohere
• Gemini (Google)
• Grok (xAI)
• Cursor

The Claude integration page adds Copilot Studio, Gemini CLI and VS Code with GitHub Copilot, plus a general rule: any editor or client that supports remote MCP over Streamable HTTP can add https://mcp.safeguard.sh/mcp.

For Cursor, the docs show this entry for ~/.cursor/mcp.json (all projects) or .cursor/mcp.json (one project):

{
 "mcpServers": {
 "safeguard": {
 "url": "https://mcp.safeguard.sh/mcp"
 }
 }
}

Cursor then opens Safeguard's sign-in page for OAuth. For VS Code with GitHub Copilot, the docs describe adding an HTTP server with the same URL to .vscode/mcp.json.

A guide on Safeguard's docs means the connection is documented, not that every assistant gives an admin the same approval controls.

What Safeguard does not do

• It does not make the directory listing a partnership or an endorsement. Safeguard's Claude listing is a community connector. Anthropic reviews directory listings, but that review is not a security assessment of what the tools do in your tenant. Safeguard's docs do not describe a listing in ChatGPT's directory; there, Safeguard is added as a custom MCP server.
• It does not quote a fixed tool count. The server registers hundreds of tools and the public figures disagree. What a given assistant can use is whatever your tenant has enabled, which by default is six read-only tools.
• It does not gate tools per user. Tool flags apply to the whole tenant and context. Per-user differences come from roles. If you need per-agent policy on MCP traffic, that is a separate product area, MCP Guardrail (early access), aimed at MCP servers and agents you build or run yourself.
• It does not review the assistant's answers for you. Assistants can misread a finding, summarise wrongly or suggest the wrong fix. A person still checks the output before it becomes a change, as SSDF PW.7.2 expects.
• It does not control the assistant vendor's plans, data handling or approval UI. Which Claude or ChatGPT plans can add connectors, how their approval prompts work, and what they retain are set by Anthropic and OpenAI. Check their current documentation.
• It does not make the IDE extension a full code review. The extension is built around dependency manifests. It does not replace your organisation's code review process, and Safeguard's first-party SAST is a separate engine labelled early access. The JetBrains plugin also documents fewer features than the VS Code and Cursor extension, including no chat assistant and no SBOM export.
• It does not enforce sign-in in the IDE. Public-package scanning works without signing in. If you need tenant-backed results everywhere, you have to make sign-in part of onboarding.
• It does not publish a local package for the MCP server. Anything on a package registry claiming to be the Safeguard MCP server did not come from Safeguard.

Common mistakes

Connecting from an Owner account "to test". The assistant inherits the Owner's reach. Test with a Developer or Viewer account first, then widen.

Enabling a whole category of tools because one was needed. Feature Flags let you enable a single tool. Use that.

Choosing the wrong OAuth client option in Claude. Anthropic's form offers three options. Safeguard's docs say to choose Register automatically because Safeguard accepts only client IDs it issued itself.

Following old setup instructions. Older guides started a local bridge with npx, set SAFEGUARD_API_KEY, or added Safeguard to claude_desktop_config.json. Remove all three; the server is hosted and never reads that variable.

Sharing a Custom GPT that holds an MCP key. Everyone who uses the GPT acts as the key's creator.

Expecting a new tool to appear instantly. The server re-checks in about a minute, but many clients cache the tool list for the session. Reconnect or refresh.

Leaving write tools on during Claude Research. Anthropic's guidance is to disable tools that can write to external applications when Research is running, because Research can call tools without asking each time.

Forgetting Open VSX for Cursor. If your organisation restricts extension registries, Cursor users need Open VSX allowed.

Assuming the IDE covers everything because it shows "0 vulnerabilities". The docs list causes: an invalid manifest, unreachable service URLs, or a manifest type outside the supported list. Check before trusting a clean result.

FAQ

Is Safeguard an official Anthropic partner?

No. Safeguard is listed in Claude's connector directory as a community connector. There is no partnership agreement between Safeguard and Anthropic.

Is Safeguard in the ChatGPT app directory?

Safeguard's docs do not describe a ChatGPT directory listing. They describe adding Safeguard to ChatGPT as a custom MCP server under Plugins with OAuth, or as a Custom GPT Action that imports Safeguard's OpenAPI schema with an MCP key.

How do I connect Claude to Safeguard?

Either open Safeguard in Claude's connector directory and connect, or add a custom connector named Safeguard Security with the URL https://mcp.safeguard.sh/mcp/anthropic, choose OAuth with Register automatically, and click Authorize access on Safeguard's sign-in page.

What can Claude or ChatGPT do in Safeguard by default?

On a new workspace, six read-only tools: list products, list projects, get a project, list vulnerabilities, get a vulnerability and list findings. Nothing in that set can create, change or delete anything. An administrator enables more under Feature Flags.

Should I use OAuth or an API key for the Safeguard MCP server?

OAuth wherever the client supports it, which includes Claude, ChatGPT, Cursor, VS Code and Gemini CLI. Use an MCP key only for a client that can send nothing but a fixed Authorization header, and keep it out of source control.

Does the assistant see everything in my Safeguard organisation?

No. It acts as the signed-in user, so it sees only what that user's role and scope allow, within the tools the tenant has enabled. An MCP key acts as the member who created it.

Which IDEs does the Safeguard extension support?

VS Code from the VS Code Marketplace, Cursor from Open VSX, and JetBrains IDEs including IntelliJ IDEA, PyCharm, WebStorm, PhpStorm, Rider, GoLand, RubyMine, CLion, DataGrip and Android Studio from the JetBrains Marketplace.

Does the Safeguard IDE extension change my code automatically?

Not by default. Fixes are applied when you choose them. The safeguard.autoFixOnSave setting can apply fixes on save, but it is off by default and the docs advise caution. Telemetry is also opt-in and off by default.

Getting a finding into the editor or into a Claude conversation only helps if the fix is easy to make next. The tools below are what an assistant or a developer reaches for once the finding is on screen, from the editor's version bump up to pull requests across every repository.

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

The first demo shows the exact flow this post describes for Claude: connecting Claude to the Safeguard MCP server with OAuth and choosing which tools Claude can use. Watch the consent step and the tool choices; those are the two points an admin should review before a team rollout.

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

The second demo is a real Safeguard CLI session. You install it, open the interactive terminal and ask it to fix the lodash CVE in a repo. It reads the finding and the 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, then shows /permissions, /model and /scan. It is the same idea as approval controls in Claude or ChatGPT: the assistant proposes, a person approves each step.

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

To try it yourself, download the apps and extensions at safeguard.sh/download and read the setup guides at docs.safeguard.sh. For a map of every capability with its maturity label, see what Safeguard does today. If you plan to put policy in front of MCP servers you run yourself, see put a policy proxy in front of MCP servers.

Quick check

Sources

• NIST SP 800-218, Secure Software Development Framework version 1.1 (PDF)
• NIST CSRC: SP 800-218 publication page
• OWASP GenAI Security Project: LLM06:2025 Excessive Agency
• OWASP GenAI Security Project: LLM02:2025 Sensitive Information Disclosure
• Model Context Protocol specification: Authorization (2026-07-28)
• RFC 7636: Proof Key for Code Exchange by OAuth Public Clients
• RFC 7591: OAuth 2.0 Dynamic Client Registration Protocol
• RFC 8628: OAuth 2.0 Device Authorization Grant
• Anthropic Help Center: Get started with custom connectors using remote MCP
• Anthropic Help Center: Use connectors to extend Claude's capabilities
• Claude Docs: Building connectors
• OpenAI Developers: Connect and test your plugin
• OpenAI Developers: Authentication for plugins
• Safeguard Docs: IDE Support
• Safeguard Docs: MCP Integrations
• Safeguard Docs: Claude
• Safeguard Docs: ChatGPT (OpenAI)
• Safeguard Docs: Cursor
• Safeguard Docs: Tool availability and gating
• Safeguard Docs: Claude Integration
• Safeguard Docs: RBAC, Teams and Organizations
• Safeguard: Frontier AI integrations

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