How to govern Cursor and Copilot in a regulated company

When an AI coding assistant has read access to your source — and sometimes write access to your repository — it is a vendor with a data-processing relationship, not a productivity toggle. In many organizations that access exists before any policy does, because developers can install Cursor or turn on Copilot without asking. Five practice areas cover most of what an auditor will ask about.

1. Build an approved-tool inventory

Track which AI coding assistants are in use, per team or repository: the vendor, the plan, who approved it, and what the plan's data handling terms say about training on your code. An inventory with gaps is worse than an honest "we don't know yet" — it tells an auditor the org doesn't have visibility into what's reading its source.

Both major vendors ship an admin control worth pointing an auditor to directly, rather than describing secondhand. Cursor's Enterprise plan adds repository, model, and MCP access controls that an org admin sets centrally (verified against cursor.com/pricing, 2026-07-24). GitHub Copilot's organization and enterprise admin console has a "Restrict MCP access to registry servers" policy (public preview on Business and Enterprise plans, verified against docs.github.com, 2026-07-24). Know its limits before treating it as a boundary: GitHub's own documentation says enforcement matches servers by name or ID, applies only on supported IDE and CLI surfaces, and can be bypassed by editing configuration files — a guardrail that signals and records intent, not a technical block. Set the policy, record who set it, and review the list when a vendor changes its connector model — not on a fixed calendar disconnected from what actually changed.

2. Set data-egress and secrets rules

Default posture: secrets never leave the IDE toward a model — no exception, because a task that "needs" a live credential in a prompt is a task that needs redesigning. Customer data and third-party material under NDA leave only with explicit authorization: the data's classification allows it, the vendor and plan are approved for that classification, and the contractual and transfer terms cover it — task necessity alone authorizes nothing. Three controls do most of the day-to-day work: secret scanning wired ahead of commits and pushes (it blocks a pasted credential from landing in history — exposure to the assistant has already happened by then, which is why the never-in-prompt rule comes first); workspace-level indexing exclusions so an assistant never reads directories it has no reason to read, not just directories it shouldn't write to; and a recorded answer to "does this plan train on our code," checked against the vendor's current terms rather than assumed from a previous plan or a competitor's default.

3. Require grounding — cited sources over model memory

The failure mode here is specific: an assistant answers a compliance or security question fluently, from its own training data, with no signal to the reader that nothing was actually looked up. A policy that requires a verifiable citation narrows that gap — narrows, not closes, because a model can fabricate a citation too. The requirement that works is a fetched source: when an assistant's answer touches a compliance control or a legal requirement, it must cite a source it actually retrieved — a resolvable link or document reference a reviewer can open — not merely name a plausible article number. An answer with no checkable source attached is not evidence of anything, however confident it reads.

This is a policy you can lift rather than invent: a short cite-or- refuse instruction in the system prompt is what makes an AI agent reliable for exactly this reason, and Instruct your agent is the worked version — the rule and the paste-ready wording, not just the idea.

4. Keep an audit trail

Pull request review is the audit-trail component you already run — make it non-optional for any AI-suggested change that touches a security-sensitive path (authentication, secrets handling, network configuration, access control), and never let an assistant merge its own change. It is one component, not the whole trail: a PR records the accepted diff, not the prompts, the tool identity, the retrieved context, or the suggestions that were rejected — which of those your regime requires you to keep is a question for your control framework, not a default. Where a specific compliance deliverable depends on an assistant's output — a drafted DPIA answer, a threat-model finding — keep the query and the cited source next to the output, not just the output. The underlying law or standard can change between when the answer was drafted and when it's reviewed; the citation is what lets a later reviewer check the answer against the current text, not the text as it stood when the assistant ran.

5. Know your regulatory touchpoints

Two EU instruments bear directly on an AI coding assistant, and both are narrower than the headlines about them suggest.

The EU AI Act's Article 50 transparency obligations apply from 2 August 2026, and that date was not moved by the 2026 Digital Omnibus amendment to the Act. Article 50 is a set of specific duties, not a blanket label-everything rule: most fall on the AI system's provider (machine-readable marking of synthetic content, disclosure when a person interacts with an AI system), and the deployer-side duty for generated text is scoped to publication intended to inform the public, with an exception where the content passed human review under editorial responsibility. Ordinary AI-assisted code or internal drafts are not categorically covered — the point of practice 5 is knowing which of your outputs fall inside those categories, and it is Article 50 you check for that, not the Act's high-risk-system rules, which apply on a later, staggered timeline.

NIS2 — Directive (EU) 2022/2555 — reaches an AI coding assistant through its supply-chain requirement (Article 21): an essential or important entity has to manage security risks in its supply chain and its relationships with direct suppliers and service providers. In our assessment a tool with repository access belongs in that analysis — whether it does for your entity, and what measures are proportionate, is an entity-specific determination, not a rule you can read off the directive. The directive's transposition deadline for EU member states was 17 October 2024; transposition status still varies by country, so the obligation your company actually faces is in your own jurisdiction's statute, not the directive text by itself.

If you don't yet know whether NIS2 or the AI Act applies to your company at all, the free NIS2 checker and AI Act checker walk the scope rules in about two minutes, with article citations, no signup.

Where the gateway fits

None of the five practices above need Ansvar — an approved-tool inventory, an egress policy, and a PR-review rule are yours to run regardless. Where a gateway helps is the grounding practice specifically: connecting Cursor, Copilot, or any MCP-capable assistant to the Ansvar gateway (the same way described in Quickstart) means a compliance question gets answered against the actual text of EU and national law, cited by article, instead of from the model's memory of what the law probably says.