Secure Semgrep access for AI agents
Query SAST, SCA, and secrets findings from the Semgrep AppSec Platform via Semgrep's official MCP server.
Semgrep findings are a natural fit for an agent: "which critical SAST issues are open on this repo, and which of them are actually reachable?" is a question worth answering in seconds. It is also a catalogue of your unfixed vulnerabilities, including validated secrets. Adding Semgrep here means every query runs through your policies and lands in the audit log, so you know which agent pulled which findings.
Server URL: https://mcp.semgrep.ai/mcp
Setup
- Navigate to Resources and click Add Resource.
- Select Semgrep from the catalog.
- Click the Per-org dynamic registration card. Semgrep is DCR-only, so this is the single option shown — and picking it installs the resource immediately.
No app needs creating on Semgrep's side, and no client ID or secret is required. Each user then authorizes their own Semgrep account (via login.semgrep.dev) the first time an agent calls a Semgrep tool; manage linked accounts in Connections.
Dynamic client registration
Semgrep's remote MCP server supports OAuth 2.0 dynamic client registration, so the gateway registers a fresh OAuth client per org during install. No scopes are requested at registration — each connection is bounded by the authorizing user's own Semgrep AppSec Platform permissions.
See Credential modes for how this compares to the other modes catalog resources use.
Available tools
Semgrep exposes 7 tools. Four are marked deprecated by Semgrep and run scans on code the agent uploads, rather than reading the platform.
| Tool | Description |
|---|---|
semgrep_findings | Fetch SAST, SCA, and secrets findings from the Semgrep AppSec Platform |
semgrep_rule_schema | Get the schema for writing and validating Semgrep rules |
semgrep_whoami | Return the identity of the current Semgrep user |
get_supported_languages | [Deprecated] List languages supported by Semgrep |
semgrep_scan_with_custom_rule | [Deprecated] Run a Semgrep scan with a custom rule on provided code |
semgrep_scan_remote | [Deprecated] Run a Semgrep scan on provided code content |
get_abstract_syntax_tree | [Deprecated] Return the AST for provided code |
semgrep_findings reads historical scan results already uploaded to the platform — it never triggers a new scan. It filters by repository, ref, status, severity, confidence, taint traces, SCA reachability, and secret validation state.
Policy examples
Block the deprecated scan tools
The four deprecated tools send code content to Semgrep on the agent's behalf. Denying them leaves the platform reads untouched:
- In Access Policies, click Add Rule and name it "Semgrep: no ad-hoc scans."
- Set the effect pill to Deny and the MCP scope pill to Semgrep.
- Add the tool patterns
semgrep_scan_*andget_*. - Set the status to Active and click Create.
Those two patterns match exactly the four deprecated tools and nothing else. semgrep_findings, semgrep_rule_schema, and semgrep_whoami are untouched by this rule and keep working via the org's default Allow all rule.
Scope one agent to findings only
An allow rule by itself restricts nothing: every org is seeded with an Allow all rule, so anything your allow doesn't match simply falls through to it. Confining an agent takes a pair of rules:
- Create the deny rule first: effect Deny, MCP scope Semgrep, Agent scope your agent, tool pattern
*. - Then create the allow rule: effect Allow, MCP scope Semgrep, the same Agent scope, tool patterns
semgrep_findings,semgrep_rule_schema,semgrep_whoami.
New rules insert at the top of the list, so creating the deny first leaves the allow above it. Evaluation is first-match-wins: the three findings tools match the allow, every other Semgrep call matches the deny, and neither reaches Allow all.
Keep the Agent scope on both rules. An unscoped deny would block Semgrep for every agent and user in the org.
Next steps
- Create a policy — the full rule editor walkthrough.
- Policies — how first-match-wins ordering and the default Allow all rule interact.
- Data Protection — redact secrets and other sensitive values out of tool responses before an agent sees them.