Is Claude Code safe for company code? Data handling and the real risks

the short answer

On a commercial plan (Team, Enterprise or API), Anthropic does not train on Claude Code prompts or code, and retains them for 30 days, with zero data retention available to qualified Enterprise organizations. The larger risk is local: the agent acts with every credential the developer has loaded, so a loose instruction can delete infrastructure or read secrets. Make it safe with a company plan, managed settings, and a policy check before each action.

Training: Not on commercial plans; consumer Free, Pro and Max users choose
Retention: 30 days on commercial plans; ZDR for qualified Enterprise organizations
Local copies: Transcripts in plaintext under ~/.claude/projects/ for 30 days
Primary risk: Wrong action with valid credentials, not a stolen credential
Highest-risk users: Infra admins and on-call engineers with long-lived elevated access
Framework: OWASP LLM06:2025 Excessive Agency

What Happens to Your Code

The practical rules: make sure people use the company plan, not personal accounts (pin the login with forceLoginMethod and forceLoginOrgUUID in managed settings; see personal AI accounts), and remember the plaintext transcripts on each laptop contain whatever the agent read, including secrets it should not have.

Question	Commercial (Team, Enterprise, API)	Consumer (Free, Pro, Max)
Used to train models?	No, unless the org opts in to the Development Partner Program	Only if the user allows it in privacy settings
Server-side retention	30 days; zero data retention available to qualified Enterprise organizations, enabled per organization	30 days, or 5 years if training is allowed
Local copies	Session transcripts in plaintext under `~/.claude/projects/` for 30 days (`cleanupPeriodDays`)	Same
Via Bedrock or Vertex	Requests go to your cloud provider under its terms	Not applicable

The Incident Pattern We Keep Hearing

An anonymized incident described to us by a platform team: a developer gave an agent a loosely worded cleanup instruction. The agent removed DNS records from non-production Route 53 hosted zones. The team found it in CloudTrail and traced it back to the developer’s SSO session. It was recoverable because it was a test environment. The same SSO session could also reach production; had the agent touched production zones, it would have been an outage.

Nothing in that chain was a security failure in the traditional sense. The credentials were legitimate, the developer was authorized, the agent did what it understood it was asked to do. Every existing control saw an authorized user doing an authorized thing. The Route 53 walkthrough reconstructs the incident and the policy that would have stopped it.

What a Local Agent Can Reach

Asset on the laptop	What an agent can do with it	Typical worst case
AWS SSO session or named profile	Any AWS API the role allows, through the CLI, Terraform or an SDK script	Deleted DNS records, security groups, databases, buckets
kubeconfig contexts	`kubectl delete`, `helm uninstall`, scaling to zero	Production workload removed
Terraform state and backends	`terraform destroy`, `apply -auto-approve`, state edits	Infrastructure torn down
Git credentials	Force-push, push to `main`, rewrite history	Lost commits, bypassed review
`.env` files and shell environment	Read secrets into the model context, print them, send them out	Credential exposure in transcripts or third-party tools
Database URLs	`DROP`, `TRUNCATE`, unbounded `DELETE`	Data loss
Package registries	Publish packages, change global installs	Supply-chain incident

What Makes the Blast Radius Larger

Concentrated admin rights. In many orgs a few infrastructure admins hold broad permission sets. An agent running in their terminal inherits all of it.
Long-lived on-call access. On-call permission sets are often elevated and stay assumed for hours; IAM Identity Center sessions can last up to 12 hours. See on-call guardrails.
No agent identity in audit logs. CloudTrail records the role session. Without agent telemetry you cannot tell which calls a human typed and which an agent generated.
Many harnesses. Developers mix Claude Code, Codex, Cursor and Copilot. A rule configured in one tool does not exist in another.
Indirection. An agent blocked from aws route53 ... can write a Python script that calls boto3, or a shell script that wraps the same command. See how agents get around deny rules.

Mapping Each Risk to a Control

The tamper-resistance page covers the last two rows in depth, because a control the agent can switch off is not a control.

Risk	Primary control	Backstop
Destructive infra change	Pre-tool `deny` on destroy, delete and production mutations, with a reason that redirects to the reviewed workflow	IAM: agents use a scoped, non-admin profile
Ambiguous change (over-provisioning, wrong region)	`instruct`: the call continues with guidance the agent reads	Cost and drift alerts
Indirect execution via scripts and SDKs	Deny destructive content in script writes; a decision model over the tool call itself	Least-privilege credentials
Secrets entering context	`block-env-files`, `protect-env-vars` (on by default), output sanitizers	Short-lived credentials, secret scanning
Agent disabling its own guardrails	Always-on `block-failproofai-commands`; fail closed when the daemon is unreachable	Separate OS user for the daemon and no sudo for agents (managed deployments)
No attribution	Session traces linked to policy decisions, per machine	CloudTrail correlation by time and role session

How This Maps to OWASP

OWASP’s Top 10 for LLM Applications names this risk Excessive Agency (LLM06:2025): an LLM-based system given more functionality, permissions or autonomy than the task needs. Its mitigations are the same three moves: minimize the tools and permissions an agent has, require human approval for high-impact actions, and enforce authorization in the downstream system rather than trusting the model. A coding agent on a laptop has unusually broad functionality by default, a full shell, which is why the policy layer has to sit at the tool boundary.

Run This Exercise with Your Own Team

Run failproofai audit on a few volunteers’ laptops. It scans existing Claude Code, Codex, Copilot CLI, Cursor and other agent histories offline and shows which risky patterns already happened.
List the five people with the broadest cloud permissions. For each, list what their default shell profile can delete.
Pick the three most destructive commands for your stack (for example terraform destroy, route53 change-resource-record-sets, kubectl delete in prod) and write a deny policy for each.
Publish them and deploy in observe mode to a pilot group; read a week of decisions under Observe → policy before enforcing.

FAQ

Is prompt injection the main risk?

It is one risk, but most reported damage comes from ordinary instructions interpreted too broadly. Prompt injection raises the odds of a harmful action; the controls at the tool boundary are the same either way.

Can CloudTrail tell me an agent made a call?

Not by itself. CloudTrail records the IAM principal and role session. Correlating with agent session traces by time, machine and command is how you attribute a call to an agent.

Should agents use separate credentials?

Where you can, yes: a non-admin profile for agent work is the cleanest backstop. Developers share one shell, so a policy enforces which profile an agent may use. See force a scoped AWS profile.

Sources

Checked against the sources below on October 21, 2026. Harness settings, hook capabilities and cloud features change between versions.