Semgrep Guardian enterprise deployment

How to deploy Semgrep Guardian in your enterprise environment.

To roll out Semgrep Guardian organization-wide, standardize the installation process so that the plugin is automatically installed by the developer’s agent, rather than relying on each developer to install it manually.

For individual developer setup, see the Guardian quick start.

Authentication

How you sign in depends on which IDE you use. Claude Code is the recommended setup.

Claude Code

Claude Code uses Semgrep’s hosted remote server and authenticates through OAuth, so developers don’t need to install or run the Semgrep CLI. Each developer completes a one-time browser login when they first use the plugin. Semgrep refreshes access tokens automatically, so developers rarely need to sign in again.

Credentials

OAuth credentials are written to ~/.semgrep/guardian.yml when you sign in through the remote Claude Code plugin.

At startup, Guardian fetches its default authentication method from Semgrep’s remote server. OAuth is currently the default for users who are not yet signed in. This setting is global and not configurable per user.

If OAuth credentials are present in guardian.yml, Guardian uses them instead of any API token in ~/.semgrep/settings.yml.

If you are switching from a local CLI setup to the remote Claude Code plugin, an existing OAuth session in guardian.yml takes precedence over CLI credentials in settings.yml. If scans run under a different account than you expect, check which file contains active credentials. Use semgrep logout to remove CLI credentials from settings.yml.

To sign in with the legacy API-token method in Claude Code, ask the Guardian MCP to log in to Semgrep using the legacy method.

Shared tokens and service accounts

Shared API tokens and service accounts are not recommended. Each developer should authenticate individually through OAuth so Semgrep can associate activity with the correct user.

Semgrep discourages sharing app or API tokens across a team because:

• Revoking a shared token affects every user who depends on it.
• Shared credentials are rate-limited as a single user, which can throttle scans when many developers run Guardian concurrently.
• An API token in settings.yml is only used when no OAuth session exists in guardian.yml. Prefer OAuth for enterprise rollouts.

Other IDEs

Other IDE integrations run Semgrep through a locally installed CLI. Each developer signs in with semgrep login, which opens a browser-based login flow. See Install the Semgrep CLI only if you need one of these setups.

Credentials

Credentials are written to ~/.semgrep/settings.yml when you sign in through semgrep login or set an API token manually. This is the same file the Semgrep CLI uses. If you are already logged in through semgrep login, Guardian can use those credentials.

Shared tokens and service accounts

Shared API tokens and service accounts are not recommended. Each developer should authenticate individually through semgrep login.

Semgrep discourages sharing app or API tokens across a team because:

• Revoking a shared token affects every user who depends on it.
• Shared credentials are rate-limited as a single user, which can throttle scans when many developers run Guardian concurrently.

Use your agent’s built-in enterprise controls

Many coding agents let you pin an approved marketplace or plugin for your whole team. This is the simplest way to make Guardian available, or required, everywhere:

• Claude Code: Require marketplaces for your team
• Cursor: Team marketplaces

Deploy through a mobile device management (MDM) platform for more granularity

Deploy through your MDM platform to scope rollout by device group, or to combine Guardian with other managed configurations deployed through your MDM.

Anthropic maintains a set of MDM deployment examples and best practices that cover managed settings for macOS, including .plist and .mobileconfig profiles through Jamf, Kandji, and similar, and Windows, including PowerShell file deployment or ADMX/registry policy via Intune and Group Policy, along with how to verify that managed settings are applied.

For Claude Code, the managed settings enable the Guardian plugin from the Claude official marketplace for every user, so they don’t have to run /plugin themselves. The same payload is reused across the MDM paths below, just delivered differently (as an MDM .mobileconfig or .plist). Settings deployed through MDM cannot be overridden by users, so the plugin stays enabled.

Guardian is published to the Claude official marketplace (claude-plugins-official), so the payload only needs to enable the plugin. There’s no separate marketplace to declare. The minimal managed-settings payload looks like the following:

{
  "enabledPlugins": {
    "semgrep@claude-plugins-official" : true
  }
}

Ready-to-upload templates with this same payload:

• com.anthropic.claudecode.plist for Jamf and similar preference-domain deployments
• semgrep-marketplace.mobileconfig for Iru and other configuration-profile deployments

These are community-maintained templates and may be unsupported or incorrect. You are responsible for verifying the configuration before deploying it to a fleet.

Iru

Deploy a Custom Profile by uploading the semgrep-marketplace.mobileconfig configuration profile.

1. Download semgrep-marketplace.mobileconfig and update PayloadIdentifier and PayloadOrganization to match your organization.

2. Go to Library > Add Library Item > Custom Profile and upload the updated file.

3. Name the profile Semgrep Guardian - Managed Settings.

4. Assign the profile to your blueprint as needed.

5. Save.

Jamf

Deploy a Custom Settings payload with preference domain com.anthropic.claudecode through a Configuration Profile.

To do so, refer to Jamf’s guide, Deploying Custom Computer Configuration Profiles Using the Application and Custom Settings Payload. Ensure that you use the preference domain com.anthropic.claudecode and the provided com.anthropic.claudecode.plist file as the uploaded property list.

Tips

• Test the rollout on a single machine before pushing to the whole fleet.
• After deploying, confirm that Guardian loaded by running /plugin (it should show as installed and enabled) and that the Guardian MCP appears.
• Users still need to log in to Semgrep once Guardian is installed. See Authentication for how sign-in works, and Connect to your IDE for setup steps.

Get help with a custom rollout

Contact Semgrep or send a message to the #mcp channel on Slack if you would like help building something custom for your MDM or agent fleet.