Originally published at ReclaimLLM.
A scoped engagement MSPs, MSSPs and vCISOs can deliver to software clients using Cursor, Claude Code or Copilot: inventory, policy, evidence and review.
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,beforeSubmitPromptorafterAgentResponsehooks (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 info@reclaimllm.com. Scope, access, support and commercial terms should be agreed separately for the engagement.
Review AI coding evidence coverage.
Read the original article at ReclaimLLM.
