Offering AI coding governance to your clients: an MSP and vCISO playbook

Updated November 14, 2026.

Your software clients are adopting Cursor, Claude Code, Copilot, Codex and Antigravity. Their customers and auditors are starting to ask two questions: which AI tools touch our code and data, and can you show what the agents did?

When no one owns that answer internally, an MSP, MSSP or vCISO who already runs the client's security programme can help. This playbook describes a scoped engagement you can deliver, a sample deliverable, and the limits you should state up front.

Why clients ask now

The tools' own records leave gaps that a client cannot close by reading the vendor's docs:

• No single record of approvals. Cursor staff stated that there is no platform audit trail linking a proposed tool call, the user's decision and the execution result into one record, and that approval-card decisions are not passed through hooks (Cursor forum, t/156247/10).
• Hooks do not cover every path. Cursor staff confirmed that the Cloud Agent pull-request tool runs on Cursor's backend and is not visible to project hooks (t/177855/7), and that headless CLI mode does not yet run the stop, beforeSubmitPrompt or afterAgentResponse hooks (t/177989/7).
• Defaults are open. Cursor's Read Access setting, available since Cursor 3.23, defaults to System, so the agent can read outside the project unless someone selects Workspace (t/149418/15; run modes docs). Even with a sandbox, the agent can ask to run a command outside it, and a granted request lifts the limit for that command (t/177516).

None of these is a reason to ban the tools. They are reasons for someone to write down the settings, collect evidence and review it on a schedule. That is a service.

The engagement: scope

The scope below is a proposal you can adapt. It is not a ReclaimLLM-certified programme and the timings are estimates, not commitments.

Prerequisites from the client

• A named client owner (CTO or engineering lead) with authority to change tool settings.
• Admin access, or an admin who will screen-share, for each AI tool in use.
• A list of repositories that hold customer data or production credentials.
• Agreement on which personal data and secrets are in scope.

Phase 1: Inventory (week 1)

• List every AI coding tool in use, by team, with version and plan (Cursor, Claude Code, Copilot, Codex, Antigravity, others).
• Record how each is installed and who can install extensions, plugins and MCP servers.
• Record key settings per tool. For Cursor: Privacy Mode, Read Access, run mode, hooks in use. For Claude Code: permission rules in shared and local settings. For Copilot: content exclusion.

Phase 2: Policy (week 2)

• A one-page AI coding policy: approved tools, data that must not enter prompts, required settings, how to report a mistake. Start from our AI governance guide for small engineering teams.
• A vendor file per tool: data terms, retention, region, sub-processors. Where relevant, map it to the client's privacy obligations (for Canadian clients, see our PIPEDA and Law 25 guide; for EU clients, the GDPR and AI Act guide).

Phase 3: Evidence (weeks 2–3)

• Set up session capture for the in-scope teams, with local redaction rules tested against synthetic data.
• Run a small coverage test per tool and surface: one allowed read, one denied read, one failed command, one file edit. Record what the capture shows and what it misses. See AI coding session audit trails for the method.
• Write a coverage note listing known gaps (for example, Cloud Agent PR actions and headless CLI hooks in Cursor).

Phase 4: Review rhythm (week 4, then ongoing)

• A weekly or monthly review: new tools, setting changes, flagged sessions, secrets that need rotation.
• A quarterly re-run of the coverage test after tool updates.
• An evidence pack the client can hand to an auditor or a customer security questionnaire. Our SOC 2 evidence guide shows what auditors usually ask for.

Acceptance criteria

The engagement is complete when the client has: a signed-off policy; an inventory and settings record for every in-scope tool; a coverage note with known gaps and owners; one completed review cycle; and a named internal owner for the ongoing review.

What stays the client's responsibility

• Decisions on which tools to allow and which data may enter prompts.
• Legal conclusions about privacy law. Recommend the client's counsel for those.
• Rotating credentials and responding to incidents, unless your incident-response contract covers it.

Sample deliverable: assessment summary (synthetic)

The example below is invented to show the format. It is not a real client and the findings are illustrative.

Client: Example SaaS Inc. (fictional), 40 engineers Period: 4 weeks

1. Tool inventory

Tool	Teams	Install path	Admin owner
Cursor	Platform, Web	Self-installed	Unassigned → assigned to platform lead
Claude Code	Data	npm, per developer	Data lead
Copilot	Web	Org licence	IT

2. Settings gaps found

Finding	Risk	Action	Owner	Due
Cursor Read Access on System (default) for all users	Agent can read outside repo without asking	Set Workspace via team policy	Platform lead	Week 2
.claude/settings.local.json committed in 2 repos	Saved approvals may contain credentials	Check contents, rotate if needed, add to .gitignore	Data lead	Week 1
No extension allowlist	Any extension can be installed	Define approved publishers	IT	Week 3

3. Evidence sample One synthetic session per tool showing a denied read, a command and an edit, with redaction applied. Two gaps recorded: Cloud Agent PR actions not visible to hooks; headless CLI runs missing end-of-session events.

4. Review rhythm Monthly 30-minute review with the CTO. Quarterly coverage re-test. Next review: [date].

What not to promise

• No real-time blocking claims. Hooks can deny some actions on supported paths. Session capture and detection tell you what happened; ReclaimLLM's detectors run on an hourly or daily sweep and alert.
• No complete coverage claims. State the known gaps in writing.
• No certification. You can help a client prepare evidence. You cannot certify their programme, and using an evidence tool does not establish that the client or vendor holds a certification.
• No legal conclusions unless your firm is qualified to give them.

Where ReclaimLLM fits

ReclaimLLM gives you the evidence layer for phases 3 and 4. It captures sessions from Cursor, Claude Code, Copilot, Codex and Antigravity, applies local redaction before upload, and makes sessions searchable. Check the current plan comparison and confirm the available team-management, audit and integration capabilities for the client's account before including them in the scope. Hosted data is stored in the US or EU region today. Canadian in-country hosting is planned for Q1 2027 and is not available yet.

Confirm account boundaries, client authorization and the access needed for each engagement before collecting evidence. This playbook does not assume a single partner account can administer multiple clients.

Working with us

If you deliver security or compliance services to software teams and want to discuss using ReclaimLLM in client engagements, email us at [email protected]. Scope, access, support and commercial terms should be agreed separately for the engagement.

Review AI coding evidence coverage