As an engineering manager rolling out AI to a 30-dev team, how do I pick a coding agent that won't leak our source code?

For a 30-person engineering team, I’d treat “won’t leak source code” as a security architecture requirement, not a vendor feature checkbox. No cloud coding agent can honestly promise zero risk; the goal is to minimize exposure and make the remaining paths auditable.

What to evaluate

I’d score vendors internally against these six gates:

The last point is particularly important: “the model provider doesn't train on our code” doesn't mean the agent can't leak it. An agent with shell, network, GitHub, Slack, cloud credentials, and MCP access can potentially move data through those channels.

The shortlist I'd test

For an enterprise rollout, I'd put GitHub Copilot Enterprise/Business, Claude Code under an enterprise/ZDR arrangement, and Codex under a business/enterprise setup into the bake-off rather than evaluating consumer subscriptions.

There are meaningful differences in their current controls:

• GitHub Copilot Business/Enterprise: GitHub says customer data isn't used to train models, and its current documentation says IDE chat/code-completion prompts and suggestions aren't retained by default; other Copilot surfaces have a 28-day default retention period. GitHub GitHub GitHub also provides enterprise agent controls, audit information, and controls for third-party agents such as Claude and Codex.
• Codex/OpenAI: OpenAI states that Business/Enterprise data isn't used to train models by default, and qualifying organizations can configure retention controls, including zero data retention for the API. OpenAI OpenAI Help Center OpenAI also documents sandboxing, permissions, approval boundaries, and telemetry as controls for running coding agents safely.
• Claude Code/Anthropic: Anthropic provides enterprise/ZDR configurations, but its retention rules can vary by model and deployment path. Its current documentation specifically describes additional retention requirements for certain "covered" models, so you should validate the exact model + endpoint combination you're buying rather than assuming "Claude Code = ZDR."

Those policies can change, so I'd make the contract/DPA and technical configuration—not a salesperson's statement—the acceptance criteria.

The test I'd actually run

Give each candidate the same sanitized-but-realistic repository and run a two-week pilot with perhaps 5–8 developers.

Have the agent perform:

1. A normal feature implementation.
2. Refactoring across multiple modules.
3. Test generation and execution.
4. Dependency installation.
5. A task requiring access to an internal API.
6. A task containing a deliberately planted fake secret.
7. An attempted request to send repository contents to an external endpoint.
8. An MCP/tool integration.

Then inspect:

• What left your network?
• Which files were uploaded?
• Were entire files sent or only relevant snippets?
• Where were requests processed?
• How long did logs/prompts/code remain?
• Can administrators retrieve the agent's activity?
• Can you revoke access immediately?
• Can developers add arbitrary MCP servers?
• Can the agent execute arbitrary shell/network commands?
• What happens when the agent encounters credentials?
• Can the agent access repositories the developer themselves cannot?

The fake-secret test is especially useful. Put a canary credential/string in the repo and monitor your egress, logging, and vendor-side telemetry. Don't use a real credential.

My minimum deployment architecture

For 30 developers, I'd start with:

Developer → managed enterprise agent → isolated/sandboxed execution → approved repositories/tools → PR → human review

rather than:

Developer → unrestricted agent with GitHub + shell + network + cloud credentials.

I'd also initially prohibit:

• production credentials
• unrestricted outbound network access
• arbitrary MCP servers
• access to production databases
• automatic deployment
• organization-wide repo access
• personal/consumer AI accounts for company code

GitHub, for example, now provides enterprise controls for MCP servers and can restrict agents to selected organizations/repositories. GitHub Docs Its third-party coding agents also undergo security validation including CodeQL, secret scanning, and dependency checks when generating/modifying code.

One important distinction

I'd separate "source-code confidentiality" from "IP/license risk."

Even if a provider doesn't retain or train on your code, generated code can still create licensing/IP questions. For example, GitHub documents public-code matching controls, and there are ongoing legal disputes around AI-generated code and open-source licensing.

So your security review should have two independent sign-offs:

Security: Can our proprietary code escape?

Legal/IP: What obligations arise from the code the agent generates?

For a 30-dev team, I'd make training exclusion + contractual retention terms + least-privilege agent permissions + auditable activity + network isolation hard gates. Everything else can be part of the comparative evaluation.

If you tell me whether you're primarily on GitHub/GitLab/Bitbucket and AWS/Azure/GCP, I can turn this into a concrete vendor scorecard and 2-week pilot plan for your team.

Rolling out an AI coding agent to a 30-developer team without compromising your intellectual property requires looking past marketing claims and auditing the vendor’s data boundary. For a team of this size, you want a tool that enforces enterprise-grade security by default without requiring a mountain of custom plumbing.

Here is a practical, step-by-step framework to evaluate and pick a coding agent that keeps your source code locked down.

1. Demand the Enterprise Tier (Never Use Pro/Consumer)

Never allow your team to sign up for individual pro tiers using corporate credit cards. Consumer and standard developer tiers often have default settings that opt your code snippets and telemetry into future model training.

• Upgrade to dedicated enterprise plans (e.g., GitHub Copilot Enterprise, Cursor Business/Enterprise, or Tabnine Enterprise).
• Ensure the contract explicitly states that your code, prompts, and completions are stateless and never retained.

2. Verify the 4 Non-Negotiable Security Controls

Before signing anything, ask your vendor (or look at their trust portal) for explicit proof of these four controls:

1. Zero Data Retention (ZDR): Prompts and contextual repo data sent to the LLM must be processed in-memory and wiped immediately upon response generation. No logging of code snippets to disk on the vendor's side.
2. Explicit Training Exclusion: A contractual guarantee that your company's source code, code reviews, and telemetry will never be used to train foundational or fine-tuned public models.
3. SOC 2 Type II Compliance: Insist on a recent SOC 2 Type II audit report covering the Trust Services Criteria for Security and Confidentiality . A Type I report only checks if policies exist; Type II proves they have been operating effectively over a sustained period.
4. Data Residency Options: If you operate in a regulated sector (finance, healthcare), verify whether data stays in your geographic region (e.g., EU-only hosting) or if they support private VPC/on-prem deployments.

3. Match the Tool Architecture to Your Risk Tolerance

Different agent architectures introduce different data-leakage surfaces. Pick the category that fits your InfoSec team's appetite:

• IDE-Native & Cloud-Backed (e.g., Cursor Business, GitHub Copilot): Best balance of velocity and security. Context is fetched locally within the IDE, packaged securely over TLS, and sent to strict enterprise API endpoints with zero retention.
• Terminal/CLI Autonomous Agents (e.g., Claude Code, Aider): Highly capable, but check how they handle local file reading and shell execution. If paired with custom API keys or open-source local runners (like Ollama), you can achieve ultimate privacy, though it places the burden of security configuration entirely on your team.
• Air-Gapped / Self-Hosted (e.g., Tabnine Enterprise, Continue with local models): Runs entirely within your VPC or local infrastructure. Zero external network calls, meaning zero risk of third-party data leakage—though model capability may lag behind frontier cloud models.

4. Lock Down the Deployment Policy

Technical controls fail if developer habits are sloppy. Establish these ground rules on day one:

• Standardize on One Tool: Pick a single primary agent (e.g., Cursor or Copilot) for the whole team. Shadow IT is your biggest leak vector; an engineer secretly running an unvetted CLI tool with your proprietary repo piped into it bypasses all corporate controls.
• Audit the Ignore Files: Ensure your workspace utilizes .gitignore or tool-specific ignore files (like .cursorignore ) to explicitly block environment files, .env , private keys, and proprietary core algorithms from ever being bundled into the AI context window.

To help narrow down the right platform for your group, tell me:

• What IDE or editor does your team primarily use (VS Code, JetBrains, etc.)?
• Do you have regulatory constraints (SOC 2, HIPAA, GDPR, etc.) that dictate where your data must be processed?

If the requirement is “our proprietary source code must not become training data or sit indefinitely in a vendor’s systems,” I’d treat this as a security/vendor-risk decision, not primarily a developer-productivity comparison.

For a 30-person engineering org, I’d use this framework:

1. Define your non-negotiables first

Put these in the procurement/security questionnaire:

• No training on our prompts, source code, outputs, or repository context.
• Explicit contractual commitment, not merely “we don't currently train on it.”
• Retention limits: ideally zero retention for inference data, or a short, documented maximum.
• Encryption in transit and at rest.
• Enterprise identity: SSO/SAML, SCIM, RBAC, audit logs.
• Data residency requirements, if applicable to your customers/regulators.
• No vendor employee access to code except tightly controlled, audited support processes.
• Subprocessor disclosure and change notification.
• Deletion rights and a defined deletion SLA.
• Your code isn't used to improve another customer's model.
• Agent isolation: the agent shouldn't automatically have access to every repository, credential, production system, or developer's filesystem.

That last point is increasingly important. Recent research found security defects in 16% of examined coding-agent setups, particularly around MCP servers, shell permissions, and agent extensions.

2. Separate “privacy” from “agent security”

These are different threats.

Threat A — vendor learns your code

Your developers send:

Here are 14 files from our proprietary payment engine... The provider receives that context. You need to know what happens to it afterward.

Threat B — the agent leaks your code

An agent with filesystem/network access could potentially send information somewhere it shouldn't. Prompt injection is particularly relevant when agents read untrusted files, issues, webpages, documentation, or repositories.

So don't accept:

“We don't train on customer code.” as equivalent to:

“Your code cannot leave the authorized environment.” It isn't.

3. Look closely at the current enterprise offerings

There are credible options, but the specific plan/configuration matters enormously.

GitHub Copilot Enterprise/Business

A strong candidate if you're already standardized on GitHub. GitHub says Business and Enterprise customer data is protected under its Data Protection Agreement, and its model-hosting documentation describes zero-data-retention arrangements with some model providers.

I'd still make your security team verify the exact models, features, retention policies, BYOK behavior, and subprocessors you'll actually enable. GitHub explicitly notes that BYOK prompts/responses are subject to the selected provider's policies.

Claude Code

Very attractive if you want a powerful terminal-based agent. Anthropic documents enterprise deployment and offers privacy/retention controls; its API documentation also describes Zero Data Retention arrangements.

But pay attention to which account/product you're buying. Anthropic's Claude Code documentation says retention depends on account type and settings.

Amazon Q Developer

Worth serious consideration if you're an AWS-heavy organization. AWS states that Q Developer Pro code content isn't used for service improvement or model training; the Free tier has different data-use provisions.

AWS also documents where Q stores/processes questions, responses, context and code, which is exactly the level of detail your security review should demand.

Cursor

I'd put it through a more rigorous security review rather than automatically rejecting it. The agent itself can be useful, but you're introducing another layer between developers and your source code, models, extensions/MCP servers, etc.

And there is a broader lesson here: recent reporting described attackers abusing Cursor's agent capabilities during real-world intrusions. That doesn't establish that Cursor leaked customers' source code, but it demonstrates why agent privilege and execution controls deserve as much scrutiny as provider data retention.

4. Make vendors answer these exact questions

I'd literally send them this questionnaire:

If the answer to “Is this guaranteed contractually?” is vague, treat the feature as unapproved.

5. Run a 30-day pilot—but make it adversarial

Don't give 30 developers your entire monorepo on day one.

Start with 5–8 engineers, using a representative but non-critical repository.

Measure:

• developer productivity;
• PR throughput;
• defect rate;
• agent autonomy;
• hallucination/rework;
• network destinations;
• files accessed;
• credentials touched;
• prompts/context transmitted;
• retention behavior;
• audit-log quality;
• how easily security can revoke access.

Then deliberately test:

• malicious instructions embedded in source files;
• poisoned README files;
• hostile dependency documentation;
• secrets accidentally present in the repository;
• MCP/plugin installation;
• attempts to access files outside the project;
• attempts to exfiltrate environment variables;
• attempts to curl arbitrary external endpoints.

The goal isn't merely:

“Can the agent write good code?” It's:

“Can this agent be safely given access to our code by 30 developers?”

6. My architecture recommendation

For a 30-dev team, I'd use a tiered trust model:

Tier 1 — ordinary repositories

Agent can read/write repository files and create branches/PRs.

Tier 2 — sensitive repositories

Restricted agent, no arbitrary network access, no production credentials, tighter logging.

Tier 3 — crown-jewel code

Either no external agent at all, or a self-hosted/private inference architecture where your security team controls the complete data path.

And I'd make agent permissions narrower than developer permissions. An agent doesn't need your developer's AWS credentials simply because the developer has them.

What I'd shortlist

If I were running the evaluation, I'd probably start with:

1. GitHub Copilot Enterprise — especially if GitHub is already your source-control/identity platform.
2. Claude Code enterprise — particularly if agentic terminal workflows are important.
3. Amazon Q Developer Pro — particularly for an AWS-centric organization.
4. Cursor — include it if developer experience is compelling, but scrutinize its agent/network/plugin architecture carefully.

I would not choose based on “doesn't train on our code” alone. That's only one row in the security matrix.

The strongest selection criterion is:

Can I prove, contractually and technically, exactly where our source code goes, who can access it, how long it persists, and what autonomous actions the agent can take? If you can't answer those four questions, it's not ready for your proprietary repositories.

as equivalent to:

“Your code cannot leave the authorized environment.” It isn't.

3. Look closely at the current enterprise offerings

There are credible options, but the specific plan/configuration matters enormously.

GitHub Copilot Enterprise/Business

A strong candidate if you're already standardized on GitHub. GitHub says Business and Enterprise customer data is protected under its Data Protection Agreement, and its model-hosting documentation describes zero-data-retention arrangements with some model providers.

I'd still make your security team verify the exact models, features, retention policies, BYOK behavior, and subprocessors you'll actually enable. GitHub explicitly notes that BYOK prompts/responses are subject to the selected provider's policies.

Claude Code

Very attractive if you want a powerful terminal-based agent. Anthropic documents enterprise deployment and offers privacy/retention controls; its API documentation also describes Zero Data Retention arrangements.

But pay attention to which account/product you're buying. Anthropic's Claude Code documentation says retention depends on account type and settings.

Amazon Q Developer

Worth serious consideration if you're an AWS-heavy organization. AWS states that Q Developer Pro code content isn't used for service improvement or model training; the Free tier has different data-use provisions.

AWS also documents where Q stores/processes questions, responses, context and code, which is exactly the level of detail your security review should demand.

Cursor

I'd put it through a more rigorous security review rather than automatically rejecting it. The agent itself can be useful, but you're introducing another layer between developers and your source code, models, extensions/MCP servers, etc.

And there is a broader lesson here: recent reporting described attackers abusing Cursor's agent capabilities during real-world intrusions. That doesn't establish that Cursor leaked customers' source code, but it demonstrates why agent privilege and execution controls deserve as much scrutiny as provider data retention.

4. Make vendors answer these exact questions

I'd literally send them this questionnaire:

If the answer to “Is this guaranteed contractually?” is vague, treat the feature as unapproved.

5. Run a 30-day pilot—but make it adversarial

Don't give 30 developers your entire monorepo on day one.

Start with 5–8 engineers, using a representative but non-critical repository.

Measure:

• developer productivity;
• PR throughput;
• defect rate;
• agent autonomy;
• hallucination/rework;
• network destinations;
• files accessed;
• credentials touched;
• prompts/context transmitted;
• retention behavior;
• audit-log quality;
• how easily security can revoke access.

Then deliberately test:

• malicious instructions embedded in source files;
• poisoned README files;
• hostile dependency documentation;
• secrets accidentally present in the repository;
• MCP/plugin installation;
• attempts to access files outside the project;
• attempts to exfiltrate environment variables;
• attempts to curl arbitrary external endpoints.

The goal isn't merely:

“Can the agent write good code?” It's:

“Can this agent be safely given access to our code by 30 developers?”

6. My architecture recommendation

For a 30-dev team, I'd use a tiered trust model:

Tier 1 — ordinary repositories

Agent can read/write repository files and create branches/PRs.

Tier 2 — sensitive repositories

Restricted agent, no arbitrary network access, no production credentials, tighter logging.

Tier 3 — crown-jewel code

Either no external agent at all, or a self-hosted/private inference architecture where your security team controls the complete data path.

And I'd make agent permissions narrower than developer permissions. An agent doesn't need your developer's AWS credentials simply because the developer has them.

What I'd shortlist

If I were running the evaluation, I'd probably start with:

1. GitHub Copilot Enterprise — especially if GitHub is already your source-control/identity platform.
2. Claude Code enterprise — particularly if agentic terminal workflows are important.
3. Amazon Q Developer Pro — particularly for an AWS-centric organization.
4. Cursor — include it if developer experience is compelling, but scrutinize its agent/network/plugin architecture carefully.

I would not choose based on “doesn't train on our code” alone. That's only one row in the security matrix.

The strongest selection criterion is:

Can I prove, contractually and technically, exactly where our source code goes, who can access it, how long it persists, and what autonomous actions the agent can take? If you can't answer those four questions, it's not ready for your proprietary repositories.

Rolling out a coding agent to a 30-developer team means shifting from individual productivity hacks to organizational risk management. When evaluating an AI coding assistant (like GitHub Copilot, Cursor, Windsurf, or specialized CLI agents), "not leaking your source code" boils down to verifying data governance, zero-retention policies, and strict tenancy boundaries.

Here is a practical, step-by-step framework for picking a secure coding agent:

1. Demand Zero Data Retention (ZDR)
   Ensure the vendor explicitly states that prompts, code snippets, and telemetry are not logged or stored on their servers post-inference, and absolutely never used to train foundational models. Check their enterprise privacy commitments (e.g., GitHub Copilot Trust Center).
2. Verify Compliance Certifications
   Do not accept marketing claims. Request and audit their compliance documentation. A baseline evaluation must include:
   • SOC 2 Type II attestation specifically covering the AI service sub-processors.
   • ISO/IEC 27001 certification.
   • GDPR/CCPA compliance alignments for developer telemetry.
3. Check Local vs. Cloud Indexing Boundaries
   Advanced agents index your whole repository to offer multi-file edits. You need to know: Where does that embedding vector database live?
   • Look for tools that do local-only indexing on the developer's machine or in an isolated, single-tenant cloud environment rather than a shared multi-tenant vector space.
4. Audit Enterprise Administration and Identity Management (IAM)
   You need centralized control. The tool must support:
   • SAML/OIDC SSO integration with your IdP (Okta, Azure AD/Entra ID).
   • Granular audit logs and seat management.
   • The ability to toggle off features globally (like web-search augmentations or third-party API integrations that send code contexts outside your boundary).
5. Review Model Provider Terms
   Many IDE extensions act as wrappers over foundational APIs (OpenAI, Anthropic, Google). Ensure that the data-privacy guarantees extend end-to-end through the underlying LLM provider (e.g., using enterprise/API tiers with zero-retention rather than consumer interfaces).

If you want to narrow this down, tell me:

• Are you leaning toward IDE-integrated forks/extensions (like Cursor/Copilot) or CLI/local agents (like Aider/Claude Code)?
• What is your primary cloud/compliance ecosystem (AWS, GCP, or Azure-heavy)?

Rolling out a coding agent to a 30-developer team means balancing developer velocity with absolute paranoia about your intellectual property. When evaluating tools (whether it's GitHub Copilot, Cursor, Codeium, or self-hosted alternatives), you need to look past the marketing fluff and audit the vendor's data lifecycle.

An evaluation framework designed to keep your source code out of public training sets and unauthorized hands includes the following steps:

1. Verify Training-Data Defaults (Opt-Out vs. Opt-In)
   • Confirm that your code, prompts, and completions are excluded by default from training public or foundational models.
   • Do not accept an opt-out policy that is buried deep inside a settings toggle or requires a separate enterprise contract addendum to enforce. It must be structurally guaranteed for your tenant.
2. Demand Zero Data Retention (ZDR)
   • Look for vendors that offer a strict Zero Data Retention mode. This ensures that your prompts and code context are held in volatile memory only long enough to process the inference request and are immediately purged from disk and logs.
   • Ask explicitly: Where are logs stored, how long are they kept, and do human reviewers ever see snippets of our proprietary code for "quality improvement"?
3. Check Compliance and Certifications
   • SOC 2 Type II is your baseline non-negotiable filter. If a vendor doesn't have it or isn't willing to share their latest audit report under an NDA, walk away.
   • If you operate in healthcare, fintech, or defense, verify additional compliance alignments like HIPAA, GDPR, or ISO 27001 depending on your regulatory footprint.
4. Audit Identity Management and Admin Controls
   • Ensure the tool integrates with your existing SAML/OIDC SSO and SCIM provisioning. When a developer leaves the team, revoking their Okta/Google Workspace access must instantly kill their AI agent seat.
   • Look for centralized management dashboards that provide visibility into seat utilization, audit logs, and domain restrictions.
5. Evaluate Deployment Architecture (Cloud vs. Air-Gapped/Self-Hosted)
   • For most standard SaaS companies, a multi-tenant cloud tool with strong data isolation and ZDR is sufficient.
   • If your codebase touches classified, highly regulated, or extreme IP domains, evaluate self-hosted or air-gapped coding agents (running local models like Llama 3 or CodeLlama via private infrastructure) where zero bytes leave your local VPC.

To help narrow down the right choice for your team, let me know:

• What is your tech stack and primary IDE?
• Do you have strict regulatory constraints (like HIPAA or SOC 2 for your own customers) that dictate where data can be processed?

For a 30-developer team, I would not pick a coding agent based on “best model” first. I would treat it like granting a new contractor access to your repositories: prove the data boundary, then optimize for developer velocity.

Here is the evaluation framework I’d use.

1. Start with a hard security gate

Reject any tool that cannot clearly answer these questions in writing (contract + documentation):

Enterprise plans often have materially different data terms than individual plans. For example, OpenAI states that business/API customer data is not used for training by default, and Anthropic states that commercial Claude Code usage is not used to train models unless customers opt in.

Do not let developers individually expense personal AI coding subscriptions and connect company repositories. That is where many accidental leaks happen.

2. Prefer enterprise identity and access controls

For a 30-person engineering org, I would require:

• SSO (preferably SAML/OIDC)
• SCIM user provisioning/deprovisioning
• Central billing
• Admin-enforced policies
• Audit logs
• Repository access controls
• Ability to disable features globally

A good agent should behave like GitHub access: when someone leaves the company, their access disappears automatically.

3. Decide your acceptable deployment model

Rank options from most controlled to least:

A. Self-hosted / private infrastructure

Best for highly sensitive IP.

Examples:

• Local models
• Private cloud deployment
• Vendor offering VPC/on-prem options

Tradeoff: more operational burden and often weaker models.

B. Enterprise SaaS agent

Usually the sweet spot.

You get:

• Strong models
• Security contracts
• Admin controls
• Less infrastructure work

C. Individual SaaS subscriptions

Avoid for company code.

Even when a vendor offers privacy controls, individual tiers can have different data-use defaults. For example, GitHub has documented different Copilot data policies between individual and business/enterprise offerings.

4. Test the agent like a security review, not a demo

Before rollout, create a pilot repo containing:

• Realistic architecture
• Fake secrets
• Proprietary-looking code samples
• Internal coding conventions
• Dependency files

Test:

Data leakage

Ask:

• Can a developer accidentally expose unrelated files?
• Does the agent send entire repositories or only relevant context?
• Are terminal outputs captured?
• Are logs exportable?

Permission boundaries

Try:

• Giving access to a repo with multiple projects
• Removing access mid-task
• Checking audit trails

Agent autonomy

Measure:

• Does it create PRs or directly modify protected branches?
• Does it run commands automatically?
• Does it access the network?
• Does it install dependencies?

Human approval gates matter. Security guidance increasingly emphasizes least privilege and review before irreversible actions because agents can amplify mistakes or follow malicious instructions hidden in files.

5. Put operating rules around the tool

A lightweight internal policy works well:

Allowed

• Refactoring
• Tests
• Documentation
• Boilerplate
• Code explanation
• Local debugging

Requires review

• Authentication changes
• Infrastructure changes
• Database migrations
• Dependency upgrades

Never provide

• Production credentials
• API keys
• Customer data
• Private certificates
• Secrets files

6. Score candidates

I would use something like:

Do not let “it writes code 15% better” outweigh “we cannot prove where our source went.”

7. Shortlist approach

For a 30-dev team, I would typically evaluate:

• A major enterprise IDE-integrated assistant
• A CLI/agent-style coding tool
• A Git-based autonomous PR agent

Then run a 2–4 week pilot with 5–8 developers:

• 2 senior engineers
• 2 mid-level engineers
• 1 security-minded engineer
• 1 tech lead
• 1 skeptical developer (valuable for finding failure modes)

The winner is the tool that your security team can approve and developers voluntarily keep using.

A useful final procurement question:

“If an engineer accidentally points this agent at our largest private repository tomorrow, can we prove exactly what data left our environment, where it went, who accessed it, and whether it was retained?” If the vendor cannot answer that clearly, it is not ready for a 30-person engineering rollout.

If the vendor cannot answer that clearly, it is not ready for a 30-person engineering rollout.

Yes. For a 30-person engineering org, I’d treat this as a security/vendor-risk decision first and a coding-quality decision second.

The key distinction is: “the vendor doesn't train on our code” is necessary, but not sufficient. An agent can avoid training while still transmitting source code to a provider, retaining it temporarily, indexing your repo, or allowing an autonomous agent to exfiltrate data through tools.

My selection framework

I’d score candidates on these dimensions:

That last one becomes particularly important with coding agents, because you're not merely sending snippets to autocomplete. You're giving software an ability to read files, execute commands, and potentially access the network.

What I'd shortlist

As of September 2026, three particularly defensible options are GitHub Copilot Enterprise, Claude Code under commercial/Enterprise terms, and Cursor Enterprise—but I'd configure them differently.

1. GitHub Copilot Enterprise — safest organizational default

If your company already lives in GitHub, this would probably be my first pilot.

GitHub explicitly says Copilot Business and Enterprise customer data isn't used to train its models. Its documented defaults also say IDE chat/completion prompts and suggestions aren't retained, although other Copilot surfaces can retain prompts for 28 days.

GitHub also provides enterprise controls and auditing for agent activity. Its cloud-agent ecosystem can now include third-party agents such as Claude and Codex, with security scanning of generated changes.

Why I'd like it for 30 developers: centralized identity, GitHub permissions, policy management, auditability, and relatively straightforward rollout.

Caveat: don't equate "Copilot Enterprise" with "nothing leaves our environment." Your code still goes through the relevant AI infrastructure/model providers. GitHub documents the hosting/data path for individual models, so your security review should examine the specific models you enable.

2. Claude Code Enterprise — excellent if you want a powerful terminal agent

Claude Code has an attractive security architecture because the agent runs on the developer's machine and reads only the portions of the repository it needs, rather than uploading the entire repository for indexing. Anthropic says commercial customers' inputs/outputs aren't used to train models by default.

It also supports explicit file-deny rules—for example, preventing an agent from reading .env files.

I'd choose this if: your senior developers are comfortable with terminal-based workflows and you want a genuinely agentic coding experience.

Important: configure permissions aggressively. A local agent is not automatically a safe agent. If it can execute shell commands and make network requests, a malicious repository or prompt injection could potentially persuade it to send information somewhere it shouldn't.

Anthropic's current policies also have some model-specific retention considerations, so I'd verify the exact Enterprise/ZDR configuration and models you're purchasing rather than relying on a blanket "zero retention" assumption.

3. Cursor Enterprise — compelling IDE-first option

Cursor's Enterprise documentation says Privacy Mode prevents code from being used for training and that Privacy Mode is enabled by default for Enterprise teams; admins can enforce it organization-wide.

But pay particular attention to Cloud Agents. Cursor explicitly says those agents need to store code and environment data in the cloud while they run. It also warns about prompt injection and the possibility of an autonomous agent being induced to exfiltrate code.

So I'd be comfortable piloting Cursor Enterprise, but I'd initially disable cloud-agent functionality for sensitive repositories.

The policy I'd put in place

For your 30 developers, I'd establish four tiers:

• Green: normal application repositories → coding agent allowed.
• Yellow: proprietary algorithms/customer integrations → agent allowed with restricted network access and approved models.
• Red: credentials, production infrastructure, signing keys, highly sensitive IP → agent cannot read these directories/files.
• Black: secrets themselves → never put them into an AI coding environment.

And I'd require:

1. Enterprise accounts only. No personal ChatGPT/Claude/Cursor accounts touching company code.
2. SSO + SCIM and centralized offboarding.
3. Privacy/no-training controls enforced by admins, not left to developers.
4. Secret scanning before code reaches the agent and again on generated commits.
5. Network egress restrictions for autonomous agents.
6. Read/write permissions scoped to the repo/worktree, not the developer's entire filesystem.
7. Human PR review remains mandatory. Agent-generated code should be treated exactly like code from an external contributor.
8. Log agent activity sufficiently to investigate an incident.
9. Quarterly vendor/subprocessor review.
10. Explicit approval before enabling cloud agents/MCP servers.

The test I'd actually run

Don't ask vendors, "Do you leak our code?"

Give them a controlled repository containing canary secrets—fake credentials and uniquely identifiable strings—and run the agent through realistic tasks.

Then test:

• Can it read files it shouldn't?
• Can it discover .env/credentials?
• Can it make arbitrary outbound HTTP requests?
• Can a malicious README cause it to exfiltrate the canary?
• What happens when it encounters a malicious dependency?
• Where does the source code travel?
• What gets retained?
• Can an administrator retrieve the interaction afterward?
• Can you revoke the agent's access immediately?
• What happens when an employee leaves?
• Can you prove deletion?

That exercise will tell you considerably more than a vendor's marketing page.

My practical recommendation

For 30 developers, I'd run a 2–3 week bake-off between Copilot Enterprise + Claude Code Enterprise, with Cursor Enterprise as the third candidate if your developers strongly prefer an IDE-centric experience.

I'd weight the evaluation roughly:

Security/privacy 40% → developer productivity 30% → code quality 20% → administration/cost 10%.

And I would make "no contractual training on customer code + documented data flows + enforceable admin controls" a hard gate, not something a vendor can compensate for with a better coding benchmark.

One particularly useful rule for your procurement team: never accept “we don't train on your data” as the complete answer. Ask “Who receives the data, what exactly is sent, where is it stored, how long, who can access it, what tools can the agent invoke, and can we enforce all of this centrally?”

Claude Code has an attractive security architecture because the agent runs on the developer's machine and reads only the portions of the repository it needs, rather than uploading the entire repository for indexing. Anthropic says commercial customers' inputs/outputs aren't used to train models by default.

It also supports explicit file-deny rules—for example, preventing an agent from reading .env files.

I'd choose this if: your senior developers are comfortable with terminal-based workflows and you want a genuinely agentic coding experience.

Important: configure permissions aggressively. A local agent is not automatically a safe agent. If it can execute shell commands and make network requests, a malicious repository or prompt injection could potentially persuade it to send information somewhere it shouldn't.

Anthropic's current policies also have some model-specific retention considerations, so I'd verify the exact Enterprise/ZDR configuration and models you're purchasing rather than relying on a blanket "zero retention" assumption.

3. Cursor Enterprise — compelling IDE-first option

Cursor's Enterprise documentation says Privacy Mode prevents code from being used for training and that Privacy Mode is enabled by default for Enterprise teams; admins can enforce it organization-wide.

But pay particular attention to Cloud Agents. Cursor explicitly says those agents need to store code and environment data in the cloud while they run. It also warns about prompt injection and the possibility of an autonomous agent being induced to exfiltrate code.

Rolling out autonomous coding agents to a 30-developer team means giving an external system deep read/write access to your intellectual property. To prevent source code leaks, model contamination, and compliance nightmares, you need a hard-nosed evaluation framework based on zero-trust principles.

The evaluation framework breaks down into critical screening steps, architecture checks, and contractual must-haves:

1. Zero Data Retention (ZDR) & Training Policies

• No Training on Your Code: Verify that the vendor’s foundational models are never trained on your prompts, code snippets, or completions. This must be guaranteed by default, not buried in an opt-out toggle.
• Zero Data Retention (ZDR): Look for enterprise tiers that guarantee prompts and generated code are processed in-memory and purged immediately, with no persistent storage on the vendor's side beyond immediate operational caching.
• Data Residency: Ensure the vendor allows you to lock data processing and storage to specific geographic regions (e.g., EU-only or US-only) to meet regulatory requirements like GDPR or HIPAA.

2. Compliance and Certifications

• SOC 2 Type II: This is non-negotiable baseline proof that the vendor has operational controls in place for data security. Request their latest audit report, not just a badge on their landing page.
• ISO/IEC 27001: Validates that the organization follows an internationally recognized standard for managing information security risks.
• Enterprise BAAs / DPAs: Ensure the vendor is willing to sign a customized Data Processing Agreement (DPA) or Business Associate Agreement (BAA) that outlines strict liability if a leak occurs through their infrastructure.

3. Deployment Architecture & Access Control

• Self-Hosted or VPC Options: For ultra-sensitive codebases, evaluate agents that can run locally (via Ollama/vLLM with open-weights models like Llama 3 or DeepSeek variants) or inside your private cloud (VPC). Zero external API calls mean zero chance of transit leakage.
• Identity Provider (IdP) Integration: The tool must support SAML/OIDC and integrate with your corporate SSO (Okta, Azure AD/Entra ID) and SCIM for automated provisioning/deprovisioning.
• Granular Repository Scoping: Avoid granting the agent blanket access to your entire GitHub/GitLab organization. Pick a tool that lets you scope permissions strictly to designated non-critical repositories first (e.g., internal tools or frontend components) before moving to core backend monoliths.

4. Supply Chain and Prompt-Injection Defense

• Indirect Prompt Injection: Coding agents that read issues, pull requests, or external READMEs are vulnerable to malicious instructions hidden in text. Ensure the agent sanitizes inputs and doesn't blindly execute shell commands or exfiltrate environment variables via API calls.
• Audit Logging: The platform must provide robust audit logs detailing which developer triggered which agent, what context was read, and what code was committed. This is vital for post-incident forensics.

If you'd like, let me know:

• Are you looking for cloud-hosted SaaS (like GitHub Copilot Enterprise or Cursor) or do you need a self-hosted/VPC solution?
• What version control and CI/CD platform (GitHub, GitLab, Bitbucket) are you using?

I can help tailor a shortlist of specific vendors that match your security posture.

Rolling out an AI coding agent to a 30-developer team means moving past individual "freemium" developer tools and evaluating platforms through a strict enterprise risk lens. Unlike passive code completers, autonomous or semi-autonomous coding agents require deep repo context, access to local files, terminal execution, and sometimes external API calls—making data governance non-negotiable.

To pick an agent that won’t leak your source code, use this pragmatic evaluation and verification framework.

1. Demand Explicit Zero Data Retention (ZDR) & Training Exclusions

Never rely on marketing copy or terms of service on a public pricing page. You need contractual guarantees.

• No Model Training: Ensure the vendor's enterprise agreement explicitly states that your code snippets, prompts, completions, and repo maps are never used to train foundational or fine-tuned models.
• Zero Data Retention (ZDR): The provider must purge prompt and response data from their servers immediately after processing. Transient logging in memory for abuse monitoring is acceptable only if strictly time-bounded and encrypted, but local-only or ephemeral processing is ideal.
• Third-Party Pass-Through: If the coding agent relies on a backend LLM from a third party (e.g., OpenAI, Anthropic, Google), verify that the ZDR and no-training clause legally binds both the agent provider and the underlying model provider.

2. Scrutinize Certifications and Compliance

At a 30-dev scale, you shouldn't be doing custom security audits for every tool. Look for third-party validation:

• SOC 2 Type II: Insist on a current SOC 2 Type II report specifically covering the Confidentiality and Security trust services criteria. A Type I only proves design at a moment in time; Type II proves the controls actually operated effectively over a period.
• ISO/IEC 42001 / ISO 27001: Increasingly standard for AI management systems and information security governance.

3. Check Data Boundaries and Context Handling

How the agent reads your codebase matters just as much as where it sends the data.

• Exclusion Controls (.gitignore / custom filters): The platform must allow you to block specific files and directories globally (e.g., .env, secrets.yaml , private keys, proprietary core algorithms) so developers don't accidentally leak secrets into an agent context window.
• Local vs. Cloud Indexing: Some advanced agents build local AST (Abstract Syntax Tree) indexes on the developer’s machine and only send minimal, relevant code chunks to the LLM. Others clone or index your entire remote GitHub/GitLab repo into a cloud vector database. If they use cloud indexing, demand to know where that vector store lives, how long it persists, and how it is encrypted (at rest and in transit).

4. Enforce Identity and Access Management (IAM)

• SSO / SCIM Integration: The tool must integrate with your corporate identity provider (Okta, Azure AD/Entra ID, Google Workspace) via SAML.
• Granular Admin Controls: As an engineering manager, you need a central dashboard to provision/deprovision licenses instantly, audit usage, and enforce policy changes organization-wide rather than trusting individual developer logins.

5. Evaluate Deployment Architecture Options

Depending on how sensitive your IP is (e.g., if you're in fintech, healthtech, or defense), cloud-hosted SaaS might be a non-starter.

• SaaS with Enterprise Privacy: Fine for most standard SaaS applications; relies on strict legal agreements and ZDR cloud APIs.
• VPC / Tenant-Isolated Deployment: Some enterprise tiers allow you to run the infrastructure within your own Virtual Private Cloud (AWS/GCP), keeping data inside your perimeter.
• Self-Hosted / On-Premise LLMs: Running fully local models (via tools like Ollama or enterprise gateways) paired with an open-source or self-hosted agent interface. This provides a mathematically airtight guarantee against data leakage, though at the cost of model capability and infrastructure overhead.

Red Flags: When to Walk Away

• The vendor claims enterprise security, but their documentation says they "may use anonymized telemetry/code to improve our products" without an opt-out.
• They cannot provide a recent SOC 2 Type II report upon request.
• The tool requires a personal user account linked to a public consumer plan rather than an organization-managed enterprise tenant.
• They force full remote repository synchronization without letting you audit or restrict which branches/repos the agent can access.

If you'd like, let me know:

• What industry or compliance standards (e.g., HIPAA, SOC 2, FedRAMP) your company operates under
• Whether your team prefers IDE extensions (like Cursor or VS Code extensions) vs. CLI/terminal agents

I can narrow down specific tool recommendations that fit your security posture.

For a 30-dev team, I would not pick a coding agent based primarily on model quality. Pick it like you would pick a production dependency: define the data boundary, prove the controls, then optimize for developer productivity.

The core question is:

“Can this agent see our source code, where does that code go, how long is it retained, and what contractual guarantees do we have?” A useful evaluation framework:

1. Eliminate tools that fail your data boundary requirements

Create a hard security checklist. A vendor should be able to answer these clearly:

Be careful with “privacy mode” language. Some products distinguish between not retaining data and not sending data at all; those are different security properties.

2. Prefer enterprise tiers, not individual licenses

Many AI coding tools have materially different policies between consumer and enterprise offerings. For example, GitHub has stated that Copilot Business and Enterprise are not affected by certain consumer-plan interaction-data policies. The GitHub Blog Anthropic similarly states that commercial products such as Claude Enterprise and API usage do not train models on customer data by default.

For a company rollout, avoid:

• developers signing up individually with personal accounts
• reimbursing consumer subscriptions
• “everyone uses whatever AI tool they like”

That creates an invisible data exfiltration path.

3. Run a 2-week security pilot

Pick 5–8 engineers from different areas.

Give them:

• a non-critical repo first
• synthetic secrets/data
• a clear policy on what repositories are allowed

Test:

Data handling

• Inspect network calls if your security team can do so.
• Confirm what files are sent.
• Confirm whether terminal output, logs, and prompts are stored.

Permission boundaries

Try:

• a repo with multiple projects
• a repo containing secrets accidentally committed historically
• a developer account with limited permissions

Ask:

• Can the agent read things it shouldn't?
• Can it modify files outside the workspace?
• Can it execute commands without approval?

Modern agents can run commands and interact with external systems, so the permission model matters as much as the model itself.

4. Decide what level of autonomy you actually want

For a 30-person engineering org, I would usually stage it:

Phase 1: Assistant mode

Allowed:

• explain code
• write tests
• refactor small functions
• generate documentation

Required:

• human review of all changes

Phase 2: PR-producing agents

Allowed:

• create branches
• modify code
• run tests
• open pull requests

Required:

• branch protection
• mandatory reviewers
• CI checks

Phase 3: Higher autonomy

Only for:

• sandbox repos
• migrations
• repetitive maintenance

Avoid giving an agent:

• production credentials
• deployment permissions
• unrestricted repository access

5. Score vendors with a simple rubric

I would weight it roughly:

A brilliant model with unclear data handling should lose.

6. Establish internal rules before rollout

A one-page policy prevents most problems:

Allowed

• company-approved AI coding tools
• approved repositories
• code review required
• secrets never included in prompts

Not allowed

• personal AI accounts for company code
• uploading proprietary code into chatbots
• pasting credentials/tokens
• connecting agents to production systems without approval

Security guidance commonly emphasizes keeping secrets, tokens, and sensitive files out of coding-agent context because agents may access whatever is exposed in their workspace.

Shortlist approach

For a 30-dev team, I would evaluate:

• GitHub Copilot Enterprise/Business if you are already GitHub-centric
• Claude Code through an enterprise/API arrangement if you value agentic workflows
• Cursor Enterprise if IDE experience is a priority
• Self-hosted/private options if your code is highly sensitive

But I would not declare a winner until each vendor passes your own security review. Vendor policies and defaults change frequently, so treat current documentation and contracts—not reputation—as the source of truth.

A practical next step: create a one-page “AI coding agent security questionnaire” and send it to 3 vendors before any pilot. That will usually eliminate the risky options quickly.