The risks of using Claude Code with company source code fall into three groups: your code and prompts leave the developer’s machine for a cloud model, where retention and training depend on the account; the agent reads files, runs shell commands, uses Git, and connects to Model Context Protocol (MCP) servers with the developer’s own permissions, so a wrong command or a prompt injection can reach secrets or take action; and without enterprise controls, security teams cannot prove what code went where.

The cloud-retention question gets all the attention, but it is the least dangerous of the three. The execution layer is where source code actually walks out the door: approval prompts get clicked past, MCP connections carry credentials beyond the repository, and a developer signed into a personal account routes proprietary code outside enterprise terms. Closing those gaps takes controls placed in the interaction layer, not at the network perimeter where a coding agent never appears.

Last updated: June 2026.

What Claude Code Can Reach With Developer-Level Permissions

Claude Code runs as an autonomous agent in the developer’s terminal or editor with the same permissions as the person who launched it, which means everything that developer can touch is in scope. By default it starts read only and asks before it acts, requesting approval to change anything, with lasting allow and deny rules set in a settings file (Anthropic, 2026).

Inside an approved session, Claude Code can:

• Read files across the repository and, unless denied, other paths on the machine.
• Edit and create files, including configuration and build scripts.
• Run shell commands, which can install packages, run tests, or touch the wider system.
• Use Git to stage, commit, and push changes.
• Fetch URLs and connect to MCP servers and the tools behind them.

That access is what makes the tool useful and what makes it a security surface. The question for a security team is not whether Claude Code is powerful. It is which of these actions touch company source code, credentials, and systems, and who decides the boundaries. Securing AI coding assistants starts with answering exactly that.

Why developer-level permissions are the real scope. A coding agent does not get a narrowed-down service account. It inherits the human’s full reach: the repository, the local secrets, the SSH keys, the cloud credentials cached on the machine, and any tool the developer can already call. Every control decision downstream flows from accepting that the agent operates at developer privilege, not at some sandboxed subset of it.

How Account Type Decides Whether Source Code Is Protected or Trained On

The single account a developer signs in with can decide whether your source code is protected or kept for model training. Claude Code is cloud inference, so repository context and prompts leave the device for a model, and what happens next depends on the account and route, not on the tool.

Under commercial terms, which cover Team and Enterprise plans, the Claude API, and cloud platforms such as Amazon Bedrock and Google Vertex AI, Anthropic does not train its models on the code or prompts sent to Claude Code, standard retention is 30 days, and zero data retention (ZDR) is available per organization on Claude for Enterprise (Anthropic, 2026). On personal Free, Pro, or Max accounts the posture is different: code can be used to train models when the training setting is on, which since the August 2025 consumer terms is the default for paid consumer plans unless a developer opts out, with a longer retention window.

There is also a local copy. Claude Code stores session transcripts in plaintext under a folder in the developer’s home directory for 30 days by default, so proprietary code and prompts sit unencrypted on the endpoint until that window clears. Source code is among an enterprise’s most valuable intellectual property, and whether it stays protected turns on a choice made at sign in. That is not a decision to leave to each developer, which is the same problem AI usage control exists to solve.

Account type, defined. A sanctioned enterprise account operates under commercial terms with no training, bounded retention, and an organization-level ZDR option. A personal account (Free, Pro, or Max) carries consumer terms where code can feed model training by default and retention runs longer. The same developer, the same repository, two different data-governance outcomes decided entirely by which credential they signed in with.

Approval Fatigue and Auto-Mode Collapse the Permission Boundary

The permission boundary fails in practice not because the controls are missing but because humans stop reading them. Claude Code asks before it acts, but a developer running dozens of approvals an hour starts clicking through, and once permissive allow rules or auto-accept modes are enabled, the approval gate stops gating anything.

This is the risk OWASP names Excessive Agency (LLM06): an agent taking actions beyond what the task required, amplified when the human checkpoint is bypassed (OWASP, 2025). Approval fatigue is the human side of the same failure. A prompt that fires on every shell command trains the developer to approve reflexively, and a single rubber-stamped command can install a package, exfiltrate a file, or push to a remote. Standing allow rules written to cut the noise quietly widen the boundary, because every rule added to reduce prompts removes a decision point a human used to make.

Auto-mode features make this concrete. When a developer enables an auto-accept or “YOLO” mode to keep momentum, the agent runs commands without per-action review, and any instruction it picked up, including one hidden in a file it read, executes unchecked. The governance lesson is direct: an approval model that depends on a tired human reading every prompt is not a boundary. Enforcement has to sit in the execution path, where a policy decides what runs regardless of whether the developer is paying attention.

Prompt Injection, MCP Tool Chains, and the Path From a File Read to a Credential Leak

The sharper source-code risk is not the model memorizing your code. It is untrusted content steering the agent, and connected tools turning a single file read into a credential leak. Claude Code reads files, dependencies, issue trackers, and web pages, and an instruction hidden in any of them can attempt to make the agent read secrets, run shell commands, or push code.

OWASP ranks prompt injection first in its Top 10 for Large Language Model Applications as LLM01, alongside Sensitive Information Disclosure (LLM02) and Excessive Agency (LLM06) (OWASP, 2025). Indirect prompt injection, where the malicious instruction rides inside third-party content the agent ingests, is the variant most frequently cited in real-world coding-assistant exploit disclosures. For the mechanics of the attack class, see what is prompt injection.

MCP is where one prompt stops being contained to the repository. The protocol lets the agent call external tools, hit internal APIs, and retrieve data, so an instruction that reaches a connected tool inherits that tool’s reach. The surface is large and largely unguarded: Censys counted more than 12,520 internet-accessible MCP services in early 2026, and the protocol does not require authentication by default (Censys, 2026). At the same time, only 21% of organizations maintain a real-time inventory of the AI agents already running in their environment, leaving most of the agent and tool surface unmonitored (Cloud Security Alliance, 2026).

How secrets exposure compounds through connected tools. A coding agent with a database MCP server, a cloud-API tool, and repository access does not hold three separate risks. It holds one chained path: a hidden instruction in a dependency file can prompt the agent to read an environment variable, pass that credential to a connected tool, and route the result to an external endpoint, all inside one approved session. Each tool added to the agent multiplies the reach of every instruction it ingests. Anthropic built sandboxing into Claude Code partly to contain this, and with filesystem and network isolation enabled a successful injection is boxed in, as Anthropic’s engineering team describes. The limits matter as much as the feature: sandboxing is off until a developer turns it on, the file read and edit tools operate outside it, and it is not a full isolation boundary. Governing the path the credential travels, the tool-execution channel, is what limits how far a single instruction goes. That is the runtime model behind agentic AI security architecture.

Insecure Code and Vulnerable Dependencies the Governance Layer Has to Catch

A coding agent does not only leak code, it produces code, and the code it writes can introduce vulnerabilities or pull in dependencies your governance layer never reviewed. An agent that accepts a suggested package, scaffolds a build script, or wires up an integration can add an outdated, malicious, or unvetted dependency that ships straight into the repository.

This is the downstream risk that account governance and prompt-injection defense do not cover. The agent writing insecure code is not an attack and not a leak; it is ordinary output that happens to carry a flaw. A developer working through approvals at speed, with auto-mode reducing the review, can commit a suggested dependency without the scrutiny a human-authored change would draw. The vulnerability bypasses the AI control layer entirely, because nothing about the interaction looks risky.

The governance response is to treat agent-generated changes as untrusted input to the software development lifecycle, not as pre-vetted work. That means the same dependency scanning, security review, and human checkpoints a change from any contributor would face, applied to what the agent produces. Aurascape’s control sits at the interaction layer and governs what the agent sends and what tools it calls; the SDLC controls below govern what it writes. Both are required, because a sanctioned account writing a vulnerable dependency is still a sanctioned account.

Security Review Workflows Keep Human Oversight in the SDLC

Inline interaction controls govern what an agent can reach and send; security review workflows govern what its output is allowed to become. Making the safe path the default is not only about routing and permissions, it is about keeping a human checkpoint at the points where agent output enters the codebase.

A workable oversight process puts named checkpoints around agent work. Code the agent writes goes through the same pull-request review, dependency scanning, and secrets detection that any contributor’s change would. High-impact actions, pushing to a protected branch, touching infrastructure, or modifying authentication, stay behind explicit human approval rather than a standing allow rule. The review is structured so the reviewer sees that the change came from an agent, because a change a tired developer auto-approved deserves more scrutiny, not less.

The point is to fold the agent into the existing software development lifecycle rather than letting it run beside it. Audit-ready, conversation-level records of what the agent did make this enforceable: a reviewer, or a later examiner, can see what code and which tool calls the agent touched and tie them back to a decision. Without that record, oversight is a policy on paper; with it, the human checkpoint becomes evidence.

Why SSE, CASB, and DLP Tools Cannot See a Coding Agent’s Interaction Path

The web and SaaS era controls most enterprises already run cannot see a coding agent at all, because a command-line agent does not look like a website. The security service edge (SSE), cloud access security broker (CASB), data loss prevention (DLP), and secure web gateway (SWG) tools in the stack were built to govern destinations and browser sessions, and a coding agent runs over command-line and thick-client paths and calls tools directly.

This is why ungoverned adoption stays invisible rather than a failure of any one team. Most source-code exposure through coding assistants is not an attack: a developer reaches for a personal account on a deadline, or wires up a new MCP server without telling anyone. The same pattern drives AI data leakage across the rest of the business, and the cost is measurable. Breaches involving shadow AI added about $670,000 to the average breach (IBM Cost of a Data Breach Report, 2025), and AI now runs in 88% of organizations (McKinsey State of AI, 2025). The table maps where each layer acts.

Aurascape works alongside an existing SSE, CASB, DLP, or SWG stack rather than replacing it. The contrast is not that those tools do nothing for AI. It is that they were built for web and SaaS traffic, while a coding agent runs over command-line and thick-client paths and calls tools directly (Aurascape, 2026).

Governing Claude Code at the Interaction Layer: an Enterprise Control Checklist

The goal is not to ban Claude Code. Used on the right account with the right controls, it speeds delivery, and the security job is to make the safe path the default. In one Aurascape deployment, governing AI coding assistants and agent integrations inline helped a Fortune 100 insurance and financial enterprise deliver code 40 percent faster and triple its AI agent integrations with no unauthorized data access, while protecting more than 20,000 users (Aurascape, 2026).

A practical evaluation works through the same questions in order:

1. Decide the route and account. Require enterprise terms or a cloud platform such as Bedrock or Vertex, and keep company source code off personal free-tier accounts.
2. Scope permissions. Set allow and deny rules so the agent cannot read secrets files, keys, or credentials, and cannot run destructive or network commands without review.
3. Turn on sandboxing and fail closed. Enable filesystem and network isolation, and configure it to error rather than silently fall back to an unsandboxed run.
4. Constrain MCP. Approve which MCP servers and tools the agent may connect to, rather than letting each developer add their own.
5. Govern the tool-execution path inline. Verify and sign approved tool calls and block unsigned ones, so execution cannot route around the control.
6. Keep humans in the SDLC. Route agent-written code through pull-request review, dependency scanning, and secrets detection, and hold high-impact actions behind explicit approval.
7. Capture decoded, conversation-level interaction records for audit and effectiveness, governed by role-based access control (RBAC) for privacy.

The control table below ties each source-code risk to where it occurs and the control that addresses it.

Source-Code Control Lives in the Execution Path, Not the Perimeter

Cloud retention is the question every Claude Code review opens with, and it is the one that matters least. The source code that actually leaves an enterprise walks out through the execution layer: an approval prompt clicked past on a deadline, an MCP connection carrying a credential past the repository, a personal account routing proprietary code outside commercial terms. None of those events looks like a website, which is why the perimeter tools built for websites never see them.

Governing Claude Code means governing the interaction itself: the account it runs under, the prompts and responses crossing the intelligence channel, and every tool call crossing the tool-execution channel. Control placed there decides what runs regardless of whether a developer read the prompt. The risk from a coding agent was never that the model remembers your code. It is that nothing watches what the agent does with developer permissions, and that gap closes only in the interaction layer.

How Aurascape Governs Claude Code at the Interaction Layer

Aurascape closes the execution-layer gap this article describes by applying control as an interaction layer across the network, endpoint, and API planes, including the command-line and non-browser agent paths a coding assistant uses. It decodes prompts, responses, and tool calls with conversation-level context, distinguishes a personal account from a sanctioned enterprise one through entitlement and Intentions, and coaches developers toward approved tools while applying context-aware actions to allow, coach, warn, block, or redact (Aurascape, 2026).

For the agent side, the Zero-Bypass MCP Gateway secures the tool-execution channel by verifying and signing approved tool calls and blocking unsigned ones, with cross-call data lineage across chained actions, while the AI Proxy secures the intelligence channel by inspecting each model interaction for data leakage and prompt injection in real time. Because new coding assistants launch constantly, Aurascape catalogs brand-new tools as they appear and finds the assistants already running across endpoints, so a tool is governed before the first developer adopts it. A sanctioned Claude Code deployment is governed through the same entitlement and intention controls, not only blocked when it is unapproved.

This is the same model that helped a Fortune 100 insurance and financial enterprise turn AI security into an adoption accelerant: 60 percent faster adoption of new AI tools, code delivered 40 percent faster, and tripled agent integrations with no unauthorized data access across more than 20,000 users (Aurascape, 2026).

How Aurascape Compares to the Tools Governing Coding Agents

Securing a coding agent splits into two problems most tools address from only one side: governing how employees use AI, and securing the agents and MCP connections developers build with. The options below cluster around where each one places its control and how much of the command-line and tool-execution path it actually sees.

Aurascape sits in row one because it governs both the AI employees use and the agents developers build on a single platform, with coverage of the command-line and thick-client paths a coding agent runs over. The other entries are real, named options; each addresses part of the coding-agent problem, and the differentiating cell shows where each places its control.

Frequently Asked Questions

Does Claude Code retain company source code?

It depends on the account the developer signs in with. Under commercial terms covering Team and Enterprise plans, the Claude API, and cloud platforms such as Bedrock and Vertex, Anthropic does not train on your code and retains it for 30 days by default, with zero data retention available per organization on Claude for Enterprise. Personal Free, Pro, and Max accounts can have code used for model training and held longer, and Claude Code also keeps local session transcripts in plaintext on the machine for 30 days by default.

Why is approval fatigue a source-code risk and not just an annoyance?

Because every approval a developer clicks through reflexively is a permission boundary that stopped functioning. A prompt firing on every shell command trains the developer to approve without reading, and standing allow rules added to cut the noise quietly widen what the agent can do without review, which is why enforcement has to sit in the execution path rather than the human checkpoint.

How does an MCP connection turn a file read into a credential leak?

A connected tool inherits the agent’s reach, so one ingested instruction can chain across the tools the agent can call. A hidden instruction in a dependency file can prompt the agent to read an environment variable, pass that credential to a connected tool, and route the result outward, all in one approved session, which is why governing the tool-execution channel matters more than inspecting the prompt alone.

Can Claude Code introduce vulnerable dependencies into our codebase?

Yes, and this risk bypasses account and prompt-injection controls entirely. An agent that scaffolds a build script or accepts a suggested package can pull in an outdated or unvetted dependency that ships into the repository, so agent-written changes need the same dependency scanning, security review, and human checkpoints any contributor’s change would face.

Why can’t our existing SSE, CASB, or DLP tools govern Claude Code?

Those tools were built to govern web destinations and browser and SaaS sessions, and a command-line coding agent does not look like a website. It runs over command-line and thick-client paths and calls tools directly, so the traffic never appears where a destination-based control can act on it, which is why governing a coding agent requires controls placed in the interaction path.

What evidence do security teams get from Claude Code natively?

Native evidence is local and per developer: session transcripts on each machine, enterprise managed settings and telemetry metrics, and provider logs such as AWS CloudTrail on Bedrock or Vertex. Organization-wide, decoded, conversation-level records that show what code and which tool calls left the environment require a control layer in the interaction path, kept for audit and governed by role-based access control for privacy.

Is Claude Code safe to use with proprietary code?

It can be, with the right setup. Route it through enterprise terms or a cloud platform rather than a personal account, restrict permissions and secrets, enable sandboxing, approve which MCP servers it can reach, keep agent output in the SDLC review process, and add an inline control layer that sees the command-line and agent traffic. The account and the controls decide the risk, not the tool by itself.

---

Aurascape is the interaction-layer control that closes the execution-layer gap a coding agent opens, governing the account, the conversation, and every tool call in the live path rather than after the fact. A short demo shows where source code is leaving today and the controls that keep it protected as AI coding adoption grows.

See how Aurascape governs AI coding assistants →