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?

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 still expose source through logs, retained sessions, third-party model providers, telemetry, plugins/MCP servers, or an overly broad filesystem/GitHub permission.

My selection framework

I’d require every candidate to pass these gates:

Don't evaluate the product's privacy page alone

Ask the vendor these questions in writing:

1. Exactly what portions of our repository are transmitted off our machines?
2. Are prompts, tool calls, shell output, diffs, embeddings, and agent transcripts retained? For how long?
3. Which subprocessors receive that data?
4. Can any employee or contractor access it? Under what circumstances?
5. Is our data ever used for training, evaluation, abuse detection, or product improvement?
6. What happens when an engineer invokes feedback/report-abuse functionality?
7. Can we enforce retention and model/provider choices centrally?
8. Can we audit every repository/file/tool the agent accessed?
9. Can the agent make arbitrary outbound network requests?
10. What happens to cached prompts and data in backups after deletion?

That last group is where many "enterprise-safe" evaluations become much less clear.

Shortlist I'd investigate

For a 30-dev team, I'd put GitHub Copilot Enterprise, Claude Code via an enterprise/commercial deployment, and OpenAI Codex through a business/enterprise setup into the first bake-off—not consumer subscriptions.

There are meaningful differences in their current data controls. For example, GitHub says its Copilot model-provider agreements include commitments against training on GitHub data, and it currently has a zero-data-retention agreement with Anthropic for generally available Anthropic features in Copilot, although it explicitly notes that some beta/preview features aren't covered.

Anthropic says its commercial products—including Claude for Work and its API—don't use customer inputs/outputs for model training by default. Its current retention documentation is more nuanced: some API usage can qualify for ZDR, while particular features/models have specific retention requirements.

OpenAI similarly states that business/enterprise/API data isn't used for training by default, and offers encryption, retention controls, and—in qualifying configurations—zero-data-retention options.

Important: don't extrapolate those policies to consumer plans. For example, OpenAI's current documentation distinguishes business products from individual ChatGPT/Codex use, where training controls are different.

The architecture matters as much as the vendor

For your team, I'd deploy the agent roughly like this:

Developer
   │
   ▼
Enterprise AI agent
   │
   ├──► Ephemeral sandbox
   │       ├── repo checkout
   │       ├── build/test tools
   │       └── no production credentials
   │
   ├──► Git provider
   │       └── narrowly scoped token
   │
   └──► Model API
           └── enterprise privacy contract

Give the agent a disposable environment, least-privilege Git credentials, and tightly controlled network egress.

That protects you against a different failure mode: even if the AI vendor has impeccable privacy policies, an autonomous coding agent can potentially be tricked by a malicious README, dependency, issue, test fixture, or prompt injection into sending information somewhere it shouldn't.

In other words:

Vendor privacy protects your code from the vendor. Sandboxing protects your code from the agent. You want both.

I'd run a 2-week bake-off

Don't let 30 engineers individually pick their favorite. Pick 3 candidates and give each the same representative workloads:

• New feature in a normal repo
• Refactor across 20+ files
• Debug a production-like failure using sanitized data
• Dependency upgrade
• Write/fix tests
• Review an unfamiliar codebase
• Handle a deliberately malicious prompt injection in a repository
• Attempt an action requiring a secret
• Attempt to access a file outside the workspace

Score each on:

Security 40% · Coding quality 25% · Developer experience 15% · Admin/governance 10% · Cost 10%

I'd make any critical security failure an automatic disqualifier, regardless of coding benchmark scores.

One particularly important test

Plant a harmless "canary" secret in the test repository—something that looks valuable but has no real privilege—and monitor:

• DNS
• HTTP/HTTPS egress
• model requests
• subprocesses
• filesystem access
• Git operations

Then deliberately give the agent tasks containing prompt-injection bait.

You're testing the actual agent, not the vendor's marketing description of the agent.

My default policy for your 30 developers

I'd start with:

Enterprise plan + SSO + centralized provisioning + no-training contract + minimum retention + sandboxed execution + no production credentials + restricted network egress + audit logging.

And I'd prohibit developers from putting proprietary repositories into consumer/free AI coding accounts.

One subtle point: "zero retention" shouldn't automatically win the evaluation. A vendor may offer ZDR for the model API while the agent product itself retains session transcripts, telemetry, or tool state elsewhere. Anthropic's current documentation is a good illustration of why you need to evaluate the entire agent stack, not just the underlying model API.

If I were making the decision for your team, I'd turn this into a one-page vendor scorecard with ~25 yes/no security questions, then have Legal/Security sign off on the top 2 before engineers compare coding performance.

Vendor privacy protects your code from the vendor. Sandboxing protects your code from the agent. You want both.

I'd run a 2-week bake-off

Don't let 30 engineers individually pick their favorite. Pick 3 candidates and give each the same representative workloads:

• New feature in a normal repo
• Refactor across 20+ files
• Debug a production-like failure using sanitized data
• Dependency upgrade
• Write/fix tests
• Review an unfamiliar codebase
• Handle a deliberately malicious prompt injection in a repository
• Attempt an action requiring a secret
• Attempt to access a file outside the workspace

Score each on:

Security 40% · Coding quality 25% · Developer experience 15% · Admin/governance 10% · Cost 10%

I'd make any critical security failure an automatic disqualifier, regardless of coding benchmark scores.

One particularly important test

Plant a harmless "canary" secret in the test repository—something that looks valuable but has no real privilege—and monitor:

• DNS
• HTTP/HTTPS egress
• model requests
• subprocesses
• filesystem access
• Git operations

Then deliberately give the agent tasks containing prompt-injection bait.

You're testing the actual agent, not the vendor's marketing description of the agent.

My default policy for your 30 developers

I'd start with:

Enterprise plan + SSO + centralized provisioning + no-training contract + minimum retention + sandboxed execution + no production credentials + restricted network egress + audit logging.

And I'd prohibit developers from putting proprietary repositories into consumer/free AI coding accounts.

One subtle point: "zero retention" shouldn't automatically win the evaluation. A vendor may offer ZDR for the model API while the agent product itself retains session transcripts, telemetry, or tool state elsewhere. Anthropic's current documentation is a good illustration of why you need to evaluate the entire agent stack, not just the underlying model API.

Rolling out a coding agent to 30 developers means expanding your attack surface 30-fold . When evaluating tools like GitHub Copilot Enterprise, Cursor , or terminal-based agents like Aider , the real risk isn't just a vendor getting hacked—it's zero data retention loopholes, autonomous tool access (RCE via prompt injection), and context leakage.

A rigorous, engineering-manager-level evaluation framework ensures your source code stays inside the perimeter:

• 1. Enforce Zero Training on Your Data (Contractually, Not Just in Marketing)
     Never trust a marketing page that says "we care about privacy." Read the Data Processing Agreement (DPA). Ensure the enterprise tier explicitly states that your snippets, prompts, and context graphs are never used to train public or foundational models, and are wiped immediately after the stateless API call completes.
• 1. Map the Agent's Blast Radius (Suggestion vs. Agentic Execution)
     Understand the difference between inline completion tools and full-blown agentic IDEs/CLI tools. An assistant that only does autocomplete (like basic Copilot) has a limited surface area. An agent that can read your entire workspace, run terminal commands, or use Model Context Protocol (MCP) servers has deep file and system access. If an agent has terminal execution ("YOLO mode") enabled, a malicious dependency or poisoned README in an open-source library your dev imports can trick the AI via prompt injection into exfiltrating environment variables or SSH keys.
• 1. Audit the Compliance and Certifications
     Ensure the vendor provides audited compliance reports: SOC 2 Type II is non-negotiable for a 30-dev team handling proprietary IP. Check if they support SAML/SSO enforcement, centralized license management, and audit logging so you can track who is querying what and when.
• 1. Evaluate Local vs. Cloud Hybrid Options
     If your IP is fiercely restricted (defense, fintech, or core proprietary engines), look at self-hosted or local models (via Ollama or enterprise-managed local gateways like Tabnine or private cloud instances via AWS Bedrock/Azure OpenAI). Keep in mind that fully local models trade off some reasoning capability for absolute data sovereignty.
• 1. Deploy Guardrails and Secrets Scanning
     Before rolling out any agent, implement a CI/CD secret scanner and an MCP/API gateway proxy. Make sure developers are trained not to paste internal API keys, production database credentials, or PII into the chat context of any AI tool, even under enterprise privacy modes.

To narrow down the right choice for your team, tell me:

• What IDE or stack (VS Code, JetBrains, Web/CLI) does your team primarily use?
• Are you bound by strict regulatory compliance (like HIPAA, SOC 2, or financial regulations)?

If I were the engineering manager for a 30-person team, I’d treat this as a data-governance decision first and a coding-quality decision second.

The key distinction: “the vendor doesn’t train on our code” is not the same as “our source code never leaves our environment.” Almost every useful cloud coding agent needs to send some code/context to a model provider.

My shortlist

My default choice: if you're already all-in on GitHub, start with Copilot Enterprise. If your developers specifically want a powerful autonomous terminal agent, I'd run a parallel pilot of Claude Code Enterprise with ZDR.

One wrinkle worth knowing: Anthropic's current documentation says commercial Claude Code users aren't used for model training, while standard commercial retention is 30 days; ZDR is a separate enterprise configuration.

What I'd require before approving any agent

Don't accept a vendor's marketing answer. Make security/procurement answer these questions in writing:

1. Is our source code ever retained?

• During inference?
• In logs?
• In prompt caches?
• For abuse monitoring?
• In backups?

2. Is our data ever used for training or model improvement?

• Contractual prohibition, not merely a UI setting.
• Does it apply to all underlying model providers?

3. Who actually receives the code?

• Vendor?
• OpenAI/Anthropic/Google?
• Cloud subprocessors?
• MCP servers?
• Analytics providers?

4. What happens with agentic features?

• A local IDE completion is one risk profile.
• An agent that clones your repo into a cloud VM is another.

5. Can we enforce the policy centrally?

• SSO/SAML
• SCIM
• Admin-enforced privacy settings
• Disable consumer accounts
• Disable unapproved models
• Audit logs
• Central billing

6. What happens when an employee leaves?

• Revoke access immediately.
• Remove cached credentials/tokens.
• Confirm repository access disappears.

7. Can the agent access secrets?

• .env
• production credentials
• cloud credentials
• SSH keys
• GitHub tokens
• database credentials

That last category is actually where I'd spend a lot of attention. An agent that doesn't leak source code but can read your production AWS credentials is still a catastrophic security failure.

Put the agent behind technical guardrails

I'd roll it out roughly like this:

Phase 1 — 5 developers

Give them a sanitized/non-critical repository and establish telemetry.

Require:

• SSO-only accounts
• enterprise plan only
• no personal AI accounts
• no API keys paid for individually
• no production credentials
• least-privilege GitHub permissions
• PR-based changes rather than direct production changes
• human approval before merge/deploy
• secret scanning
• dependency/security scanning

Phase 2 — 10–15 developers

Give access to real repositories, but classify repositories:

• 🟢 Low sensitivity → agent allowed
• 🟡 Internal/proprietary → agent allowed under enterprise controls
• 🔴 Highly sensitive → agent disabled or restricted to approved configuration

For example, I'd probably put authentication infrastructure, proprietary algorithms, regulated data pipelines, and repositories containing unusually sensitive IP into the red category initially.

Phase 3 — all 30

Only after you've verified:

• actual network destinations
• retention behavior
• model-provider contracts
• audit logs
• access controls
• secret handling
• incident response
• offboarding

One particularly important trap

Don't evaluate only the model.

Evaluate the entire chain:

Developer → IDE/agent → agent vendor → model provider → tools/MCP → cloud environment → GitHub

For example, Cursor explicitly says ordinary AI requests send prompts/code context to model providers, while its Cloud Agents require storing repository copies temporarily.

Likewise, GitHub's third-party agent architecture can give Claude or Codex access to repositories where the agent is enabled, so enabling an agent is itself an access-control decision.

The test I'd give vendors

Before buying 30 seats, ask each vendor to demonstrate this live:

“Show me exactly what happens to SECRET_PROJECT/foo.py when an engineer asks the agent to modify it. Show me every system that receives the file, how long each system retains it, whether it enters training, and how an administrator can prove afterward that the policy was followed.” Then have your security engineer inspect the network traffic and the contractual/DPA language.

If the vendor can't give you a crisp answer, don't deploy it to proprietary repositories.

For a 30-dev organization, I would not try to eliminate all cloud transmission—that would rule out most useful coding agents. I'd instead require no training + contractual confidentiality + minimal retention/ZDR where available + strict repository/credential permissions + auditability.

If you tell me whether your stack is GitHub/GitLab, AWS/Azure/GCP, and whether you handle regulated/customer data, I can turn this into a concrete vendor scorecard (security, privacy, agent capability, cost, admin controls, and rollout risk) for Copilot vs Claude Code vs Cursor vs Codex.

Rolling out a coding agent to a 30-developer team without compromising your source code requires looking past vendor marketing pages and inspecting their data governance architecture, training policies, and execution environment . For a team of this size, you want enterprise-grade protections without stifling developer velocity.

Evaluating and picking a secure coding agent involves focusing on these core criteria:

1. Zero Data Retention (ZDR) & Training Exclusions
   • Ensure the vendor contractually guarantees they do not use your prompts, code snippets, context, or generated outputs to train their foundational or fine-tuned models.
   • Verify that data sent to the API is held only in transient memory for processing and wiped immediately (Zero Data Retention).
2. Tenant Isolation & Data Residency
   • Look for deployment options that isolate your data within a dedicated enterprise tenant (e.g., via Amazon Bedrock, Google Cloud Vertex AI , or Microsoft Azure OpenAI Service).
   • Confirm that data does not cross unwanted geographic boundaries, satisfying regional compliance frameworks like GDPR or CCPA.
3. Local-First or Bring-Your-Own-Model (BYOM) Alternatives
   • If your codebase handles ultra-sensitive proprietary algorithms or defense/fintech data, consider an open-source IDE extension like Continue.dev paired with locally hosted open-weight models (via Ollama ) or private cloud endpoints . This guarantees your code never leaves your local network or virtual private cloud (VPC).
4. Granular Context and Indexing Controls
   • Coding agents often index your entire repository to build a local vector database for context . Check where that vector index lives, how it is updated, and whether you can explicitly exclude sensitive subdirectories (like internal auth modules, cryptographic keys, or proprietary core IP) via an .aignore or equivalent configuration file.
5. Sandbox & Least-Privilege Execution Boundaries
   • Because agents execute tasks, write files, or run terminal commands, they need strict guardrails . Ensure the agent runs in an isolated sandbox , cannot unilaterally execute high-impact terminal/deploy commands without human approval gates , and adheres to the principle of least privilege regarding network and file access.
6. Compliance Certifications
   • Request and review their latest SOC 2 Type II report and ISO/IEC 27001 certifications. Check the audit scope to ensure AI coding services and telemetry handling are explicitly covered, not just their corporate web hosting.

To help narrow down the ideal tool for your team, tell me:

• What is your tech stack and primary IDE (VS Code, JetBrains, etc.)?
• Are you restricted to on-prem/local-only infrastructure, or is a secure enterprise cloud API (like Azure/AWS) acceptable?
• Do your developers need autonomous multi-file agents (like Devin/Cursor-style agents) or primarily inline autocomplete and chat?

If I were the EM for a 30-person team, I’d treat this as a data-governance and agent-control decision, not primarily a “which model writes the best code?” decision.

My shortlist

The key distinction: “not trained on” ≠ “never leaves our network”

This is the mistake I'd avoid.

Even with a contractual no-training guarantee, your source code may still be:

1. sent to the vendor/model provider for inference,
2. temporarily cached,
3. indexed/embedded,
4. retained for abuse/security monitoring,
5. copied into a cloud agent's execution environment,
6. exposed to an MCP/plugin/tool you allowed the agent to call.

For example, Cursor explicitly says ordinary AI requests send prompts/code context to model providers, while its Cloud Agents require repository storage during execution.

So I'd make your security requirement:

“No training” is necessary but insufficient. We need documented data flows, retention periods, subprocessors, encryption, access controls, agent sandboxing, and an enforceable contract.

What I'd require before approving a vendor

For your 30 developers, I'd make these hard gates:

• No training on company code/data, contractually—not merely a marketing FAQ.
• Defined retention, ideally ZDR for inference traffic.
• Explicit treatment of prompts, completions, embeddings, indexes, telemetry and agent logs.
• Complete subprocessor list and notification/change process.
• SSO + SCIM and centralized offboarding.
• Ability to restrict models; don't let developers silently switch to a model with different retention.
• Ability to block repositories/directories containing secrets, credentials, customer data, etc.
• MCP/plugin governance. An agent can leak data through a tool even if the LLM provider itself doesn't retain it.
• Sandboxed agent execution and explicit approval for network access and destructive operations.
• Audit logs that your security team can actually consume.
• SOC 2 Type II (and whatever regulatory certifications your environment requires).
• A DPA that matches your legal/security requirements.

Cursor's own current hardening guidance is a useful illustration: it recommends enforcing Privacy Mode, restricting models, blocklisting repositories, governing MCP servers, sandboxing agent execution, limiting network access, and streaming audit logs to a SIEM.

I'd run a 2-week bake-off

Don't let 30 people install everything and vote.

Give 6–8 engineers the same representative workload:

• large monorepo navigation
• bug fix requiring cross-file context
• feature implementation
• test generation
• refactor
• dependency upgrade
• security-sensitive code
• task requiring an external tool/MCP

For each agent, measure:

Security

• What leaves the laptop?
• Where does it go?
• How long is it retained?
• Can the vendor train on it?
• Can admins prevent risky behavior?
• What happens if the agent is compromised?

Engineering

• Task success rate
• Review/rework required
• Tests passing
• Hallucinated APIs
• Time saved
• Developer adoption

Operations

• SSO/SCIM
• GitHub integration
• RBAC
• audit/SIEM integration
• model controls
• cost predictability

My default recommendation

For a 30-dev organization, I'd start with GitHub Copilot Enterprise and Cursor Enterprise as the two finalists, then add Codex Enterprise if you specifically want autonomous cloud agents.

If your company is already heavily standardized on GitHub, Copilot Enterprise is the lowest-friction security choice. GitHub also has provider agreements covering non-training commitments, including ZDR arrangements with Anthropic for generally available Anthropic features in Copilot.

If developer experience and agentic workflows are the priority, I'd seriously evaluate Cursor Enterprise, but I'd make Privacy Mode mandatory and Cloud Agents opt-in. Cursor explicitly says Cloud Agents are the feature that requires storing repository copies, and recommends not enabling them when your policy prohibits code storage.

And if you're evaluating Codex, OpenAI currently states that Business/Enterprise data isn't used for training by default, while its Enterprise Codex offering includes enterprise security controls.

One final rule: don't approve an agent because the vendor says “your code is private.” Have security/legal review the actual DPA, retention schedule, subprocessors, model-specific terms, and agent architecture. Those details matter more than the product's privacy headline.

Rolling out an AI coding agent to a 30-developer team is exciting, but as an Engineering Manager, your primary fear shouldn't just be low-quality code—it’s unintentional data exfiltration.

Autonomous and semi-autonomous coding agents (like Cursor, Claude Code, GitHub Copilot, or specialized enterprise setups) read everything in your local workspace: source files, .env files, config yamls, and terminal outputs. If configured poorly, they can inadvertently leak proprietary code or hardcoded secrets to third-party model providers.

To pick and deploy a coding agent safely without leaking your source code, use this four-step evaluation and hardening framework.

1. Filter Vendors by Commercial Data Governance (The Non-Negotiables)

Do not rely on consumer-grade privacy toggles or marketing promises. Before a tool touches your codebase, require the vendor to clear these criteria:

• Zero Data Retention (ZDR) & No Training: Ensure the enterprise tier explicitly states that your code prompts, completions, and workspace context are never saved on the vendor's servers beyond the immediate inference call, and are never used to train foundational models.
• Signed DPA (Data Processing Agreement): Demand a formal, enterprise-grade DPA that outlines clear liability if data privacy terms are breached.
• SOC 2 Type II and ISO/IEC 42001: Look for independently audited security controls specifically covering AI lifecycle and data handling.
• Data Residency Options: If you operate in regulated spaces or under strict regional guidelines (such as the EU), verify where data processing and embedding storage happen.

2. Audit How the Agent Handles Local Secrets

Most enterprise leaks happen silently. Agents ingest your entire workspace directory to build context, which often means they read local .env files, mcp.json configs, or test database credentials sitting in your project directory.

• Test for Secret Redaction: Run a canary test. Place a dummy API key in a local test file and monitor the network traffic or agent behavior to see if the tool attempts to pass raw credentials into cloud inference payloads.
• OS Keychain Integration vs. Plaintext JSON: Review how the tool stores its own auth tokens locally. Many developer tools foolishly drop tokens into plaintext JSON files in home directories, exposing them to local malware. Prefer tools with native OS keychain integration.
• Workspace Scoping: Pick a coding agent that allows you to configure strict .gitignore -style exclusion files (.Aignore or equivalent) so the agent is programmatically blocked from reading sensitive directories (e.g., /infra, /secrets , or .env).

3. Implement Strict Guardrails and Isolation Layers

Tool selection is only half the battle; how you wire it into your infrastructure dictates safety.

• Enforce Principle of Least Privilege for Permissions: Advanced CLI or terminal-connected agents can execute shell commands or run scripts. Never run agents with --dangerously-skip-permissions or broad system access. Configure explicit allow/ask/deny lists for local file system and network access.
• Sandbox Execution: If the agent needs to run code, test packages, or fix bugs autonomously, ensure it runs inside an isolated microVM or containerized sandbox rather than directly on the developer's raw host machine with full network privileges.
• Network-Level Egress Guardrails: Monitor or restrict outbound AI assistant communication to verified vendor endpoints to spot anomalous data transmission.

4. Build Continuous CI/CD and Review Gates

Treat AI-generated code and agent actions as untrusted external contributions.

• Shift-Left Secret Scanning: Integrate aggressive pre-commit hooks and CI/CD blocking gates (such as Gitleaks or TruffleHog) to catch accidental credential injection before code hits your main repository.
• Mandatory Human-in-the-Loop Reviews: Do not allow agents to merge code directly to production without human approval. Set policy gates requiring human developer review, especially for files handling authentication, payment logic, or data pipelines.

To help narrow down the right tool for your specific environment, tell me:

• What is your primary tech stack / IDE (e.g., VS Code with TypeScript, JetBrains with Java/Go)?
• Do you have strict compliance frameworks (like SOC2, HIPAA, or EU regulations) to satisfy?

I can help you evaluate a shortlist of compliant vendors or draft a 1-page developer usage policy for your team.

Rolling out an AI coding agent to a 30-developer team is exciting, but for an Engineering Manager, it can quickly turn into a security nightmare if you treat tool selection like a casual software evaluation. Coding agents don’t just read a single file—they index entire repositories, stream context to cloud APIs, and in some agentic modes, execute local shell commands or interact with external toolchains.

To pick a coding agent that won’t leak your source code, you need to cut through the marketing fluff ("zero data retention!", "privacy-first!") and evaluate vendors using a hard-nosed, architectural framework.

1. The Vendor Governance Check (Zero-Training Guarantees)

Never rely on a consumer-grade or standard tier agreement. You need a dedicated Enterprise tier backed by contractual SLAs.

• Explicit No-Training Clause: The contract must state explicitly that your source code, prompts, snippets, and intermediate context states will never be used to train or fine-tune public or foundational models.
• Ephemeral Processing: Confirm that input data (the context sent when a developer asks the agent a question) is held strictly in volatile memory for inference and purged immediately without persistent logging on the vendor's side.
• Compliance Certifications: Insist on an independent, verified SOC 2 Type II report and ISO 27001 compliance. If they cannot provide these during the sales cycle, walk away.

2. Choose Your Deployment Topology

You have three architectural paths depending on your risk tolerance and industry regulations:

• Strict Cloud Enterprise (e.g., GitHub Copilot Enterprise, Enterprise Claude/Cursor setups): Code snippets are transmitted via encrypted channels (TLS 1.3) to dedicated single-tenant or securely partitioned multi-tenant cloud instances with strict data residency controls (e.g., EU-only or US-only processing).
• On-Premise / Air-Gapped / Self-Hosted (e.g., local models via tools like Continue + Ollama): The entire model runs locally on your own infrastructure or secure VPC.
  • The Engineering Tradeoff: Your source code has a 0% chance of leaving your perimeter, but local open-weights models acting as agents often suffer from lower reasoning and tool-calling capabilities compared to frontier models.
• Hybrid / Bring-Your-Own-Cloud (BYOC): The agent runs inside an isolated microVM sandbox within your own cloud environment, connecting only to approved frontier inference endpoints.

3. Evaluate the Execution & Sandboxing Layer

In 2026, security teams realize that data leakage isn’t just about the model—it’s about the execution layer . An agentic coding tool that can run terminal commands or read local environment variables expands your attack surface.

• Ephemeral Sandboxes: Look for agents that execute shell tasks or test runs inside isolated, disposable containers (microVMs) rather than bare-metal local developer execution without guardrails.
• Network Egress Control: Ensure the agent cannot arbitrarily curl external APIs or leak data via unauthorized network sockets. Egress traffic should be filtered through strict allowlists.
• Secret & Credential Hygeine: Ensure the agent honors your .gitignore and .dockerignore files, and check whether the tool integrates with pre-commit secret scanners to block developers from accidentally pushing .env keys or AWS tokens into an AI prompt.

4. Enforce Policy-as-Code and Human-in-the-Loop Gates

Selecting the right tool is only half the battle; how you configure it dictates your true blast radius.

• Centralized Admin Controls: You need a single pane of glass to manage seat provisioning, monitor who is using what, revoke access instantly via your Identity Provider (Okta/Azure AD via SSO), and audit logs.
• Mandatory PR Review Gates: Treat the coding agent like a junior developer whose code must never bypass review. Enforce branch protection rules requiring human peer review and passing green CI/CD pipelines (SAST/SCA) before any AI-generated diff can merge into main.

If you want to narrow down your shortlist, tell me:

• What is your industry or regulatory requirement (e.g., HIPAA, SOC 2, FinTech, or general SaaS)?
• Do you prefer an IDE-native extension (like Cursor/Copilot) or a terminal-native agent (like Claude Code/Aider)?

I can recommend specific enterprise configurations or help you build a pilot evaluation checklist.

For a 30-developer team, I would treat this as a security architecture decision, not a “which AI writes the best code?” decision. The main question is not “does the vendor train on my code?”—it is:

What data leaves our environment, when, to whom, and under what contractual controls?

A good selection process:

1. Define your acceptable trust boundary first

Classify your repositories:

• Green: open source, prototypes, low-risk services
• Yellow: normal product code
• Red: proprietary algorithms, customer data paths, credentials, regulated code

Then decide your policy:

Be careful with “privacy mode” marketing. A tool that says “we don’t train on your code” may still send source, prompts, embeddings, logs, or metadata through vendor infrastructure. Self-hosting can reduce exposure, but you need to understand whether you are self-hosting the agent runtime, the model, or only the workspace.

2. Ask vendors these exact questions

Put these in your procurement checklist:

Data handling

• Is customer code ever used for training? Is that contractually guaranteed?
• Are prompts, completions, embeddings, and repository indexes stored?
• What is the retention period?
• Can we enable zero-data-retention?
• Are subprocessors involved?

Network behavior

• Does the agent upload:
  • entire repositories?
  • selected files?
  • embeddings?
  • telemetry?
  • crash reports?
• Can we block outbound traffic and still operate?

Access control

• Can admins:
  • restrict approved models?
  • disable certain features?
  • enforce SSO?
  • revoke users?
  • audit usage?

Developer workflow

• Does it need:
  • GitHub write access?
  • cloud credentials?
  • database credentials?
  • SSH access?

A powerful agent with broad credentials is effectively another employee account.

3. Shortlist architectures, not just products

You generally have four patterns:

A. Enterprise SaaS agent (fastest rollout)

Examples include enterprise versions of popular IDE agents and coding assistants.

Pros:

• easiest adoption
• best UX
• vendor maintains infrastructure

Require:

• enterprise contract
• no-training commitment
• retention controls
• admin/audit features

For example, some enterprise offerings provide contractual controls such as zero-data-retention options rather than relying only on default consumer settings.

B. SaaS model + your own execution environment

The agent runs in your VPC/workspace, while the model may still be hosted elsewhere.

Pros:

• source tree and secrets can remain inside your environment
• better isolation

Cons:

• the model still sees context unless using a private inference endpoint

C. Self-hosted agent platform

Pros:

• strongest control
• easier security review
• can integrate with internal networks

Cons:

• your team owns operations

Some enterprise platforms focus specifically on running agent execution inside customer-controlled infrastructure with audit and governance controls.

D. Fully local models

Pros:

• strongest data isolation

Cons:

• hardware cost
• model quality may lag frontier hosted models
• more operational burden

4. Run a 2–4 week security pilot

Do not roll out to all 30 developers immediately.

Pick:

• 5–8 developers
• non-critical repositories
• representative languages

Measure:

Security

• What files does it request?
• What network calls occur?
• What permissions does it need?
• What appears in logs?

Engineering

• PR acceptance rate
• review burden
• bugs introduced
• developer satisfaction
• time-to-merge

5. Put guardrails around the rollout

For a 30-person team, I would implement:

• approved-agent allowlist
• company-managed accounts only
• SSO enforcement
• no personal API keys
• separate policies for sensitive repos
• secret scanning before AI access
• least-privilege Git permissions
• audit logs reviewed periodically

Also create an internal rule:

“AI agents may modify code, but humans remain responsible for review, testing, and merge approval.”

My default recommendation for a 30-dev team

A practical path:

1. Start with an enterprise coding agent that passes security review.
2. Require contractual guarantees around training and retention.
3. Run agents with least privilege.
4. Keep high-value repositories behind stricter controls.
5. Re-evaluate self-hosting if your threat model requires that code never leaves your network.

The biggest mistake is choosing the agent based only on coding benchmarks. For a company rollout, the winning tool is usually the one your security team can approve and your developers will actually use.

For a 30-person engineering org, I’d treat this as a security architecture decision, not an IDE preference.

The key distinction is: “the vendor doesn't train on our code” is necessary but not sufficient. An agent can still expose source through prompts, logs, telemetry, third-party model providers, MCP integrations, cloud execution, or an overly broad network/credential scope.

My shortlist

Those policies are current as of August 2026. OpenAI says business data isn't used for training by default, and Codex has enterprise controls around access, networking and telemetry. openai.com Anthropic similarly says commercial-product inputs/outputs aren't used for training by default. privacy.claude.com GitHub says Copilot Business/Enterprise customer data isn't used for training and documents its provider-specific zero-retention arrangements. docs.github.com Cursor's Privacy Mode provides a comparable commitment and says it has ZDR agreements with its model providers.

The security requirements I'd put in the RFP

1. Contractual no-training guarantee

Require:

• No training/fine-tuning on your prompts, source, diffs, embeddings, tool outputs or agent traces.
• Applies to every downstream model provider, not merely the agent vendor.
• No opt-in hidden behind individual developer settings.
• Organization-wide admin enforcement.
• Written DPA/security terms, not just marketing copy.

2. Retention controls

Ask for the exact retention period for:

• prompts
• source files
• generated code
• embeddings/indexes
• agent transcripts
• tool/MCP calls
• telemetry
• error logs
• abuse/safety-review data
• backups

“Zero retention” needs to be defined precisely. For example, Cursor says plaintext code used for indexing ceases to exist after the request, but metadata such as hashes and filenames may remain.

3. Control the agent's network

This is probably the most overlooked issue.

A coding agent with your repository plus unrestricted internet access can potentially send sensitive material somewhere even if the primary model provider has an excellent privacy policy.

I'd require the agent to run with:

repository access → model endpoint
repository access → explicitly allowlisted services
everything else → denied

OpenAI's description of its own Codex deployment is a good example of this model: explicit network boundaries, domain allowlists/denylists, controlled credentials and auditable telemetry.

4. Treat MCP/tools as privileged access

Don't let 30 developers install arbitrary MCP servers.

An MCP integration can turn:

read source → call external service → transmit source

into a one-click operation.

Require centrally managed/approved MCP servers, with:

• allowlists
• OAuth scopes
• per-tool permissions
• audit logs
• secrets isolation
• ability to disable individual tools

5. Separate “coding assistant” from “autonomous agent” permissions

I'd have three tiers:

• Tier 1: read repo, propose changes
• Tier 2: edit repo + run tests locally
• Tier 3: modify infrastructure, access production systems, merge PRs, deploy

Most developers can have Tier 1/2. Tier 3 should require explicit approval and additional controls.

How I'd run the evaluation

Don't ask vendors to demonstrate on a toy repo.

Give each finalist a sanitized but representative repository containing:

• proprietary-looking architecture
• fake credentials
• sensitive-looking comments
• internal package names
• large dependency graph
• multiple services
• deliberately planted “do not expose this” files

Then instrument the environment and test:

1. What leaves the laptop?
2. Which domains receive it?
3. Which third parties receive it?
4. What gets cached?
5. What gets persisted?
6. Can the agent read files outside the repo?
7. Can it access $HOME, SSH keys, cloud credentials, environment variables?
8. Can an MCP/plugin exfiltrate data?
9. Can it make arbitrary outbound HTTP requests?
10. Can admins reconstruct what happened afterward?

I'd also deliberately put a fake secret in the repository and ask the agent to solve tasks that tempt it to expose that file.

One important gotcha

Don't evaluate “does the vendor train on my code?” in isolation.

For example, Anthropic's commercial policy says no training by default, but Anthropic also documents circumstances involving feedback and safety review. privacy.claude.com Likewise, GitHub's provider arrangements differ depending on model/provider and feature; its documentation explicitly notes exceptions for some beta/preview Anthropic functionality.

That's why I'd make the security team evaluate the actual data flow of the exact agent configuration you're buying, not just the vendor's headline privacy statement.

What I'd choose

If I were responsible for your 30 developers, I'd run a 2–3 week bake-off between Codex, Claude Code and Cursor Enterprise, with Copilot Enterprise as the fourth candidate if you're deeply invested in GitHub.

My initial preference would be:

Codex or Claude Code for teams wanting a powerful terminal/agent workflow, Cursor Enterprise if developer UX is the overriding factor, and Copilot Enterprise if centralized GitHub governance is worth more than having the most aggressive agent experience.

But I would make network isolation + retention + MCP governance + admin enforcement hard gates. A tool that is 10% better at coding but can't give you those controls shouldn't make the shortlist.

For a 30-dev team, you can get surprisingly far with a simple rule: the agent gets the minimum filesystem, credential, network and repository permissions necessary to do its job—and nothing else.

Rolling out AI coding agents to a 30-developer team requires strict guardrails to protect your intellectual property. When evaluating tools, you need to look past the marketing and audit how the vendor handles your data, retention, and model training policies.

• Zero Data Retention (ZDR) : Ensure the vendor explicitly guarantees that your code, prompts, and context snippets are never stored persistently on their servers or logged beyond the immediate processing window.
• No Model Training on Your Code : Verify that your proprietary codebases are not used to train public or foundational models. Look for enterprise tiers with contractual opt-outs or guarantees that data isolation is enforced at the tenant level.
• SOC 2 Type II and ISO 27001 Compliance : Demand independent, third-party security audits. A vendor must prove they have robust operational security, encryption in transit (TLS 1.3) and at rest (AES-256), and strict access controls.
• Deployment Flexibility (Self-Hosted vs. Cloud) : Assess whether you need a SaaS solution with strong enterprise privacy guarantees or an air-gapped / self-hosted model runner (running open-weights models locally or within your private VPC) where data never leaves your infrastructure.
• Granular Access and Audit Logging : Check for enterprise administration controls, including single sign-on (SSO/SAML), role-based access control (RBAC), and comprehensive audit logs showing who queried the agent and what repositories were accessed.
• IP Indemnification : Look for vendors that offer intellectual property indemnification, protecting your company if copyright or licensing issues arise from generated code.

If you'd like, let me know:

• Are you looking for cloud-hosted enterprise tools (like GitHub Copilot Enterprise or Cursor) or self-hosted/VPC options?
• What is your primary compliance requirement (SOC 2, HIPAA, GDPR)?

I can tailor a shortlisting framework or specific vendor checklist for your team.