Does your company use Cursor, Codex, or Copilot without a policy? Risks and minimum controls

Cursor, Codex, Copilot, and other AI coding tools can enter a company before IT, security, and legal have defined clear rules. A developer uses them in their IDE, a team enables agent mode, a contractor pastes logs into a chat, a department experiments with client repositories. Everything seems productive, but no one really knows what data has left the building, which tools are authorized, and which modifications require review.

An AI coding policy is not meant to block innovation: it is meant to make explicit who can use which tools, on what data, with what permissions, and with what controls before merging or deploying.

For CISOs, CTOs, IT managers, and legal teams, the point is not to choose a vendor once and for all. The point is to prevent every team from inventing their own rules while code, prompts, secrets, and responsibilities spiral out of control.

Why a policy is necessary even with enterprise tools

Enterprise features help: SSO, RBAC, content exclusion, audit logs, sandboxes, approval policies, and controls on cloud or local agents. But these settings govern the tool; they do not automatically guarantee that the produced code is secure, that the data is lawful to use, or that every pull request has the right review.

A corporate policy must combine three distinct levels. The first concerns tools: which instruments are allowed, with which accounts and configurations. The second concerns data: what cannot be included in prompts, context, logs, or workspaces. The third concerns process: when reviews, tests, gates, logging, training, and exceptions are required. Without these levels, the company risks a false sense of control: “we have Copilot Enterprise” or “Codex is in a sandbox” does not answer the question of which repositories are permitted, which data is prohibited, and who approves a PR that modifies auth, pipelines, or secrets.

Defining allowed and prohibited tools

The policy must start with an inventory that includes Cursor, Codex, Copilot, Claude Code, IDE extensions, generic chats, plugins, MCP servers, cloud agents, open-source tools, personal accounts, free plans, and test environments. For each tool, you must define at least the internal owner, the allowed plan, minimum requirements (SSO, MFA, logging, access management, data retention, privacy), authorized repositories or teams, enabled features, and the process for requesting exceptions.

The rule should not be “use AI with common sense.” It must state what is allowed, what is prohibited, and what requires approval.

Writing the list of prohibited data in prompts

The most important part of the policy is often the most concrete: what cannot be pasted or made available to the model. Some elements must be explicitly prohibited or authorized only through a specific process:

• Secrets, tokens, passwords, cookies, cloud keys, and API keys.
• Personal data, client data, health, financial, or HR data.
• Logs with PII, headers, stack traces, or client identifiers.
• Database dumps and production files.
• Contracts, confidential documents, incident reports, and vulnerability reports.
• Unauthorized client or third-party code.
• Architectures, internal endpoints, and unredacted production configurations.

It is not enough to write “do not enter sensitive data.” You need examples close to the developers’ actual work: error logs, .env files, tickets, screenshots, queries, test files, transcripts, cloud configurations.

Governing repositories, context, and indexing

Many AI tools work by reading open files, repositories, workspaces, branches, issues, documentation, or indexed context. If the company does not define boundaries, the agent may see much more than necessary. The policy must therefore distinguish between public repositories, internal repositories, client code, monorepos, regulated projects, components with secrets, production environments, and legacy repositories: some may be allowed with exclusions, others require read-only mode or a prohibition on indexing.

Useful controls in this area:

• Exclusion files for sensitive directories.
• Allowlist of authorized repositories.
• Prohibition on client projects without contractual consent.
• Separation between different clients.
• Secret scanning before agentic use.
• Review of indexing and retention settings.

Establishing when agent mode, terminal, and cloud agents are allowed

Autocomplete and chat do not have the same risk profile as an agent that modifies files, executes commands, opens pull requests, uses MCP servers, or works in the cloud with a copy of the repository. The policy must classify operational modes and associate a minimum rule with each.

Mode	Risk	Minimum Rule
Chat or local completion	Improper use of data and snippets	Prohibited data, code review, corporate account
Modify files in repository	Vulnerable or overly broad diffs	Mandatory PR, owner reviewer, branch protection
Terminal or commands	Secrets, side effects, installations	Sandbox, approval, no production
Cloud agent	Code and context in remote environment	Authorized repositories, limited network, separate secrets
MCP/external tools	Actions on corporate systems	Tool allowlist, least privilege, audit log

If a mode allows writing, deploying, network access, or the use of external tools, it should not be enabled by default on all repositories.

Making review mandatory for sensitive areas

The policy must clarify that AI-generated code remains the responsibility of the team: a PR that passes tests is not automatically acceptable. Review becomes mandatory when the modification touches authentication, sessions, password resets, MFA or OAuth callbacks; authorizations, roles, tenant isolation, middleware, and policies; APIs, queries, serializers, uploads, exports, and payments; secrets, environment variables, logs, and error handling; dependencies, lockfiles, package managers, and installation scripts; CI/CD, Dockerfiles, IaC, cloud, IAM, and deployments; runtime prompts, tool calling, RAG, memory, or application agents.

The connection with Code Review is direct: the policy defines when a review is necessary, while the review verifies the diff and any regressions.

Logging, audit, and evidence

A policy without evidence is difficult to enforce. The company must know which tools are enabled, which users are using them, which repositories are involved, which agents can modify code, which exceptions have been approved, and which PRs have been generated or assisted by AI. It is not always necessary to log the content of prompts, which may be sensitive, but you need at least the governance data: active tools, users, configurations, repositories, approvals, exceptions, findings, reviews, and merge decisions.

For incident response, evidence must allow you to answer concrete questions: which agent produced this change? What context could it read? Did it have access to secrets? Did it use the network or external tools? Who approved the PR?

Training: practical examples, not abstract principles

Effective training shows real cases from daily work, not generic principles about AI ethics. Developers need to know what to do concretely: a production log that should not be pasted into a chat, an API key in a configuration file that must be rotated if it entered the prompt, an AI-generated PR that modifies middleware and tests, an AI-suggested dependency to verify before merging, a CORS or IAM policy widened to “make the build work,” a client file that cannot be indexed. These examples make the policy understandable and applicable, rather than remaining a document that no one consults.

Managing exceptions and rollout

Every policy must provide for exceptions; otherwise, exceptions become informal. A team may have an experimental case, a tool not yet approved, a pilot repository, or a temporary need: in all these cases, the exception must have an owner, duration, scope, accepted risk, compensatory controls, and review. If it remains active without an expiration date, it is no longer an exception but a second, ungoverned policy.

For rollout, it is best to start with pilot repositories, measure the problems, update the policy, and then extend. A minimum policy that is applied and improved over time works better than a perfect policy written before any testing.

Minimum checklist for an AI coding policy

• Inventory of AI coding tools used by employees and contractors.
• Authorized, prohibited, and pilot-phase tools.
• Minimum requirements: SSO, MFA, logging, access management, data retention.
• Prohibited data in prompts and context, with concrete examples.
• Repositories allowed, excluded, or subject to approval.
• Rules for agent mode, terminal, cloud agents, network, and MCP.
• Secret scanning and file exclusion before use on sensitive repositories.
• Mandatory review for critical areas of code.
• Minimum CI/CD gates for AI-generated PRs.
• Logging and auditing consistent with privacy and incident response.
• Practical training for developers, reviewers, and managers.
• Exception process with owner, expiration, and accepted risk.

When to involve ISGroup

If the company is already using AI coding without clear rules, the priority is to understand exposure and risk: active tools, processed data, involved repositories, vendor controls, internal policies, pipelines, and reviews.

Scenario	Main Risk	Recommended Service
Widespread use without clear ownership	Weak governance and unassigned responsibilities	Virtual CISO
Continuous adoption of AI coding in teams	Non-repeatable controls on PRs, pipelines, and releases	Software Assurance Lifecycle
Repositories already modified by AI on sensitive areas	Vulnerabilities or regressions in the code	Code Review
Web applications developed with AI coding	Application flaws not detected before deployment	Web Application Penetration Testing

The expected result is not a long document that no one reads, but an applicable policy: a few clear rules, defined responsibilities, escalation thresholds, and technical controls linked to the process.

Frequently Asked Questions

• Is it necessary to ban Cursor, Codex, or Copilot in the company?
• Not necessarily. It is usually more effective to authorize specific tools and use cases, prohibit sensitive data and repositories, impose reviews on critical areas, and configure available enterprise controls.
• Are the vendor’s enterprise settings enough?
• No. They are necessary, but they govern the tool. Application security still depends on code, data, repositories, reviews, pipelines, licenses, dependencies, and internal responsibilities.
• What data should not enter prompts?
• Secrets, tokens, passwords, personal data, client data, logs with PII, dumps, contracts, incident reports, vulnerability reports, unauthorized code, and unredacted production configurations.
• Who should own the AI coding policy?
• Shared ownership is required: CTO or engineering for the technical process, CISO for risk, IT for access, legal and privacy for data and contracts, procurement for vendors and clauses.
• When is a Code Review needed?
• When an AI-generated or assisted PR touches auth, roles, APIs, queries, secrets, dependencies, pipelines, cloud, payments, or business logic. The policy must make this explicit before the PR is merged.

Sources and references

• NIST AI Risk Management Framework
• NIST SP 800-218 SSDF
• OWASP SAMM
• OWASP Top 10 for LLM Applications
• GitHub Copilot documentation
• OpenAI Codex enterprise admin setup
• OpenAI Codex agent approvals and security