Work with ISMS Copilot from your agent
When your agent consults ISMS Copilot and has it check the work, what stays in your agent, paste-ready routing rules for Claude Code, Codex, OpenCode, Grok and Cursor, and the patterns that keep each call small.
Your coding agent does the work: it owns your repository, your shell and your files. ISMS Copilot is the compliance expert it consults over the account MCP and has check that work. You decide and sign. This page covers when your agent calls ISMS Copilot (to consult, during the work, and to check before finishing), how to tell it to do so, and how to keep each call small.
When your agent connects, the server already sends it a short routing note (the MCP instructions field) saying what goes to ISMS Copilot, what stays with your agent, and when to have work checked. Agents do not always act on that note, so a routing rule in your project or user instructions makes the behaviour reliable.
What goes to ISMS Copilot, what stays with your agent
| Consult ISMS Copilot | Keep in your agent |
|---|---|
| Exact requirements and identifiers: DORA RTS articles, the NIS2 implementing regulation, ISO 42001 controls, CMMC practices | Small, well-known edits and quick drafts your model already handles |
| Framework interpretation: ISO 27001, ISO 27701, ISO 42001, SOC 2, GDPR, NIS 2, DORA, EU AI Act, Cyber Resilience Act (CRA), NIST SP 800-171/CMMC, HIPAA, PCI DSS | Code, tests, refactors, git and pull requests |
| Drafting that needs framework grounding or your workspace memories, files and company context: policies, procedures, SoA justifications, risk register entries | Reading and editing files, shell commands |
| Control mapping and gap analysis | General questions unrelated to compliance |
| Audit preparation and evidence lists | Deciding what to change in your codebase, and writing the final deliverable to disk |
A useful test: if the answer depends on exactly what a standard or regulation says, or on your workspace context, consult ISMS Copilot. If it depends on facts in your repository, keep that lookup local, then send ISMS Copilot a short summary of the relevant facts rather than the files themselves. For a check, send the document text itself, with secrets removed. If your model already knows the answer, needs no lookup and writes it straight to a file, keep it local too: calling ISMS Copilot adds turns and costs more Claude usage on small tasks like that. Compliance work you are about to finalize still gets a check. See where calling ISMS Copilot does not help.
Routing rules, per harness
Each rule below has the same content; only the file differs. Paste it into the file your harness reads. The rules assume the server is registered under the name ismscopilot, as in the setup guides.
Claude Code
Add to CLAUDE.md in the project root, or to ~/.claude/CLAUDE.md for every project:
## GRC work goes to ISMS Copilot
For ISO 27001/27701/42001, SOC 2, GDPR, NIS 2, DORA, EU AI Act, Cyber Resilience Act (CRA),
NIST SP 800-171/CMMC, HIPAA or PCI DSS questions, policy drafting, control mapping,
gap analysis, SoA justifications, risk registers and audit prep, use the ismscopilot
MCP server instead of answering from memory: when you need to know what a framework
requires, while you do the work when it needs compliance judgement, and before you finalize it.
You read the files and write the deliverable; ISMS Copilot judges. Keep code, git and shell work local.
- Do not paste framework text. To check work, send the document as message text, with secrets removed, and say in the deliverable which parts were not checked.
- One conversation per deliverable: create_conversation once, then send_message on the same conversation_id for every follow-up.
- Call set_company_context only when I ask to update my company profile.
- Pass workspace_id when the work is for a specific client or company.
- Default mode fast; think for checks and multi-step analysis; beyond on request, for a final check right before an audit, or for long research-grade drafting.
- Pass answer_format "brief" or "decision" unless I ask for the full text.
- If a call returns status "generating", poll get_reply until "complete".
- Write long deliverables to a file and give me the path, not the whole text in chat.
- Verify any citation an audit will depend on against the official source text when you can. Also verify anything ISMS Copilot marks as unconfirmed or says it cannot confirm before relying on it (fetch the official publication if you have web access). Do not routinely re-check other confirmed answers.
- Record which items you verified or could not verify in the deliverable itself, as a short "Verified" note. Say it in chat too, unless I ask for a bare reply such as a file path.Setup: Connect ISMS Copilot to Claude Code.
Codex, OpenCode and Grok
These harnesses read AGENTS.md. Put the same rule in AGENTS.md at the project root, or in the harness's global instructions file (for example ~/.codex/AGENTS.md for Codex). Check your harness version's documentation for the exact global path.
## GRC work goes to ISMS Copilot
For ISO 27001/27701/42001, SOC 2, GDPR, NIS 2, DORA, EU AI Act, Cyber Resilience Act (CRA),
NIST SP 800-171/CMMC, HIPAA or PCI DSS questions, policy drafting, control mapping,
gap analysis, SoA justifications, risk registers and audit prep, use the ismscopilot
MCP server instead of answering from memory: when you need to know what a framework
requires, while you do the work when it needs compliance judgement, and before you finalize it.
You read the files and write the deliverable; ISMS Copilot judges. Keep code, git and shell work local.
- Do not paste framework text. To check work, send the document as message text, with secrets removed, and say in the deliverable which parts were not checked.
- One conversation per deliverable: create_conversation once, then send_message on the same conversation_id for every follow-up.
- Call set_company_context only when I ask to update my company profile.
- Pass workspace_id when the work is for a specific client or company.
- Default mode fast; think for checks and multi-step analysis; beyond on request, for a final check right before an audit, or for long research-grade drafting.
- Pass answer_format "brief" or "decision" unless I ask for the full text.
- If a call returns status "generating", poll get_reply until "complete".
- Write long deliverables to a file and give me the path, not the whole text in chat.
- Verify any citation an audit will depend on against the official source text when you can. Also verify anything ISMS Copilot marks as unconfirmed or says it cannot confirm before relying on it (fetch the official publication if you have web access). Do not routinely re-check other confirmed answers.
- Record which items you verified or could not verify in the deliverable itself, as a short "Verified" note. Say it in chat too, unless I ask for a bare reply such as a file path.Setup: Connect Cursor and Codex, or Connect any MCP client for OpenCode and Grok.
Cursor
Create a project rule at .cursor/rules/ismscopilot.mdc:
---
description: GRC work goes to the ISMS Copilot MCP server
alwaysApply: true
---
For ISO 27001/27701/42001, SOC 2, GDPR, NIS 2, DORA, EU AI Act, Cyber Resilience Act (CRA),
NIST SP 800-171/CMMC, HIPAA or PCI DSS questions, policy drafting, control mapping,
gap analysis, SoA justifications, risk registers and audit prep, use the ismscopilot
MCP server instead of answering from memory: when you need to know what a framework
requires, while you do the work when it needs compliance judgement, and before you finalize it.
You read the files and write the deliverable; ISMS Copilot judges. Keep code, git and shell work local.
- Do not paste framework text. To check work, send the document as message text, with secrets removed, and say in the deliverable which parts were not checked.
- One conversation per deliverable: create_conversation once, then send_message on the same conversation_id for every follow-up.
- Call set_company_context only when I ask to update my company profile.
- Pass workspace_id when the work is for a specific client or company.
- Default mode fast; think for checks and multi-step analysis; beyond on request, for a final check right before an audit, or for long research-grade drafting.
- Pass answer_format "brief" or "decision" unless I ask for the full text.
- If a call returns status "generating", poll get_reply until "complete".
- Write long deliverables to a file and give me the path, not the whole text in chat.
- Verify any citation an audit will depend on against the official source text when you can. Also verify anything ISMS Copilot marks as unconfirmed or says it cannot confirm before relying on it (fetch the official publication if you have web access). Do not routinely re-check other confirmed answers.
- Record which items you verified or could not verify in the deliverable itself, as a short "Verified" note. Say it in chat too, unless I ask for a bare reply such as a file path.Setup: Connect Cursor and Codex.
claude.ai, Claude Desktop and ChatGPT
Add ISMS Copilot as a custom connector (in ChatGPT, a custom MCP app with OAuth and default settings) with the endpoint URL, then sign in and click Approve. These apps have no instructions file for the routing rule above; put it in the project or custom instructions if the app has them. Setup: Connect any MCP client.
Patterns that work
One conversation per deliverable
Start each deliverable (an access control policy, a gap analysis, a batch of SoA justifications) with create_conversation, then refine it with send_message on the same conversation_id. The specialist keeps the thread's history on its side, so your agent does not need to resend earlier turns. Start a new conversation for an unrelated deliverable: long threads use more of your usage window per message.
Scope client and company work to a workspace
Pass workspace_id (from list_workspaces) when the work belongs to a specific client or company. On a workspace-scoped turn, ISMS Copilot reads that workspace's memories and files, so your agent does not have to restate them. Without workspace_id, the turn runs on your personal memories only.
Pick a built-in assistant
With a personal access token, your agent can route a question to a built-in assistant focused on one framework: Cyber Resilience Act (cra), DORA (dora), EU AI Act (eu-ai-act), NIS 2 (nis2), Privacy management (iso27701, covers ISO/IEC 27701) and AI management (iso42001, covers ISO/IEC 42001). Have it call list_assistants once, then pass assistant with the matching id on create_conversation. The choice sticks to the conversation, so follow-ups need no assistant. For anything else, omit it: the general specialist answers every other framework as before. Each reply's assistant field says which assistant answered. Sign-in connections do not have this yet. Details: Connect any MCP client.
Pick by job
Built-in assistants also come by job. With a personal access token, list_assistants returns them as by_job, next to the framework experts in built_in. The jobs are Questionnaire responder, Audit prep, Implementation lead and Incident lead; list_assistants shows the ones enabled for your account. More roles will follow. Pick a job when your agent has a task to get done, such as answering a security questionnaire or preparing for an audit. Pick a framework expert when the question is about what one framework requires. When unsure, omit assistant. Name the framework in the message and the role works to it. Each role reply names the framework it led with. Sign-in connections do not have this yet.
Memories for durable facts
Facts that should apply to every future turn (the certification scope, the chosen risk methodology, the audit date) belong in a memory: create_memory, with workspace_id for a workspace memory or without it for a personal one. Memories are capped at 500 characters each. Use list_memories to check what is already there before adding a duplicate.
Company Context
set_company_context replaces the account's company profile (name, sector, size, country, privacy role, data types, hosting region, tech stack, notes), and get_company_context reads it. With a workspace_id, both act on the company linked to that workspace instead (companies and links: see Tokens and scopes). Conversations your agent runs over MCP or the account API get a profile on the same terms as web chat, as background to each turn of a conversation your own account started, and replies may use facts from it: outside any workspace, the account profile; in a personal workspace, only the company linked to it, and no profile when none is linked. Only your own account's profiles are used, and they are never shared with another account. The account profile is not added inside workspaces or in temporary chats, and no profile is added when it cannot be read (the turn then runs without it). Facts that matter only for one question can still go in the message itself or in a workspace memory.
Fast, Think or Beyond
mode | Use it for |
|---|---|
fast (default) | Most questions and short drafts. |
think | Checks before your agent finalizes work, and multi-step analysis: gap analysis across several controls, mapping between frameworks. Paid plans; on a free plan it falls back to fast. |
beyond | On request, for a final check right before an audit, or for long research-grade drafting. Paid plans, capped at 10 runs per UTC day (50 on Unlimited), minutes-scale. |
A beyond request that cannot run is answered through the normal flow, and the result says why in beyond_denied_reason: plan, adp, disabled, trivial, cap or cap_anthropic. A turn running on the over-cap overflow path also answers through the normal flow instead of Beyond. See Using Beyond mode.
Ask for a reply shaped for an agent
create_conversation and send_message take an optional answer_format:
answer_format | Reply shape |
|---|---|
brief | The shortest correct answer, about 150 words, framework references inline. |
decision | Recommendation first, then why, risks and next steps as bullets, about 300 words. |
full or omitted | The default chat style. |
An explicitly requested full document is never cut short. Beyond runs ignore answer_format and say so with answer_format_applied: false.
Polling cadence
When a call returns status: "generating", call get_reply with the conversation_id and message_id until it returns complete:
- Fast and Think turns: every 2-5 seconds.
- Beyond runs: every 10-20 seconds. You can also pass the
beyond_run_idthe ticket returned.
Wait for a reply before sending the next message on the same conversation: a send while the previous turn is still generating is rejected.
Write long deliverables to files
When the specialist returns a policy or a full SoA, have your agent write it straight to a file and report the path. Repeating a long document back in chat puts it in your agent's context twice. See What calling ISMS Copilot saves.
MCP or the Model API?
ISMS Copilot offers two ways in from a coding agent. They suit different jobs.
| Account MCP | Model API sub-agent | |
|---|---|---|
| Credential | pat-isms-… personal access token | sk-isms-… API key |
| Billing | Your ISMS Copilot plan, same usage limit as the chat app | Prepaid API credits |
| State | Stateful: conversations, workspaces, memories, files | Stateless: each completion stands alone |
| Tools in your agent | Yes, native MCP tools | No: the endpoint is text in, text out, called from a script or step |
| Best for | Interactive work where you and your agent refine a deliverable over several turns | Fixed, repeatable compliance steps in scripts, CI or automation |
For the Model API pattern, see Use the API in coding agents.
If a turn hits your plan limit, the tool error carries the reset time and, where it applies, the upgrade link or the overflow option. See Connect any MCP client.