Connect Semgrep to ChatGPT: Triage Findings & Generate Fixes

If you need to connect Semgrep to ChatGPT to automate vulnerability triage, trigger AI-powered fix generation, or audit software supply chain dependencies, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between ChatGPT's tool calls and Semgrep's REST APIs. You can either build, host, and maintain this infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL.

If your team uses Claude, check out our guide on connecting Semgrep to Claude or explore our broader architectural overview on connecting Semgrep to AI Agents.

Giving a Large Language Model (LLM) read and write access to a complex Static Application Security Testing (SAST) and Software Composition Analysis (SCA) platform like Semgrep is a significant engineering challenge. You must handle complex, protobuf-derived payload structures, asynchronous task polling, and strict bulk-update requirements. Every time Semgrep updates a schema or introduces a new findings filter, your custom server code must be updated, redeployed, and tested.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Semgrep, connect it natively to ChatGPT, and execute complex security engineering workflows using natural language.

Stop writing boilerplate API integration code. Let Truto generate secure, managed MCP servers for your AI agents in seconds. :::

The Engineering Reality of the Semgrep API

A custom MCP server is a self-hosted integration layer that translates an LLM's JSON-RPC tool calls into vendor-specific REST API requests. While the MCP standard provides a predictable mechanism for models to discover tools, the reality of implementing it against the Semgrep API is painful. If you decide to build a custom MCP server for Semgrep, you own the entire API lifecycle.

Here are the specific integration challenges that break standard CRUD assumptions when working with Semgrep:

Protobuf-Derived Schema Opacity

Semgrep's backend relies heavily on gRPC and Protocol Buffers, with the REST API acting as a translation layer. This results in highly nested, occasionally opaque response structures. Endpoints like list_all_semgrep_deployment_products or list_all_semgrep_deployment_managed_scan_settings return an id alongside an attributes object that contains the actual data. If you write a static MCP schema, the LLM will struggle to understand what fields belong inside the attributes block versus the top-level object. You have to write custom parsers that flatten or strictly define these nested objects for the LLM.

Asynchronous Task Polling

Several high-value operations in Semgrep are asynchronous. For example, triggering an AI-powered auto-fix (create_a_semgrep_issue_fix_job) or generating an SBOM (create_a_semgrep_deployment_sbom_async) does not return the result immediately. Instead, the API returns a 202 Accepted response with a task_token_jwt. Your custom MCP server must implement logic to either poll the tasks endpoint on behalf of the LLM or explicitly expose the task-checking endpoint to the LLM and prompt it to wait and poll until the status resolves to COMPLETED.

Bulk Operation Constraints

When triaging issues, you rarely update a single finding. Semgrep relies on bulk update endpoints (e.g., semgrep_deployment_findings_bulk_update). These endpoints require complex filter bodies. If an LLM decides to mark 50 false positives as ignored, it must construct a precise filter payload rather than simply passing an array of IDs. If your MCP server does not validate the LLM's filter payload before passing it to Semgrep, a hallucinated filter could accidentally bulk-triage the wrong vulnerabilities.

Rate Limits and 429 Errors

Semgrep enforces strict rate limits on its API. Unlike some platforms that absorb rate limit errors under the hood, Truto explicitly passes HTTP 429 Too Many Requests errors back to the caller. Truto normalizes the upstream rate limit information into standard IETF headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset).

Because Truto does not retry, throttle, or apply exponential backoff on your behalf, your client or the LLM framework is responsible for handling the backoff. If you build your own server, you must implement this header parsing and instruct the LLM to pause execution until the ratelimit-reset window clears. Failure to handle this gracefully will result in the LLM assuming the tool call succeeded when it actually dropped.

The Managed MCP Approach

Instead of forcing your security engineering team to build and maintain a custom Node.js or Python application to handle token refreshes, asynchronous polling, and schema parsing, Truto handles the infrastructure layer dynamically.

Truto derives MCP tools directly from Semgrep's API documentation and OpenAPI specifications. Every Semgrep resource endpoint is dynamically mapped into a JSON-RPC tool. Query parameters and request bodies are translated into strict JSON Schemas. When you generate an MCP server through Truto, the resulting URL is a fully authenticated, self-contained endpoint.

When ChatGPT calls a tool, Truto validates the payload against the derived schema, routes the request through a secure proxy layer, attaches the correct Semgrep API token, executes the request against the Semgrep REST API, and returns the normalized response.

How to Generate the Semgrep MCP Server

Truto allows you to generate a secure MCP server URL in seconds. The server is scoped specifically to the connected Semgrep deployment, meaning data is strictly isolated. You can do this via the Truto dashboard or programmatically via the API.

Method 1: Via the Truto UI

This is the fastest method for internal tooling and rapid prototyping.

1. Log into your Truto account and navigate to your Integrated Accounts.
2. Select the connected Semgrep account you want to expose to ChatGPT.
3. Click the MCP Servers tab.
4. Click Create MCP Server.
5. Select your desired configuration. You can filter the available tools by method (e.g., only allow read operations to prevent the LLM from altering configurations) or by tags.
6. Click Generate and copy the resulting MCP Server URL (e.g., https://api.truto.one/mcp/a1b2c3d4e5f6...).

Method 2: Via the Truto API

For production deployments, you can programmatically provision MCP servers for your users on the fly. This validates the Semgrep connection, provisions a secure hashed token in edge storage, and returns the ready-to-use URL.

curl -X POST https://api.truto.one/integrated-account/{integrated_account_id}/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Semgrep ChatGPT Triage Server",
    "config": {
      "methods": ["read", "write", "custom"]
    },
    "expires_at": "2026-12-31T23:59:59Z"
  }'

The API responds with the url required by ChatGPT:

{
  "id": "mcp_srv_9x8y7z",
  "name": "Semgrep ChatGPT Triage Server",
  "config": { "methods": ["read", "write", "custom"] },
  "expires_at": "2026-12-31T23:59:59.000Z",
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f6..."
}

Connecting the MCP Server to ChatGPT

Once you have your Truto MCP URL, you must configure ChatGPT to consume it.

Method A: Via the ChatGPT UI (Custom Connectors)

If you are on a ChatGPT Plus, Team, or Enterprise plan, you can add the server directly through the interface.

1. Open ChatGPT and navigate to Settings -> Apps -> Advanced settings.
2. Toggle Developer mode on (MCP support requires this flag).
3. Under MCP servers / Custom connectors, click Add.
4. Enter a name (e.g., "Semgrep Integration").
5. Paste the Truto MCP URL into the Server URL field.
6. Click Save.

ChatGPT will immediately connect to the server, execute an initialization handshake, and pull down the list of available Semgrep tools.

Method B: Via CLI and SSE Transport

If you are building a custom agent wrapper around the OpenAI API or using a local ChatGPT desktop client that requires a config file, you can proxy the remote Truto MCP URL through a Server-Sent Events (SSE) bridge using the official MCP CLI.

{
  "mcpServers": {
    "semgrep": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "--url",
        "https://api.truto.one/mcp/a1b2c3d4e5f6..."
      ]
    }
  }
}

Hero Tools for Semgrep

Truto exposes the entirety of the Semgrep API, but certain operations provide massive leverage for AI agents. Here are the core tools your ChatGPT agent will rely on to execute security workflows.

1. list_all_semgrep_deployment_findings

This is the primary discovery tool. It allows the agent to fetch code (SAST), supply chain (SCA), or AI-powered scan findings for a specific deployment. The agent can apply filters to isolate high-severity issues or limit results to a specific repository.

"Fetch all open, high-severity findings in the 'backend-api' repository that were introduced in the last 7 days."

2. semgrep_deployment_findings_bulk_update

This tool allows the agent to triage issues in bulk. It accepts filter parameters and applies state changes (like marking false positives as ignored) to all matching findings in a single operation.

"I reviewed these 15 SQL injection findings. They are all inside test files. Bulk update their triage state to 'ignored' and set the reason to 'Test code.'"

3. create_a_semgrep_issue_fix_job

This triggers an automated, AI-powered SAST fix job for a specific issue. Semgrep analyzes the vulnerability, generates a fix, and opens a pull request directly in the repository. (Note: This is currently a Public Beta feature in Semgrep).

"Take finding ID 884723 and trigger a Semgrep fix job to automatically patch the vulnerability and open a PR."

4. list_all_semgrep_deployment_dependencies

This tool allows the agent to retrieve Software Composition Analysis (SCA) data. The agent can list all dependencies, filtering by ecosystem (e.g., npm, pip), transitivity, and known vulnerabilities to audit the software supply chain.

"List all direct dependencies in the 'frontend' project that use the 'npm' ecosystem to check for outdated React packages."

5. semgrep_deployment_scans_search

Allows the agent to search and retrieve metadata about recent Semgrep scans. This is critical for determining if a CI/CD pipeline failed due to a scan error or if a managed scan completed successfully.

"Search the recent scans for the 'auth-service' repo. Did the latest scan complete successfully, or are there errors?"

6. create_a_semgrep_tickets_link

This tool links an existing external ticket (like a Jira issue) directly to one or more Semgrep findings. This bridges the gap between your vulnerability scanner and your engineering task tracker.

"Link Jira ticket SEC-1042 to Semgrep finding IDs 4451, 4452, and 4453."

For the complete inventory of available tools and exact JSON schemas for request bodies, view the Semgrep integration page.

Workflows in Action

Exposing individual tools is useful, but the real power of connecting Semgrep to ChatGPT lies in multi-step, autonomous workflows. Here are two real-world scenarios.

Scenario 1: Automated Triage and Jira Ticketing

When a new service is onboarded, Semgrep often generates hundreds of findings. A security engineer can instruct ChatGPT to perform a first-pass triage, filtering out low-confidence findings and tracking the critical ones.

"Review the findings for the 'payment-gateway' deployment. Find all low-confidence findings and bulk ignore them with the comment 'AI auto-triage: Low confidence'. Then, take all high-severity, high-confidence findings, summarize them, and prepare to link them to our Jira board."

Execution Steps:

1. The agent calls list_all_semgrep_deployment_findings with filters for confidence=LOW and repository=payment-gateway.
2. The agent calls semgrep_deployment_findings_bulk_update, passing the target filters and setting new_triage_state to ignored with the requested comment.
3. The agent calls list_all_semgrep_deployment_findings again, this time filtering for severity=HIGH and confidence=HIGH.
4. The agent presents a summary of the critical findings to the user and (if connected to Jira via another MCP server) generates a Jira ticket, finally calling create_a_semgrep_tickets_link to bind the Jira URL to the Semgrep finding IDs.

sequenceDiagram
    participant User
    participant ChatGPT
    participant Truto as Truto MCP
    participant Upstream as Upstream API (Semgrep)
    
    User->>ChatGPT: "Triage low confidence, escalate high severity."
    ChatGPT->>Truto: call list_all_semgrep_deployment_findings (LOW confidence)
    Truto->>Upstream: GET /api/v1/deployments/.../findings
    Upstream-->>Truto: Return finding records
    Truto-->>ChatGPT: JSON result
    ChatGPT->>Truto: call semgrep_deployment_findings_bulk_update (Set Ignored)
    Truto->>Upstream: POST /api/v1/deployments/.../findings/triage
    Upstream-->>Truto: 200 OK
    Truto-->>ChatGPT: JSON result
    ChatGPT->>Truto: call list_all_semgrep_deployment_findings (HIGH severity)
    Truto->>Upstream: GET /api/v1/deployments/.../findings
    Upstream-->>Truto: Return critical records
    Truto-->>ChatGPT: JSON result
    ChatGPT-->>User: "Ignored 42 low-confidence items. 3 critical items require ticketing."

Scenario 2: AI-Powered Auto-Fix Generation

Instead of just identifying vulnerabilities, engineers can instruct ChatGPT to leverage Semgrep's beta auto-fix capabilities to patch the code and open a PR.

"Look up finding ID 99281. If it's a SAST issue, trigger a Semgrep fix job for it. Wait a few seconds, then check the task status to see if the PR was successfully opened."

Execution Steps:

1. The agent calls list_all_semgrep_deployment_findings (or semgrep_deployment_issues_search depending on the exact id structure) to verify the finding details.
2. The agent calls create_a_semgrep_issue_fix_job, passing the deployment_id and issue_id.
3. Semgrep returns a 202 Accepted with a task_token_jwt.
4. The agent waits briefly, then calls list_all_semgrep_tasks using the task_token_jwt to poll the status.
5. Once the status reads COMPLETED, the agent reads the result block to retrieve the URL of the newly opened pull request and presents it to the user.

Security and Access Control

Exposing a security tool like Semgrep to an LLM requires strict access governance. Truto handles this at the infrastructure level.

• Method Filtering: When creating the MCP server, you can set config.methods: ["read"]. This drops all POST, PUT, PATCH, and DELETE tools during generation. The LLM physically cannot alter triage states or trigger fixes; it can only read findings and scans.
• Tag Filtering: If Semgrep resources are tagged (e.g., "findings", "settings"), you can restrict the MCP server to specific tags. You can prevent the LLM from accessing user management endpoints by only allowing the "findings" tag.
• Mandatory API Authentication: By enabling require_api_token_auth: true, possession of the MCP URL is no longer enough. The client connecting to the server must also pass a valid Truto API token in the Authorization header, tying all LLM actions back to an authenticated internal user.
• Ephemeral Servers: Setting an expires_at timestamp ensures the MCP server automatically self-destructs. The underlying edge storage and database records are purged when the timestamp hits, eliminating zombie integration endpoints.

Integrating Semgrep with ChatGPT manually means fighting protobuf schemas, managing polling loops, and building strict bulk-update payload validators. By offloading this to a managed MCP architecture, your security team can focus on writing better detection rules and triaging vulnerabilities, rather than maintaining boilerplate API code.