Integrations

How integrations work

Everything under Settings → Integrations follows one principle: you make the connection, you scope what it can see, and you can revoke it at any time, on either side. devguard never asks for a vendor password, and nothing is connected behind your back.

The integrations differ in how they connect and in which direction information flows. There are three kinds:

• Two-way sync integrations connect through the vendor's own authorization flow (an app install or an OAuth sign-in) and move work in both directions: devguard creates tickets and notifications in your tools, and status flows back.
• API-key integrations connect with a credential you create at the vendor and paste into devguard. They only ever read: their job is to run automated checks against the vendor's API and turn what they find into evidence on your controls.
• The MCP server points your own AI tooling at devguard; the direction is inverted, with devguard as the read-only data source.

The type badge on each entry tells you which kind you are looking at, and the search and filters narrow the list by name, connection type, or category.

Two-way sync integrations

Sync integrations authorize through the vendor: an app installed on your organization, scoped to the repositories or projects you choose, or an OAuth sign-in. Once connected, they do their work through Actions: automation rules that create tickets in your tracker and send chat notifications when compliance work needs attention, optionally on a recurring schedule from Collections → Schedules. Each action renders a Markdown template into the ticket, and created tickets stay linked in devguard. Webhooks sync status back, so closing an issue in your tracker is reflected on the action's ticket list.

Some sync integrations additionally run read-only checks against the same vendor; for those, everything in the next section applies too, over a separate read-only credential.

API-key integrations

Connecting an API-key integration takes a few minutes: choose the provider, and the connect dialog walks you through creating the credential on the vendor's side: which console page to open, which permissions the checks need, and why. The guiding rule is least privilege: a read-only key or token is always enough, because checks never write. Paste the credential, name the connection, and it is live.

A few points that hold for every API-key integration:

• Credentials are stored encrypted and are never written into check results, logs, or error messages. When something fails, the error names the endpoint and status, never the secret.
• Checks only read. Every request the check runner makes is a read; devguard holds no write access to your vendors and remediates nothing silently.
• Some vendors need more than a header. Where a provider requires signed requests or a token exchange instead of a plain API key, devguard handles the signing or exchange automatically on every run; you still only paste the credential the setup instructions describe.
• Reconnecting replaces the credential. Rotating a key on the vendor side is routine: create the new one, choose Reconnect, paste it. Revoking the credential at the vendor stops the checks immediately.

From checks to evidence

Connecting an integration makes its checks available; it does not enable them. You choose which checks run under Actions, from the catalog. Each check verifies one concrete, named thing (an enforced setting, a protected resource, a policy that exists) and states plainly what passing means.

Before a check can be activated it needs a schedule (from Collections → Schedules), and some checks ask for variables: values the vendor's API needs that only you know, such as an organization identifier or a threshold to enforce. You can also run any check as a test first: a test run shows the full result without writing evidence and without affecting the regular schedule.

Once active, each scheduled run ends in one of three ways:

• Pass: the linked evidence is marked done and its review date resets. Your evidence stays current without anyone uploading anything.
• Fail: the evidence is marked failed and the run produces findings that say exactly what was wrong, so the failure is actionable rather than a red dot. You decide the treatment; nothing pages your team and nothing is auto-remediated.
• Error: the vendor could not be reached or the credential no longer works. Evidence is left untouched: an unreachable API says nothing about your compliance, so it never counts as a pass or a fail. After several consecutive errors the connection is marked unhealthy and the owner is notified by email.

Every run is timestamped and kept, so evidence carries a history rather than a snapshot, which is what an auditor actually wants to see.

Setting up checks with AI

On Business plans, Actions → Build with AI is the fastest way from "we should verify this" to a running check. Describe what you want verified in plain language; the assistant looks up your connected credentials, drafts the check, explains every step, and test-runs it against the real API before anything is saved for good. Prompts that work well as a starting point:

• Set up a check that fails when our status page stops answering over HTTPS.
• We just connected GitHub. Build a check that fails when branch protection is off on the default branch of our main repository.
• Draft a check against our vendor's admin API that fails when single sign-on is disabled. Use the credential we already connected.
• Build a check for our internal API: GET /health must return 200 and the response must report a healthy status.
• Our Divio check needs the organisation UUID: here it is, set it as the variable and test-run again.
• The test run failed. Explain what the API returned and adjust the check so it asserts the right field.

The assistant can draft, revise, and test-run as often as needed; a test run never writes evidence. Activating the result stays yours: pick a schedule, review the draft, and publish it yourself. The AI cannot activate anything.

For catalog providers you don't need the builder at all: connect the integration here, then enable its ready-made checks from the catalog; the setup instructions in each connect dialog cover the vendor side. The regular AI assistant helps here too: ask it to enable a catalog check and it renders a prefilled setup form right in the chat, where you pick the credential and schedule and confirm.

Asking your AI about your checks

Both the built-in AI assistant and any client connected through the MCP server below can read your integration checks: their status, last verdict, last run, consecutive errors, and the evidence they collect. Prompts that work well:

• Which of my integration checks are failing right now, and which evidence do they affect?
• List every active check that has not run in the last seven days.
• Do any checks have consecutive errors? Summarize what is unhealthy and since when.
• Which connected integrations have no checks enabled yet?
• Summarize the latest verdict of every check, grouped by integration.

Remember the distinction from the top of this page: a connected integration with no enabled checks will honestly come back empty. If the assistant reports no active checks, enable some from the catalog first.

Building your own checks

If the catalog doesn't cover a vendor, two paths remain. The generic HTTP and TLS checks probe any endpoint you own (certificate validity, expiry, and redirect behavior) with no vendor credential at all. And on Business plans, Actions → Build with AI drafts a custom check for any API in a guided conversation: the AI proposes and test-runs the check, but only a human can publish it.

If a vendor should be in the catalog and isn't, use Suggest an integration at the bottom of the integrations page; suggestions go straight into our prioritization.

The rest of this page covers the MCP server, which connects your own AI tooling to devguard.

MCP server

devguard exposes your organization's compliance data as a remote MCP (Model Context Protocol) server. You bring your own AI client and model; devguard acts as the data source. Access is read-only: your AI can list and summarize risks, policies, audits, evidence, and more, but it can never change anything.

The server speaks streamable HTTP at:

https://app.devguard.ch/api/mcp/

Authentication

Create an API token under Settings → Tokens. The token is bound to the organization that is active when you create it. Send it as a bearer token:

Authorization: Bearer dvg_your_token

Client setup

The quickest path is in the app: open Settings → Integrations and select Connect your AI on the MCP server card. The dialog carries the same snippets as below with your endpoint prefilled. Replace dvg_your_token with the API token you created above.

Claude Code

Run in your terminal:

claude mcp add --transport http devguard https://app.devguard.ch/api/mcp/ --header "Authorization: Bearer dvg_your_token"

Claude Desktop

Claude Desktop cannot talk to remote HTTP servers directly, so the connection goes through the mcp-remote bridge (requires Node.js). Add this to claude_desktop_config.json (Settings → Developer → Edit config):

{
  "mcpServers": {
    "devguard": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://app.devguard.ch/api/mcp/",
        "--header",
        "Authorization:${AUTH_HEADER}"
      ],
      "env": { "AUTH_HEADER": "Bearer dvg_your_token" }
    }
  }
}

Cursor

Add this to ~/.cursor/mcp.json (or .cursor/mcp.json inside a project):

{
  "mcpServers": {
    "devguard": {
      "url": "https://app.devguard.ch/api/mcp/",
      "headers": { "Authorization": "Bearer dvg_your_token" }
    }
  }
}

Gemini CLI

Run in your terminal:

gemini mcp add --transport http devguard https://app.devguard.ch/api/mcp/ --header "Authorization: Bearer dvg_your_token"

Or add this to ~/.gemini/settings.json manually (Gemini CLI uses httpUrl for streamable HTTP servers):

{
  "mcpServers": {
    "devguard": {
      "httpUrl": "https://app.devguard.ch/api/mcp/",
      "headers": { "Authorization": "Bearer dvg_your_token" }
    }
  }
}

Run /mcp inside Gemini CLI to list the connected servers.

VS Code

Add this to .vscode/mcp.json (or your user MCP configuration):

{
  "servers": {
    "devguard": {
      "type": "http",
      "url": "https://app.devguard.ch/api/mcp/",
      "headers": { "Authorization": "Bearer dvg_your_token" }
    }
  }
}

Windsurf

Add this to ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "devguard": {
      "serverUrl": "https://app.devguard.ch/api/mcp/",
      "headers": { "Authorization": "Bearer dvg_your_token" }
    }
  }
}

To verify the connection, ask your assistant to list your organization's risks.

What your AI can do

• Tools: 44 read-only queries covering assets, risks, policies, controls, frameworks and coverage, vendors, people, audits, findings, reviews, deadlines, evidence, processes and their runs, and the knowledge base search.
• Resources: read single entities by URI, e.g. devguard://risk/vendor-lock-in or devguard://evidence/42.
• Prompts: five ready-made workflows — gap-analysis, summarize-risks, draft-risk-treatment, audit-prep, and policy-review.

Example prompts

Once connected, these read well across the whole workspace, in your own tools:

• Which controls have no evidence newer than 90 days?
• Summarize our open findings by severity and owner.
• Are all integration checks passing? Flag anything unhealthy.
• Which policies are overdue for their annual review?
• Prepare a briefing for the upcoming audit: open findings, failing checks, and stale evidence.
• Which vendors are due for reassessment this quarter?
• Run the gap-analysis prompt for ISO 27001.

Limits and notes

• MCP requests do not count against your AI request quota; your own model does the thinking.
• Each token is limited to 1000 requests per hour. A single tool call spends three of them (it authenticates the token, then resolves your session and your memberships), so a token is good for roughly 330 tool calls per hour.
• Internal record identifiers are redacted from responses; entities are referenced by name, slug, or short ID.