Connect Sprinto to ChatGPT: Automate Audit Evidence & Staff Scoping

If you need to connect Sprinto to ChatGPT to automate compliance evidence gathering, background verification tracking, and staff scope management, you need a Model Context Protocol (MCP) server. This server translates an LLM's natural language tool calls into structured REST API requests. You can either spend weeks building, hosting, and maintaining this infrastructure internally, or use a managed platform like Truto to dynamically generate a secure, authenticated MCP server URL in seconds.

If your team uses Claude, check out our guide on /connect-sprinto-to-claude-manage-compliance-checks-background-reports/ or explore our broader architectural overview on /connect-sprinto-to-ai-agents-sync-workflow-evidence-staff-scope/.

Giving a Large Language Model (LLM) read and write access to a Governance, Risk, and Compliance (GRC) platform like Sprinto is a high-stakes engineering challenge. You are exposing critical security posture data and audit evidence directly to an AI agent. You have to handle OAuth token lifecycles, map massive JSON schemas to MCP tool definitions, and deal with complex file upload workflows. Every time Sprinto updates an endpoint or deprecates a field, you have to update your server code, redeploy, and test the integration. This guide breaks down exactly how to use Truto to generate a managed MCP server for Sprinto, connect it natively to ChatGPT, and execute complex GRC workflows using natural language.

The Engineering Reality of the Sprinto API

A custom MCP server is a self-hosted integration layer. While Anthropic's open MCP standard provides a predictable way for models to discover tools, the reality of implementing it against vendor APIs is painful. If you decide to build a custom MCP server for Sprinto, you own the entire API lifecycle.

Sprinto is a specialized GRC platform. Its API design reflects the strict requirements of compliance audits. Integrating with it presents specific challenges that break standard CRUD assumptions:

Evidence File Mapping Complexity Uploading evidence to Sprinto is not a standard JSON payload. When an LLM wants to upload a background check or workflow evidence, the API requires multipart file uploads bound to specific primary keys (workflowCheckPk). An AI agent cannot easily construct a multipart/form-data request natively. The MCP server must provide a clear schema that accepts file buffers or base64 strings from the LLM, parses them, constructs the multipart payload, and executes the HTTP request. If your custom server drops the evidenceRecordDate or incorrectly formats the file buffer, the upload will fail and the audit check will remain incomplete.

Audit Scope State Management Marking a staff member as "in scope" or "not in scope" is a highly consequential action in Sprinto. It fundamentally alters the compliance posture of the organization and triggers a cascade of automated security tasks, policy acceptance flows, and training modules. When an LLM executes a tool to change a user's scope, the server must handle the strict schema requirements (like mandatory reason strings for out-of-scope transitions). A custom server must accurately enforce these constraints, or the LLM will generate malformed requests that corrupt your audit boundaries.

Cursor-Based Pagination for Compliance Checks Sprinto relies on cursor-based pagination for listing workflow checks. When an LLM requests a list of open checks, it cannot ingest 10,000 records at once. You have to explicitly instruct the LLM via tool schemas to pass next_cursor values back unchanged to fetch the next set of records. If your MCP server does not inject these explicit prompting instructions into the JSON schema descriptions, the LLM will hallucinate cursor values or fail to traverse the compliance dataset entirely.

Factual Note on Rate Limits and 429 Errors

When interacting with APIs programmatically, rate limiting is inevitable. It is critical to understand how Truto handles this at the infrastructure layer. Truto does not retry, throttle, or apply backoff on rate limit errors.

If your AI agent gets stuck in a loop and fires hundreds of requests to update staff scopes, it will hit Sprinto's API rate limits. When the upstream API returns an HTTP 429 Too Many Requests error, Truto passes that error directly to the caller. Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) following the IETF specification.

The caller - whether that is your custom MCP client application or the framework orchestrating the LLM - is entirely responsible for implementing exponential backoff and retry logic. Do not assume the integration layer will absorb rate limit rejections.

How to Create the Sprinto MCP Server

Truto dynamically generates MCP tools based on the existing documentation and resource schemas defined for the Sprinto integration. This means the MCP server is always in sync with the underlying API capabilities. You can generate a secure MCP server URL in two ways.

Method 1: Via the Truto UI

For operations teams and IT admins, the visual dashboard is the fastest route to an active MCP server.

1. Navigate to the integrated account page for your connected Sprinto instance.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Select your desired configuration. You can filter tools by methods (e.g., read, write) or by tags to restrict the LLM's capabilities.
5. Copy the generated MCP server URL. This URL contains a cryptographically hashed token that authenticates the server without exposing raw credentials.

Method 2: Via the API

For developers automating their AI agent infrastructure, you can programmatically provision MCP servers per tenant.

Make a POST request to /integrated-account/:id/mcp with your configuration block. Truto will validate the requested filters, generate a secure token backed by Cloudflare KV storage, and return a ready-to-use URL.

// POST /integrated-account/{integrated_account_id}/mcp
{
  "name": "Sprinto Compliance Agent MCP",
  "config": {
    "methods": ["read", "write"],
    "tags": ["staff", "evidence"]
  },
  "expires_at": "2026-12-31T23:59:59Z"
}

The API response returns the server record along with the URL:

{
  "id": "mcp-7a8b9c0d",
  "name": "Sprinto Compliance Agent MCP",
  "config": { "methods": ["read", "write"], "tags": ["staff", "evidence"] },
  "expires_at": "2026-12-31T23:59:59Z",
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f67890"
}

Connecting the MCP Server to ChatGPT

Once you have the Truto MCP URL, connecting it to an LLM interface requires zero backend engineering. This makes it simple to bring 100+ custom connectors to ChatGPT using Truto's unified infrastructure. You pass the URL directly to the client.

Method A: Via the ChatGPT UI

If your organization uses ChatGPT Enterprise or Developer modes, you can add the connector directly in the application.

1. In ChatGPT, navigate to Settings > Apps > Advanced settings.
2. Enable Developer mode (MCP capabilities are currently gated behind this toggle).
3. Under MCP servers / Custom connectors, click to add a new server.
4. Set the Name to "Sprinto Compliance" and paste the Server URL generated by Truto.
5. Save the configuration. ChatGPT will immediately perform the JSON-RPC initialization handshake, retrieve the tool schemas, and make them available to the model.

Method B: Via Manual Config File

If you are running a local orchestrator, a custom agentic framework, or integrating with an environment that requires a standard configuration file, you can utilize the official remote Server-Sent Events (SSE) transport adapter.

Define the following in your MCP configuration file (e.g., mcp-config.json):

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

Sprinto Hero Tools for AI Agents

When ChatGPT connects to the Truto MCP server, it receives dynamically generated schemas for the Sprinto API. Here are the highest-leverage tools your AI agent can now execute to manage compliance workflows.

list_all_sprinto_workflow_checks

Retrieves a paginated list of workflow checks currently active in Sprinto. This is the primary discovery tool for finding which compliance controls require attention or evidence. It uses cursor-based pagination, returning an array of edges containing the check's primary key (pk) and title.

"Fetch the first 20 workflow checks in Sprinto. Look for any checks related to 'Background Verification' and return their exact primary keys so we can upload evidence later."

create_a_sprinto_background_verification_report

Uploads a background verification report for a specific staff member. This tool directly satisfies compliance controls requiring proof of background checks before systems access is granted. It maps to Sprinto's specific multipart requirements.

"Upload this summarized PDF text as the background verification report for developer@company.com. Set the verification completion date to yesterday."

create_a_sprinto_workflow_check_evidence

Attaches arbitrary evidence to an existing workflow check. This is the core operational tool for an AI agent handling SOC 2 or ISO 27001 automation. It updates the evidence status of the target check immediately upon successful execution.

"Attach the AWS IAM access review log as evidence to the workflow check with ID 847291. Record the evidence date as today."

sprinto_staff_members_mark_in_scope

Modifies a staff member's account status to "in-scope" for audits. This action pulls the user into the compliance matrix, ensuring Sprinto maps them against configured controls and initiates automated policy acceptance workflows.

"We just onboarded a new contractor. Mark contractor.jane@company.com as in-scope in Sprinto so she receives her security training assignments."

sprinto_staff_members_mark_not_in_scope

Removes a staff member from the audit compliance scope. This instructs Sprinto to stop tracking security tasks for the account. The tool allows the agent to provide a specific reason for the scope removal, which is critical for maintaining an accurate audit trail.

"The marketing intern has completed their rotation. Mark intern.bob@company.com as not in-scope in Sprinto and log the reason as 'End of temporary contract'."

For the complete inventory of available Sprinto tools and their detailed JSON schemas, refer to the Sprinto integration page.

Workflows in Action

Connecting Sprinto to ChatGPT transforms static compliance data into an interactive, agentic workflow. Instead of navigating through multiple dashboard tabs to close out a compliance task, IT admins can execute end-to-end sequences using natural language.

Example 1: The Automated Evidence Uploader

When a new employee finishes their background screening, the HR system often outputs a raw report. An IT admin can drop this report into ChatGPT and ask the agent to handle the Sprinto compliance mapping.

"Here is the background check summary for alice.chen@company.com completed on 2026-03-01. Please upload this report to her profile in Sprinto, then make sure she is marked as in-scope for our SOC 2 audit."

Step-by-step Execution:

1. The agent calls create_a_sprinto_background_verification_report, passing the email alice.chen@company.com, the completion date, and the provided text as the file content.
2. Once Sprinto confirms the upload, the agent calls sprinto_staff_members_mark_in_scope with the same email.
3. The agent reads the returned user object and confirms to the admin that Alice is now in-scope and her background check is logged.

sequenceDiagram
  participant Admin as IT Admin
  participant GPT as ChatGPT
  participant Truto as Truto MCP
  participant Sprinto as Sprinto API

  Admin->>GPT: Upload background check and mark Alice in-scope
  GPT->>Truto: Call create_a_sprinto_background_verification_report
  Truto->>Sprinto: POST /background-verification
  Sprinto-->>Truto: 200 OK (Upload Success)
  GPT->>Truto: Call sprinto_staff_members_mark_in_scope
  Truto->>Sprinto: POST /staff/in-scope
  Sprinto-->>Truto: 200 OK (User Object)
  Truto-->>GPT: Scope Updated
  GPT-->>Admin: "Evidence uploaded. Alice is now in-scope."

Example 2: The Offboarding Scope Adjuster

During an offboarding event, security teams must explicitly remove users from the compliance scope to prevent them from skewing metric calculations for overdue training or policy acceptance.

"Find the open workflow check for 'Quarterly Access Reviews'. Mark departing engineer david.smith@company.com as not in-scope, with the reason 'Employee terminated'. Then upload this access revocation log as evidence to the Quarterly Access Review check."

Step-by-step Execution:

1. The agent calls list_all_sprinto_workflow_checks and parses the paginated edges to find the specific pk for the "Quarterly Access Reviews" check.
2. The agent calls sprinto_staff_members_mark_not_in_scope with David's email and the provided termination reason.
3. The agent calls create_a_sprinto_workflow_check_evidence using the pk discovered in Step 1 and attaches the revocation log.
4. The agent reports that the user is out of scope and the access review check has been updated with fresh evidence.

Security and Access Control

Exposing a GRC platform to an LLM requires strict boundary setting. This is why we focus on zero-data retention MCP servers for building SOC 2 and GDPR compliant AI agents. Truto's MCP implementation provides multiple layers of access control:

• Method Filtering: You can enforce hard boundaries on the server by restricting the HTTP methods. Setting methods: ["read"] ensures the LLM can only query data (like listing workflow checks) but cannot modify staff scope or upload evidence, physically blocking write operations at the routing layer.
• Tag Filtering: Integration resources in Truto are mapped to semantic tags. You can configure the MCP server to only expose tools tagged with "evidence" or "staff", hiding irrelevant endpoints from the LLM's context window and reducing hallucination risk.
• API Token Authentication: By default, the cryptographically hashed MCP URL acts as the authentication mechanism. For enterprise deployments, enabling the require_api_token_auth flag forces the client to also provide a valid Truto API Bearer token, adding a strict secondary authentication layer.
• Automatic Expiration: You can provision temporary access for contractors or transient automated scripts by setting the expires_at field. Truto uses distributed scheduling to automatically tear down the server and revoke KV storage keys at the exact expiration timestamp, ensuring no stale access remains.