Engineers who cannot wait for an approved AI coding assistant buy their own, sign in with a personal account and point it at company source code, often with a personal API key saved on the laptop. That code and the prompts around it then leave under a contract the organisation never signed, and the keys sit outside every rotation and offboarding process. Hardening the approved tools does nothing about the ones nobody approved. This guide covers how to find personal AI coding assistant licences, sign-ins, IDE extensions and API keys across engineering endpoints, networks and repositories, how to tell a personal account from a corporate one, and how to move people onto approved tooling without driving the use further underground. It is for endpoint, platform and application security teams and engineering leaders. Products named below are examples listed alphabetically, not recommendations.
Key takeaways
- The question is which account, not which tool. The same IDE extension can run on a corporate seat or a personal plan, so discovery has to identify the tenant behind a sign-in, not just the installed software.
- Vendors now ship tenant controls. GitHub Copilot routes traffic by plan to separate hostnames, Cursor accepts an
x-cursor-allowed-tenantsheader, VS Code hasChatApprovedAccountOrganizations, and Claude Code and Codex can pin logins to one organisation or workspace. - Use three vantage points. Endpoint inventory finds extensions, CLIs and key files; network logs show which plan endpoints are called; repositories show assistant config files and committed keys.
- Route before you block. A discovery programme that only blocks pushes engineers to personal devices. Offer an approved seat, a migration path for their settings and a fast exception route, then enforce.
- Personal keys are credentials to revoke. A personal model provider key found in a repository or shell profile is a leaked secret, whoever paid for it. Treat it through the leak process, not as a policy note.
What counts as unsanctioned
An AI coding assistant is unsanctioned when its use on company code is not covered by an approved contract, configuration and identity. That is broader than "unapproved product". Four cases come up in practice:
| Case | Example | Why it matters | Typical signal |
|---|---|---|---|
| Unapproved product | An assistant the organisation has not assessed at all | No data processing terms, no admin controls, unknown retention | New extension ID, new CLI binary, new API domain |
| Approved product, personal plan | A corporate-approved assistant signed in with a personal subscription or free tier | Enterprise data terms and admin policies do not apply to the personal plan | Traffic to an individual-plan endpoint; personal account in sign-in state |
| Approved product, personal key | An approved CLI or IDE using a personal model provider API key | Prompts and code go to the provider under the individual's account; the key is outside rotation and offboarding | Provider key prefixes in shell profiles, .env files or IDE settings |
| Approved product, unapproved extension | A third-party "AI helper" extension or MCP server added to an approved IDE | Extensions run with the IDE's access to files and terminals | Extension not on the allow list; new MCP entry in a config file |
For the general shadow AI picture beyond engineering, see the Shadow AI Discovery Guide. For the difference between assistants that suggest code and agents that act, see AI Coding Assistants vs Autonomous Coding Agents.
Discovery signals by vantage point
No single source finds all four cases. Endpoint inventory is the strongest for developer laptops; network logs confirm which plan is in use; repositories catch what has already leaked into code. The Network vs Browser vs Endpoint Shadow AI Discovery guide compares the methods in general; this table is specific to coding assistants.
| Vantage point | What to collect | Finds | Blind spots |
|---|---|---|---|
| Endpoint (EDR, MDM, osquery) | Installed IDEs and their extension directories; CLI binaries on PATH; presence (not contents) of assistant config and credential files; environment variable names in shell profiles | Unapproved products, unapproved extensions, personal keys on disk | Personal devices; containers and remote dev environments without an agent |
| Network (proxy, SSE, firewall, DNS) | Destinations for assistant and model provider APIs; plan-specific hostnames; sign-in endpoints | Personal plans of approved products; direct calls to provider APIs | Off-network use; pinned clients if you need content rather than destination |
| Identity and SaaS admin | Seat assignments and usage reports from approved vendors; OAuth app grants on the source control platform | Who has a corporate seat (and so who uses assistants without one) | Anything outside the corporate tenant by definition |
| Repositories and CI | Assistant config and instruction files; secret scanning for model provider key formats; committed agent settings | Tools in use per repository; leaked personal and corporate keys | Use that leaves no file behind |
Endpoint inventory, without collecting secrets
- Extensions: enumerate extension IDs and versions per IDE profile (VS Code and its forks keep extensions in a per-user extensions directory; JetBrains IDEs keep plugins per product version). Compare against the approved list rather than a deny list of known AI extensions, which will always be behind.
- CLIs: look for assistant command line tools installed through package managers or standalone installers, including in user-writable paths that software inventory often misses.
- Credential and config files: record existence, owner, permissions and modification time of known assistant files, never their contents. The file paths per tool are listed in How to audit AI coding assistant tokens and config files, which this page does not repeat.
- Environment variables: report the names of provider key variables set in shell profiles and IDE settings, and the key prefix only where you need to tell provider or key type apart.
- Remote development: include dev containers, cloud workstations and SSH targets, where extensions install on the remote side and endpoint agents on the laptop do not see them.
Developer laptops hold far more than assistant keys; see Developer endpoints as NHI stores for the wider credential inventory.
Telling personal from corporate accounts
This is where the vendors' own controls help most. Each mechanism below both reveals personal use (through denials or logs) and enforces the corporate tenant. Products are listed alphabetically; each row states only what the vendor's documentation describes, as checked in November 2026.
| Product | Control | How it works | Delivery |
|---|---|---|---|
| Claude Code | forceLoginMethod, forceLoginOrgUUID, allowedProviders | Restricts the login method, pins claude.ai logins to one organisation, and limits which API providers a machine may use. The settings reference says only a managed source enforces forceLoginOrgUUID; allowedProviders is managed-only. | Managed settings: managed-settings.json, MDM policy or server-managed settings; /status shows the active source |
| Codex (OpenAI) | forced_login_method, forced_chatgpt_workspace_id | Restricts sign-in to chatgpt or api, and limits ChatGPT logins to one workspace ID | Configuration file, with enterprise requirements through requirements.toml |
| Cursor | x-cursor-allowed-tenants header | Value v1.orgs=<ids>;teams=<ids> with numeric IDs; accounts outside the listed teams or organisations get a tenant_restriction_violation denial; a blank or malformed header is refused | Injected by a TLS-terminating proxy on requests to api2.cursor.sh and cursor.com; device policies such as Allowed Team IDs are separate |
| GitHub Copilot | Subscription-based network routing | Each plan uses its own endpoint: allow *.business.githubcopilot.com and *.enterprise.githubcopilot.com, block *.individual.githubcopilot.com (Copilot Free, Pro, Pro+ and Max) | Firewall or proxy rules; covers the IDE clients, Copilot Chat on GitHub, GitHub Mobile and Copilot CLI |
| VS Code | ChatApprovedAccountOrganizations, AllowedExtensions | Restricts chat sign-in to listed GitHub organisation logins (fail-closed; ["*"] allows any account), and limits installable extensions by publisher, ID and version | Device policy through Group Policy, Intune or macOS MDM |
Availability: several of these controls depend on the product's business or enterprise plan, a minimum client version (GitHub lists VS Code Copilot Chat 0.17, JetBrains plugin 1.5.6.5692 and Visual Studio 2022 17.11 for plan routing), or a proxy that can terminate TLS. Confirm the requirements in each vendor's current documentation before relying on a control.
Two limits apply to all of them. Network controls only act on traffic that passes your network, so off-network use on a managed laptop needs the device-side setting as well; Cursor's documentation states plainly that the header does not follow the account off the network. And none of them reach a personal device; for that, control access to source code itself through conditional access on the source control platform.
Run in observe mode first
Before blocking, log. Count requests to individual-plan endpoints, and watch for tenant denials in a pilot group. A week of logs turns "we think a few people use personal plans" into a named list per team, which is what the routing step needs.
Personal API keys in repositories and profiles
Bring-your-own-key setups are the hardest form to see from the network, because the traffic goes straight to a model provider domain that approved tools may also use. Endpoint and repository evidence carries the weight here.
- Repository scanning: enable secret scanning with push protection for model provider key formats, and scan full history, not only the default branch. See How to find LLM API keys in code and CI.
- Agent settings files: assistant permission files can capture credentials typed into commands. The Claude Code settings leak found secrets in committed
.claude/settings.local.jsonfiles across public repositories, stored because "don't ask again" saved the full command. - Personal does not mean harmless: in the xAI API key leak, a staff member's key in a committed
.envfile stayed valid for about two months after the scanner alerted only the committer. Route alerts to the security team as well as the author. - Ownership test: if the key belongs to an organisation account, revoke and rotate through the provider console (see How to audit OpenAI and Anthropic organisation API keys). If it belongs to the individual, you cannot revoke it yourself: ask the owner to revoke it, record confirmation, and remove it from history.
Personal keys used with company code are also a sprawl problem; see AI Coding Tools and Secrets Sprawl.
Routing people to approved tooling
Most unsanctioned use is a procurement and productivity gap, not malice. The response should close the gap first. The options are compared in Block vs Sanction vs Coach; for coding assistants the practical decisions are these.
| Finding | Default response | Escalate when |
|---|---|---|
| Approved product on a personal plan | Assign a corporate seat, have the user sign out and sign back in, then enforce the tenant control | The user declines a corporate seat or keeps the personal plan after enforcement |
| Unapproved product, low data sensitivity repositories | Coach and offer the approved alternative; open an assessment request if several teams ask for the same tool | Use spreads to regulated or customer code |
| Unapproved product on regulated, customer or export-controlled code | Block on managed devices and review what code was exposed | Contract or regulatory notification may be needed; involve legal and privacy |
| Personal API key in use | Move to an approved provider path (corporate key through a gateway or vendor seat); owner revokes the personal key | Key found in a repository or shared file: run the leak process |
| Unapproved extension or MCP server | Remove through extension allow listing; review requested permissions before adding it to the list | The extension came from outside the marketplace or is impersonating a known tool |
Small organisations can often skip the proxy work: buy business seats for one or two assistants, push the device policies through MDM, and rely on endpoint inventory. Large organisations need the network controls for scale, an exception register with expiry dates, and a published approved-tools list that engineers can find without asking. The AI coding assistant rollout playbook covers standing up the approved path.
Rolling out discovery and enforcement
- Publish the approved list and the policy. Name the approved assistants, plans, sign-in method and key handling. Engineers should know the rule before they are measured against it. The AI Acceptable Use Policy Template is a starting point.
- Agree privacy scope. With HR, legal and works councils where relevant, agree that endpoint checks record tools, file presence and destinations, not code, prompts or key values.
- Baseline in observe mode. Run endpoint inventory and network logging for two to four weeks. Produce counts per team for each of the four cases.
- Open the approved path. Provision seats for everyone found using a personal plan, plus a self-service request route.
- Pilot enforcement. Apply tenant controls and the extension allow list to one engineering group. Watch help desk tickets and denial logs; fix false positives such as legitimate open source maintainers who need a personal account for their own projects on a separate profile.
- Enforce in rings. Extend group by group. Keep the allow list in source control so a bad change can be reverted.
- Roll back cleanly. Each control has a simple undo: remove the network block or header, set
ChatApprovedAccountOrganizationsto["*"], or remove the managed setting. Document the undo before each ring. - Clean up keys. Run repository history scans and close every personal key finding with owner confirmation of revocation.
Where identity fits
An assistant sign-in is an identity decision. A corporate seat tied to the identity provider gets joiner, mover and leaver handling; a personal account and a personal API key do not, and both survive the engineer's departure. Treat assistant OAuth tokens and provider keys as non-human credentials with an owner, a scope and a revocation route. The AI IDE and Coding Agent Security Guide covers permissions for the approved tools once people are on them.
Detection and measurement
- Personal-plan share: requests to individual-plan endpoints, or tenant denials, as a share of all assistant traffic. Target zero on managed devices after enforcement.
- Seat coverage: engineers with an active corporate seat divided by engineers with any assistant on their endpoint.
- Extension drift: number of installed extensions not on the allow list across the estate, trending down.
- Personal key findings: open personal provider key findings in repositories and endpoints, and median days to owner-confirmed revocation.
- Exception health: exceptions past their expiry date (target zero).
- Time to approve: median days from a tool request to a decision; if this is long, unsanctioned use will return.
Framework mapping
| Framework | Reference | How this guide applies it |
|---|---|---|
| NIST CSF 2.0 | ID.AM-02, ID.AM-04 | Inventory of software and of supplier services, including AI coding assistants and their plans |
| NIST CSF 2.0 | PR.PS-02 | Removing or replacing unapproved assistant software |
| NIST SP 800-53 Rev 5 | CM-8, CM-10, CM-11, CM-7(5) | Component inventory, software usage restrictions, user-installed software, allow-by-exception for extensions |
| NIST SP 800-53 Rev 5 | SA-9, IA-5 | External services used for code processing; managing assistant tokens and keys as authenticators |
| CIS Controls v8.1 | Control 2 (Safeguards 2.1, 2.3, 2.5) | Software inventory, addressing unauthorised software, allow listing |
| ISO/IEC 27001:2022 | A.5.9, A.5.10, A.8.19 | Asset inventory, acceptable use, installation of software |
| MITRE ATT&CK | T1552.001 Credentials In Files | Why personal keys in files and profiles matter to an attacker |
Common failure patterns
- Blocking the product, missing the plan. Teams block an unknown assistant but leave personal plans of the approved one untouched, which is often the larger population.
- Deny lists of AI extensions. New assistant extensions appear weekly. Only an allow list keeps up.
- Collecting secrets during discovery. Scripts that copy config files to a central share create a new store of every key they were meant to find.
- Alerting only the committer. As the xAI case shows, a key can stay valid long after the author is told. Security needs the alert and the closure.
- Enforcing before the approved path exists. Engineers move to personal laptops and the organisation loses all visibility.
- Forgetting remote environments. Dev containers and cloud workstations run extensions and keys where laptop agents do not look.
Practitioner checklist
- Publish the approved assistants, plans, sign-in method and key handling rules.
- Inventory IDE extensions, assistant CLIs and credential file presence on every engineering endpoint and remote environment.
- Log traffic to plan-specific endpoints and model provider APIs before enforcing.
- Provision corporate seats for everyone found on a personal plan.
- Apply the vendors' tenant controls through managed settings, device policy or proxy, ring by ring.
- Enforce an extension allow list, kept in source control.
- Scan full repository history for model provider keys and route alerts to security.
- Close personal key findings only with owner-confirmed revocation.
- Track personal-plan share, seat coverage, extension drift and time to approve each month.
Standards and references
- GitHub Docs: Managing GitHub Copilot access to your enterprise's network
- Cursor Docs: Tenancy restriction
- Visual Studio Code Docs: Manage AI settings
- Visual Studio Code Docs: Manage extensions in the enterprise
- Anthropic: Claude Code settings
- OpenAI: Codex configuration reference
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Shadow AI Discovery Guide · AI IDE and Coding Agent Security Guide · How to audit AI coding assistant tokens and config files · Block vs Sanction vs Coach