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
Credential modes
Semgrep supports per-org dynamic registration only, so there is no app to create on Semgrep's side and no client ID or secret to enter. See Credential modes for how it compares with Use SecureAuth's app and Bring your own app.
Before you begin
- A Semgrep AppSec Platform account that can reach the findings your agents need.
- Administrator access to your Agent Authority workspace, to add the resource.
Setup
- In the Agent Authority console, go to Resources and click Add Resource.
- Select Semgrep from the catalog.
- On Choose how to install Semgrep, click Per-org dynamic registration. Selecting it adds the resource right away with its tools pre-configured.
Dynamic client registration
When you add the resource, the gateway registers its own OAuth client with Semgrep – the credential that lets it sign users in. Semgrep's own AppSec Platform permissions still apply, so an agent can only reach what the person who signed in could already reach.
Verify the connection
The gateway syncs the Semgrep tools automatically. To check the connection end to end, ask your agent to run a request:
Who am I in SemgrepIf your Semgrep identity comes back, the connection is working.
How users connect
Access is per user. Each additional user connects their own Semgrep account the first time their agent calls a Semgrep tool: the gateway returns a sign-in link, the user authorizes once, and the tools work from then on. Users sign in through login.semgrep.dev. Go to Connections to manage linked accounts.
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.
Required scopes
The gateway does not request a fixed scope list for Semgrep. It registers the client without naming any scopes and records the ones Semgrep returns.
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.