The pattern we see over and over
An engineering VP decides it is time. Claude Code, Cursor, or Copilot goes out to the team. Productivity jumps. Developers post demos in Slack. Everyone is happy.
Three weeks later, a security engineer notices a prompt log with a customer record in it. Or legal finds out that code from a regulated repo was sent to an LLM provider that is not covered under the DPA. Or an auditor asks who has access to what, and nobody can answer cleanly.
The rollout gets paused. The team goes back to old habits. The momentum is lost.
This is not hypothetical. In the past year, there have been publicly disclosed chains of vulnerabilities in AI coding tools that enabled silent data exfiltration, and critical CVEs against Claude Code itself. The attack surface is real, and security teams are rightly paying attention.
This is avoidable. The teams that do it right set up five things before they expand beyond the pilot. This is that list.
1. Define what the AI is allowed to see
The single biggest source of incidents is ambient context leakage. An engineer opens their IDE. The AI has access to the whole workspace. The workspace contains a repo with PHI fixtures, or a .env with production secrets, or a SQL dump that should never have been on disk.
Before the rollout expands, answer three questions:
- Which repos contain data the AI should never see. Mark them. Most modern AI tools support per-repo exclusions or workspace-level blocklists.
- Which files on developer machines contain secrets. Move them out of the workspace. If they must stay, exclude them explicitly.
- Which environments does the AI have network access to. Local only, or can it call production APIs. Most should be local only.
The goal is that the AI sees code, not data. Code is safe to reason about. Data is not.
2. Pick the deployment mode that matches your compliance posture
"Claude Code" is not one thing. Depending on deployment mode, the data boundary is in a different place. Know which you are using.
Direct API, standard tenancy. Prompts and code snippets go to Anthropic's servers. Covered by a standard DPA. Data is not used for training. Good for most teams working on non-sensitive code.
Via AWS Bedrock. The LLM call happens inside your AWS account. Data stays within AWS's boundary and can be kept inside your VPC with Bedrock private endpoints. The right answer for HIPAA, FedRAMP, and most regulated workloads.
Via Google Vertex AI. Same idea for GCP-native shops. Supports GCP VPC service controls for network-level isolation.
Via Azure OpenAI or Azure AI Foundry. For shops already aligned with Microsoft's compliance frameworks.
Pick once, document it, and make sure every rollout group is on the same deployment mode. Mixed deployments are where data boundary assumptions break down.
3. Stand up access controls that mean something
Most teams start with "everyone gets a license." That is fine for a pilot. It is not fine for 200 engineers.
The access controls that actually matter:
- Group by data sensitivity, not by team. Engineers working on customer-facing features have different exposure than engineers working on internal tooling. Structure access and logging accordingly.
- Separate models for separate workloads. A model instance dedicated to your regulated workloads should not be shared with your marketing team's experiments. Bedrock and Vertex both support this.
- Off-ramp procedures. When an engineer leaves, their AI access revokes the same way their GitHub and AWS access revoke. Wire it into your identity provider from the start.
None of this is hard. It just has to happen before the rollout, not after.
4. Log enough to answer the audit question
The audit question: "show me every prompt that touched data classified as PHI, for the last 90 days."
If you cannot answer this in under an hour, your logging is not good enough.
Logging the right things:
- Prompt content, with redaction for known sensitive patterns.
- Response content, at least in summary form.
- User identity, tied to your SSO.
- Timestamp and session identifier.
- The repo or workspace the request came from.
- The model version served.
Store this in the same log infrastructure you use for everything else. Not in a separate system only the AI team sees. Your SIEM should be able to query it. Your incident response runbook should reference it.
Most AI coding tools expose this data through enterprise APIs. For Claude Code specifically, the Anthropic Compliance API gives programmatic, real-time access to usage data including who ran what query and what code was generated. Feed it into your existing SIEM. The integration is straightforward and it closes the audit gap that otherwise never gets closed.
5. Write the policy before you need it
A short document. Two pages is enough.
- What the tool is approved for.
- What data classes are allowed in prompts.
- What data classes are not.
- What to do if you think a sensitive prompt leaked.
- Who to contact with questions.
Distribute it on day one of the rollout. Reference it in onboarding. Make sure engineering managers can answer questions about it.
The policy exists so that when something does go wrong, the conversation with security is "here is what happened, here is the response we pre-committed to" rather than "we did not think about this."
The rollout sequence that actually works
Based on what has worked for teams we have helped:
Weeks one and two. Pilot with 10 to 20 engineers. Mixed seniority. Deployment mode selected and validated. Logging wired up. Policy drafted.
Weeks three and four. Review pilot data. Check logs. Catch anything surprising. Lock down access controls. Finalize policy.
Weeks five through eight. Expand to the full engineering org. Structured training. Office hours. Clear channel for questions.
Week nine onward. Measure what matters. PR velocity, review throughput, reported issues. Iterate on the policy as real patterns emerge.
The total timeline is about two months for most mid-sized engineering teams. Shorter for teams with existing SSO and logging infrastructure. Longer for regulated orgs that need a formal risk review.
What this is not
This post is not a pitch for paranoia. Claude Code and the other modern AI coding tools are net positive for most engineering teams. The productivity gains are real and they are large.
But the pattern of "roll out, pause after an incident, lose momentum" is avoidable. The teams that move fastest are the ones that do the five things above before they expand. They ship with confidence because they already answered the questions security would eventually ask.
If you are planning a rollout and want a second pair of eyes on the setup, that is the kind of work we do. Two weeks, documented deliverables, a rollout your security team signs off on.
Kai Token leads AI adoption work at Fraktional. Works on secure rollouts of AI coding tools for engineering teams. Thinks the best rollout is the one your security team would have signed off on before you started.
