MCP Integration

This guide explains how to configure MCP (Model Context Protocol) integration so AI-powered agents - such as those in n8n, Cursor and other MCP-compatible tools - can create identity verification challenges, check their status, revoke SaaS sessions, and contain endpoints without requiring custom integrations in your ITSM or SOAR systems.

MCP server URL: https://challenge.veraproof.io/mcp
Use this URL when adding the Challenge MCP server in your MCP client. All MCP requests (create challenge, get challenge status, revoke sessions, contain devices) are sent to this endpoint with a Bearer token from the OAuth 2.1 flow.

Why MCP Integration?

The MCP integration lets AI agents work with Challenge using a standard, secure protocol:

No bespoke integrations required – AI agents can create and check challenges through the MCP server instead of building and maintaining separate webhook or API integrations inside each ITSM or SOAR tool.
OAuth 2.1 + PKCE – Clients authenticate with short-lived tokens and optional client secrets; no long-lived API keys to rotate in agent configs.
Scoped access – You control which clients can create challenges (challenges:create), read status (challenges:read), revoke sessions (sessions:revoke), and contain devices (devices:contain).
Centralized revocation – Deleting an MCP client in the admin console immediately invalidates all of its tokens.
Session revocation – Agents with sessions:revoke can revoke sessions across enabled session connectors when MCP revocation is enabled for the tenant.
Device containment – Agents with devices:contain can lock MDM devices or network-isolate EDR endpoints via enabled device connectors when MCP containment is enabled for the tenant.

You can support both human-driven workflows (e.g., analysts in Cursor, Claude, Goose, etc) and automated ones (e.g., Tines, Torq, n8n, SOAR playbooks, etc) through the same Challenge tenant.

Overview: Two Ways to Configure MCP Clients

Challenge supports two ways to register MCP clients:

Approach	Best for	How it works
Dynamic Client Registration (DCR)	Quick setup; tools like Cursor that support “connect with OAuth”	The client starts authorization with `client_id=dynamic`. An admin or owner approves once; Challenge creates a new OAuth 2.1 client and completes the flow. No pre-registration.
Static (pre-registered) client credentials	Automation, scripts, or tools that need a fixed `client_id` and `client_secret`	You create an “MCP Integration” in the admin console and get `client_id` and `client_secret` once. The client uses these with the token endpoint (and PKCE if supported).

Both approaches use the same OAuth 2.1 authorization server, token endpoint, and MCP API; only how the client is created differs.

Option 1: Dynamic Client Registration (DCR)

Use DCR when your MCP client can start an OAuth flow without pre-configured credentials. The client will use client_id=dynamic (or no client_id) and a redirect URI (e.g. https://localhost:5000/oauth/callback). Only tenant admins or owners can complete this flow as they are authorizing a new MCP client for the tenant.

Steps (admin or owner)

Log in to the Challenge admin console at challenge.veraproof.io.
In your MCP-capable tool (e.g., Cursor), add the Challenge MCP server. For Cursor, add a DCR MCP server entry in your MCP settings (e.g. in Cursor Settings → MCP or your MCP config file) with the Challenge MCP URL:
```
{
  "mcpServers": {
    "veraproof_challenge_dcr": {
      "url": "https://challenge.veraproof.io/mcp"
    }
  }
}
```
Then start the flow to connect (e.g. add or open the server). When prompted for authorization, you will be sent to Challenge’s OAuth authorize URL.
On the Challenge consent screen, review the requested scopes (e.g. challenges:create, challenges:read, sessions:revoke, devices:contain) and click Allow.
You are redirected back to the client. Challenge has created a new OAuth 2.1 client for your tenant and completed the authorization. The client can now obtain access tokens and call the MCP tools.

The new client appears under Integrations → MCP Integrations as a “dynamically registered” client with the clients name in brackets. You can delete it at any time (see Deleting MCP clients).

Requirements for DCR

You must be logged in as a tenant admin or owner before trying to connect the MCP client.
The client must send a valid redirect_uri (e.g. https://... or cursor://anysphere.cursor-mcp/oauth/callback).
The client must send a PKCE code_challenge (and code_challenge_method, e.g. S256).

Option 2: Static (Pre-Registered) Client Credentials

Use this when you need a fixed client_id and client_secret for scripts, automation, or MCP clients that cannot use the interactive DCR flow.

1. Create an MCP Integration

Log in to the Challenge admin console at challenge.veraproof.io.
Go to Integrations → MCP Integrations (OAuth 2.1 + PKCE).
Click Add MCP Integration.
Fill in:
- Display Name: A friendly name (e.g. “SOAR MCP Client” or “Automation”).
- Redirect URIs: One per line. Allowed: https://..., http://localhost... (or http://127.0.0.1), and for Cursor: cursor://anysphere.cursor-mcp/oauth/callback.
Click Create (or equivalent).
Copy the Client ID and Client Secret – the secret is shown only once. Store them securely.

2. Use the Credentials

Your client uses the standard OAuth 2.1 flow:

Authorize: Send the user (or service account) to the authorization URL with your client_id, redirect_uri, scope (e.g. challenges:create challenges:read sessions:revoke devices:contain), PKCE code_challenge/code_challenge_method, and response_type=code.
Token: After the user approves, exchange the code at the token endpoint using client_id and client_secret (e.g. client_secret_post) and the PKCE code_verifier.
MCP: Use the returned access_token as a Bearer token when calling the MCP server (create challenge, get challenge status, revoke sessions, contain devices).

Discovery and metadata:

MCP server URL: https://challenge.veraproof.io/mcp
Authorization endpoint: https://challenge.veraproof.io/oauth/authorize
Token endpoint: https://challenge.veraproof.io/oauth/token

If you lose the client secret, use Regenerate client secret for that MCP integration in the admin console. The new secret is shown once; all existing tokens for that client remain valid until they expire or the client is deleted.

Deleting MCP Clients

You can remove MCP clients from the admin console in two ways, depending on how they were created.

Pre-registered (static) MCP integrations

Go to Integrations → MCP Integrations.
Find the integration and click Delete.
Confirm.

Effect: The OAuth 2.1 client linked to that integration is deleted. All tokens and authorization codes for that client are revoked. Any further request that uses a token issued to that client will receive 401 Unauthorized.

DCR-created (dynamic) clients

Go to Integrations → MCP Integrations.
In the list of dynamically registered clients, click Delete next to the client you want to remove.
Confirm.

Effect: Same as above: the client record is deleted, all of its tokens and authorization codes are removed, and any existing access tokens for that client immediately become invalid (401 with reason such as “Invalid or expired token”).

Why this matters

Deleting an MCP client is the way to revoke access for that client (e.g. a lost device, decommissioned tool, or former vendor). There is no separate “revoke” step; deletion revokes all access for that client immediately.

Scopes and Capabilities

MCP clients can be granted the following scopes (typically at authorization time):

challenges:create – Create identity verification challenges (standard or Slack-based) via MCP tools.
challenges:read – Read challenge status via MCP tools.
sessions:revoke – Revoke user sessions via MCP tools (requires session revocation to be enabled and Allow revoke via MCP integration checked on Integrations).
devices:contain – Lock MDM devices or network-isolate EDR endpoints via MCP tools (requires device containment to be enabled and Allow containment via MCP integration checked on Integrations).

These align with the same capabilities as the webhook APIs (create challenge, get challenge status), plus session revocation and device containment for incident-response workflows.

For Slack-based challenges (integration_type: slack), slack_user_id and requester_email are optional. If both are omitted, the Challenge Slack app’s bot user is used as the requester (same behavior as the webhook API). Slash-command challenges always use the user who ran /challenge as the requester.

MCP tools reference

`create_challenge`

Create an identity verification challenge. Requires challenges:create.

Parameter	Required	Description
`target_user_id`	One of target fields	Target user identifier
`target_user_email`	One of target fields	Target user email
`context`	No	Reason or message for the challenge
`callback_url`	No	URL to receive a webhook when the challenge completes
`requester_id`	No	Requester identifier (default: `mcp`)
`requester_email`	No	Requester email
`integration_type`	No	`webhook` (default) or `slack`
`slack_user_id`	No	For Slack: requester Slack user ID (optional; bot user used when requester omitted)
`expiry_minutes`	No	Per-challenge lifetime in minutes (1–10080). Omit to use the tenant default.

Example arguments:

{
  "target_user_email": "user@example.com",
  "context": "Verify identity before granting access",
  "expiry_minutes": 30
}

`get_challenge_status`

Parameter	Required	Description
`challenge_id`	Yes	Challenge UUID

Session revocation MCP tools

When sessions:revoke is granted and MCP revocation is enabled:

Tool	Description
`revoke_sessions`	Revoke sessions for a `username` across enabled integrations. Optional `integration_targets` list; omit to target all enabled connectors. Optional `reason`.
`list_session_revocation_capabilities`	Returns supported and enabled integration keys and targeting defaults for the tenant.

Device containment MCP tools

When devices:contain is granted and MCP containment is enabled:

Tool	Description
`contain_device`	Lock MDM devices or network-isolate EDR endpoints. Requires `action` and `lookup`. Optional `integration_targets` list; omit to target all enabled connectors. Optional `reason` and `dry_run`.
`list_device_containment_capabilities`	Returns supported and enabled integration keys, actions, lookup types, and targeting defaults for the tenant.

`contain_device`

Requires devices:contain.

Parameter	Required	Description
`action`	Yes	`lock_device` (MDM), `network_contain` (EDR), or `release_containment` (EDR)
`lookup`	Yes	Object with `lookup_type` and `value`
`lookup.lookup_type`	Yes	`user_email`, `hostname`, `serial_number`, or `provider_device_id`
`lookup.value`	Yes	Lookup value (email, hostname, serial, or provider device ID)
`integration_targets`	No	List of connector keys (e.g. `jamf`, `crowdstrike`); omit for all enabled
`reason`	No	Free-text reason recorded on the request
`dry_run`	No	When `true`, resolve targets without taking action (not billed)

Example arguments:

{
  "action": "network_contain",
  "lookup": {
    "lookup_type": "hostname",
    "value": "alice-mac.corp.example"
  },
  "reason": "SOAR containment after failed challenge",
  "integration_targets": ["crowdstrike"],
  "dry_run": false
}

The tool returns a JSON device containment request with request_id, overall status, and per-integration, per-device results (including lock PINs in result_metadata when applicable). See Device Containment for actions, outcomes, and connector setup.

Email lookups against EDR-only tenants: If you target EDR connectors (crowdstrike, phorion) by user_email without an enabled MDM connector, Challenge returns an error. Use hostname or serial_number, or enable an MDM connector so Challenge can resolve the user’s devices.

Example authorization scope string:

challenges:create challenges:read sessions:revoke devices:contain

Test session revocation and device containment with Responder before granting sessions:revoke or devices:contain to production automation clients.

Best Practices

Use DCR for interactive tools when possible for quick and easy set up; use static credentials for scripts or tools that don’t support DCR.
Store client secrets securely – Never commit them to version control or share them in plain text.
Limit scopes – Grant only the scopes each client needs.
Remove unused clients – Delete MCP integrations or clients when they are no longer used so tokens cannot be reused.
Regenerate secrets if compromised – Use “Regenerate client secret” for the affected MCP integration and update your automation.

Support

For issues or questions about MCP or OAuth 2.1 configuration, contact support@veraproof.io or refer to the main documentation.