AI Client Access (MCP)

QuantAssure exposes your compliance data to AI tools via the Model Context Protocol — so Claude, Cursor, or any MCP-capable client can query findings, risks, controls, and posture, and (with your approval) make changes, all under your organisation's permissions.

Before You Start

You need two things, and nothing else:

• A QuantAssure account that is a member of the organisation whose data you want to reach. If you can sign in to the dashboard and see your findings, you are ready.
• An MCP client that supports remote servers over HTTP with OAuth — Claude Code, Claude Desktop, and Cursor all do. Clients that only support local stdio servers cannot connect.

You do not need to create anything in advance. There is no "create client" button to find, and no client ID or secret for you to copy. Your AI tool registers itself the first time it connects, and you approve it in the browser. That approval is the moment access is granted, and it is the moment the audit trail records.

Your Endpoint

This is the only value you need:

https://production--quant-gov--quant-assure--4322.apps.quantgovsites.com/mcp

Connect Your Client

Claude Code

Add the server, then start the sign-in from inside Claude Code:

claude mcp add --transport http quantassure https://production--quant-gov--quant-assure--4322.apps.quantgovsites.com/mcp

Then run /mcp in Claude Code and choose to authenticate. Your browser opens to finish the steps below.

Claude Desktop, Cursor, and other clients

Add QuantAssure as a remote HTTP server in your client's MCP configuration:

{
  "mcpServers": {
    "quantassure": {
      "type": "http",
      "url": "https://production--quant-gov--quant-assure--4322.apps.quantgovsites.com/mcp"
    }
  }
}

Restart the client. It will prompt you to sign in the first time it tries to use a QuantAssure tool.

What happens next

Whichever client you use, the sign-in is the same three steps in your browser:

1. Sign in to QuantAssure. If you are already signed in to the dashboard in that browser, this is skipped. If not, you are sent to the login page and returned to the right place afterwards — so use the browser you normally use for QuantAssure.
2. Review the consent screen. It names the client requesting access and lists every permission it is asking for. Nothing is granted until you approve here.
3. Approve. Your client receives its tokens and the connection is live. Ask your assistant something like "what are my open critical findings?" to confirm it works.

What You Are Approving

Access is divided into scopes — findings:read, evidence:write, policies:write and so on — and the consent screen lists exactly the ones being requested. A client granted read-only access stays read-only.

Approval is per person. Your teammates each go through their own consent, and each of their clients acts as them. Everything a client does is attributed to the approving user in the audit log, including the approval itself, recorded with the scopes granted and whether the client registered itself or was registered by an administrator.

If It Does Not Connect

What Clients Can Do

The tool surface covers the whole compliance conversation, not just lookups. A session with your assistant can move from "where do we stand?" to a generated audit pack without leaving the chat:

1. Find the gaps — read tools list and inspect findings (AI-adjusted severities included), risks, action items, framework controls with your org's statuses, and posture summaries.
2. Know when to trust the data — get_posture_summary always carries a coverage block reporting whether your connectors and collectors are healthy, so an agent never reports on your findings or posture score without also knowing whether the underlying collection is degraded. get_connector_health drills into the per-source detail — see Connector Health for what each status means and why it matters.
3. Close them with evidence — create_control_evidence attaches evidence to a control (by code, e.g. ISM-1504), and update_control_status records the applicability and compliance determination with a required rationale, captured in the audit trail.
4. Author the policies behind the controls — create_policy drafts a new policy from markdown, and update_policy publishes a revised version with a change summary. Revisions go through the same version history as the in-app editor: the previous content is archived as a snapshot, never overwritten. list_policies and get_policy read the register, current content, and version history.
5. Run a fresh scan — trigger_run dispatches an Assure Agent collection run for a scope, through exactly the same path as the dashboard's run button.
6. Read the results — get_run_status follows the run through collection and AI triage; once it completes, the read tools pick up the freshly triaged findings.
7. Produce the audit pack — generate_report creates any report type (AI Decision Audit Trail, SLA Compliance, and the rest), and get_report reads back the summary plus a dashboard link to the full report.

Write tools also cover the day-to-day in between: create and update risks and actions, update finding statuses, and keep the asset register current — list_assets reads the inventory, and upsert_asset records an asset by its stable source identity, so repeating the same upsert updates the existing record instead of duplicating it (the same semantics the collection pipeline uses). Every write is audit-logged with your identity.

Each tool group carries its own OAuth scope — for example findings:read, evidence:write, runs:write/runs:read, reports:write/reports:read, and connectors:read for get_connector_health — so the consent screen tells you which of these capabilities a client is actually asking for.

The coverage signal on get_posture_summary is deliberately not behind connectors:read: it lives under the findings:read scope every existing client already holds, so a client you approved before this feature shipped starts seeing it with no re-consent required. It only tells you counts — how many sources are degraded, failing, or have never run. The named list of which sources are affected is more detail than a findings-only client should get for free, so that list — and the full per-source detail behind get_connector_health — only appears once a client has been re-authorised for connectors:read. Existing tokens can't pick this up silently: the client has to go through consent again before either the named list or the tool becomes reachable.

Autonomous Agents

Everything above assumes a person is driving — you sign in, you approve, and the assistant acts on your behalf. An agent that runs on a schedule or in a pipeline has no person to sign in as and no browser to open, so it uses a different credential: an organisation API key with MCP scopes.

1. Go to Organisation → API Keys and create a key. Owners and admins only.
2. Tick the scopes the agent needs. Read-only grants every read scope and nothing else; leaving all of them unticked creates an ordinary REST API key with no MCP access at all.
3. Give the key to your agent as a bearer token — no OAuth, no browser:

   claude mcp add --transport http quantassure https://production--quant-gov--quant-assure--4322.apps.quantgovsites.com/mcp \
     --header "Authorization: Bearer qa_your_key_here"

The important difference is in the audit trail. A person's assistant acts as that person. An agent on an API key acts as itself: entries appear under the key's name with an Agent marker rather than being attributed to whoever created the key. When an assessor asks who changed a control, "the nightly compliance agent" is a truthful answer and a borrowed username is not.

Security Posture of the Endpoint

The MCP surface is hardened as a first-class product API: per-token rate limiting, strict session lifecycle with idle expiry, CSRF-protected consent, request size caps, and org-scoped authorisation on every tool. Your data is only reachable with tokens minted through the consent flow you approved.