Claude is the harness. ISMS Copilot is the GRC specialist.

People ask us whether ISMS Copilot competes with Claude. It does not. Claude is very good at running work: reading a repo, editing files, calling tools, keeping a plan. We do not want to be that. We want to be the thing it calls when the work turns into compliance.

So here is the pattern we recommend. Your agent is the harness. Claude Code, Cursor, Codex, OpenCode, Grok: whichever one you already live in. ISMS Copilot is the GRC specialist it delegates to, over MCP. The harness runs the job. The specialist answers the compliance part and hands the answer back.

Where a generic agent plus a skill file falls short

The common alternative is one agent doing everything, with a skill file of framework notes in its instructions. That can work. For the big, stable frameworks, a well-maintained file is hard to beat, and we say so in the docs.

It has three weak spots.

• The file goes stale. Frameworks get revised and renumbered. Your file does not know. Someone has to notice and fix it, and that someone is you.
• The framework text lives in your transcript. To answer from a skill file, the agent loads it into its own context. So does every policy or control excerpt it pastes in to reason over.
• There is no second reader. The agent that drafted the policy is the same one checking it. A specialist gives you a second pass against curated framework references. That is a mechanism, not a measured advantage: we have not benchmarked it.

A specialist changes the shape of the work. It does not make your agent smarter. The full reasoning, including where a skill file is still the right call, is in Why connect a specialist.

What actually happens when your agent delegates

Your agent calls ISMS Copilot's MCP tools to start a conversation or send a message. It passes the question. Then the work happens on our side.

• Framework knowledge stays on our side. The curated framework modules are loaded where the answer is written, not in your agent's context.
• Your workspace is read on our side. Your memories and, when the conversation is scoped to a workspace, that workspace's memories and files are read by ISMS Copilot. The raw files are not copied into your agent.
• The drafting happens on our side. A long policy or a gap analysis is written by the specialist, not assembled token by token in your harness.
• The answer comes back. Your agent receives the reply, not the material behind it, and carries on with the job.

The useful consequence: context that never enters your transcript is never re-sent on later turns. Your agent does not carry the full framework text or your raw workspace files forward through the rest of the session, because it never received them.

One honest caveat. The answer itself is read by your agent. It is input to your harness like anything else. If the answer quotes or summarizes a framework clause or one of your files, that part is now in your transcript. A long reply costs your harness a long reply. If you want the answer lean, ask your agent to request a brief answer, or only the decision and the references.

What to delegate, and what to keep

Delegate the compliance work:

• Framework questions: ISO 27001, SOC 2, GDPR, NIS 2, DORA, the EU AI Act, HIPAA, and the rest.
• Policy and procedure drafts.
• Control mapping across frameworks.
• Gap analysis against a framework.
• Statement of Applicability justifications, risk register entries, audit prep.

Keep the rest in your harness:

• Code, git, the file system, your build.
• General questions that have nothing to do with compliance.
• Orchestration. Your agent decides what to delegate and what to do with the answer.

A good rule to put in your agent's instructions: when the task is compliance, ask ISMS Copilot, and do not paste framework text or large documents into your own context to answer it yourself.

Connect in one command

In ISMS Copilot, open Settings, then Connected apps, and create a token. Then, for Claude Code:

claude mcp add --scope user --transport http ismscopilot https://account.ismscopilot.com/v1/account/mcp --header "Authorization: Bearer pat-isms-..."

The --scope user flag makes it available in every folder. Cursor, Codex, OpenCode, and other MCP clients that accept a Bearer header use the same server URL and token. The per-client steps are in the Claude Code guide and Connect Cursor and Codex.

It rides your chat plan

There is no separate MCP product and no separate bill. Delegated conversations run on your existing ISMS Copilot chat plan, with the same usage window as the web app. If you hit the limit, the tool says so and tells you when it resets.

The short version: compliance answers you can trust, inside Claude Code, Cursor or Codex, without burning your Claude or ChatGPT plan. How the costs compare, with sources and dates, is on /for/grc-engineers.

What is not supported yet

The connection uses a personal access token. Clients that only connect through OAuth cannot use it yet. That means claude.ai connectors, Claude Desktop connectors, and ChatGPT connectors are not supported today. Claude Code, Cursor, Codex, OpenCode, and other clients that accept a Bearer header work now.

The point

You do not have to choose between your agent and a compliance specialist. Keep the agent. Give it someone to ask.