> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/by-ai-vendor/anthropic/claude-code.md).

# Claude Code

Security guidance for Claude Code, including identity, MCP servers, hooks, filesystem access, sandboxing, approvals, telemetry, and incident response.

{% hint style="warning" %}
**In short:** Claude Code is Anthropic's coding agent across the terminal, IDEs, Claude Desktop, hosted web sessions, mobile or browser remote control, and automated workflows. The product name is the same across these surfaces, but the code, credentials, network traffic, and approval path may live on a developer endpoint, a remote host, Anthropic infrastructure, or a CI runner.
{% endhint %}

## What is Claude Code?

Claude Code can inspect repositories, edit files, run commands and tests, use Git, operate development tools, and call connectors or MCP servers. It uses the same underlying agent engine across several clients.

The Claude Agent SDK exposes the agent loop for applications and automated services. This handbook covers the SDK under **Anthropic API & Agent Platform** because the application owner chooses the runtime, identity, credentials, and surrounding controls.

## Surfaces and their security considerations

| Surface                                       | Where work runs                                                                                                                             | Main security considerations                                                                                                                                                                                                                                                                                                                                                      |
| --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Terminal CLI**                              | On the user's workstation, a development server, or another shell host.                                                                     | The session inherits the operating-system user's files, environment variables, credentials, network reach, and installed tools. Enforce workspace trust, sandboxing, permission rules, managed settings, secret-path denies, and narrow network access.                                                                                                                           |
| **VS Code and JetBrains**                     | Usually on the local or remote IDE host.                                                                                                    | IDE trust, extension deployment, unsaved editor context, integrated terminals, remote-development credentials, and repository settings become part of the boundary. Apply the same managed Claude Code policy used for the CLI and control which IDE extensions may run.                                                                                                          |
| **Claude Desktop Code section**               | Local machine, an SSH host, or an Anthropic-hosted cloud environment selected per session.                                                  | Do not treat Desktop as one runtime. Local sessions inherit endpoint authority. SSH sessions inherit the remote account. Cloud sessions use separate repository and environment controls. Review worktrees, preview browser, Computer Use, connectors, scheduled tasks, and bypass-mode settings.                                                                                 |
| **Claude Code on the web**                    | An isolated Anthropic-managed cloud virtual machine.                                                                                        | Scope the GitHub App or synced GitHub credential to required repositories. Configure environment network access as None, Trusted, or a narrow Custom list instead of Full. Treat setup scripts and environment variables as privileged configuration. Sessions can continue after the user disconnects. Organizations with Zero Data Retention cannot use cloud-session features. |
| **Mobile and Remote Control**                 | Cloud sessions run at Anthropic. Remote Control is only a client into a CLI or VS Code session that continues to run on the user's machine. | Protect the mobile account and device, require admin enablement, and review pairings. Remote Control does not move execution into a safer mobile sandbox; it exposes the local session's filesystem, tools, MCP servers, and approvals through another device.                                                                                                                    |
| **Slack, GitHub, scheduled tasks, and CI/CD** | Anthropic cloud, a repository workflow runner, or another configured automation host.                                                       | Use service identities, least-privilege repository grants, isolated runners, constrained network access, spend controls, and human review. Unattended jobs should not use broad bypass modes or production credentials.                                                                                                                                                           |

## Core security model

Claude Code uses permissions and sandboxing together:

* **Permission rules** decide whether a tool action is allowed, denied, or requires confirmation.
* **Sandboxing** limits what an allowed process can read, write, or reach.
* **Managed settings** can impose organization requirements over user and project configuration.
* **Workspace trust** marks whether Claude Code should load project configuration from a repository.
* **Repository content** can influence the agent through instructions, hooks, plugins, MCP configuration, build scripts, tests, and tool output.

An approval prompt is not proof that a command is safe. Review the command, working directory, affected paths, network destination, and credentials the process can inherit.

## How to configure Claude Code securely

### Identity and access

* Prefer managed Team or Enterprise sign-in for interactive use.
* Use **forceLoginMethod**, organization controls, and managed settings to prevent unapproved authentication paths where supported.
* Scope access through organization roles and groups.
* Use separate service identities for CI, scheduled work, code review, and other automation.
* Do not reuse an interactive developer token as a production automation credential.
* Recertify GitHub, GitLab, cloud-provider, connector, and MCP access independently.

### Local CLI and IDE sessions

* Deploy server-managed or device-managed settings so project and user files cannot weaken required controls.
* Keep sandboxing enabled and restrict writes to approved repository roots.
* Deny reads from credential stores, SSH material, environment files, production configuration, browser profiles, and unrelated home directories.
* Use explicit allow, ask, and deny rules for shell commands, files, network actions, plugins, and MCP tools.
* Keep outbound network access off or behind a corporate proxy unless the task needs it.
* Open unfamiliar repositories in a disposable environment. Review **CLAUDE.md**, settings, hooks, plugins, MCP configuration, and build scripts before granting trust.
* On Windows, avoid WebDAV paths and broad UNC patterns that may cause network requests outside the expected permission boundary.
* For remote IDE sessions, apply the policy to the remote extension host as well as the local editor.

### Desktop Code sessions

* Use the Desktop admin controls for **Code in Desktop**, **Code on the web**, **Remote Control**, and **Disable Bypass permissions mode**.
* Apply Claude Code managed settings to local and SSH sessions launched by Desktop.
* Test the deployed client because remotely uploaded settings may cover CLI and IDE paths before every Desktop path.
* Restrict which SSH destinations and remote accounts users may select.
* Treat the preview browser as an authenticated browser surface when cookies or local storage persist.
* Keep Computer Use off unless needed. It acts on the actual desktop, outside the Bash sandbox.
* Use isolated worktrees for parallel sessions and still require diff review before merge.
* Give scheduled tasks narrower permissions and credentials than attended sessions.

### Web and cloud sessions

* Grant the Anthropic GitHub App access only to approved repositories. Review whether **/web-setup** copies a local GitHub CLI credential into the account configuration.
* Create separate cloud environments for different trust levels and repository groups.
* Prefer **None** or **Custom** network access. Use **Trusted** only when its documented default domains are acceptable, and avoid **Full** for routine work.
* Keep secrets out of ordinary environment variables when they would be visible to environment editors. Use supported secret handling where available and limit who can edit the environment.
* Review setup scripts as production code. Pin dependencies and avoid downloading unverified installers.
* Remember that Git operations use a dedicated proxy and outbound web traffic uses a security proxy; validate audit coverage rather than assuming it matches endpoint logs.
* Do not use cloud sessions where the organization's Zero Data Retention requirement makes them ineligible.

### Remote Control and mobile

* Keep Remote Control disabled unless remote steering is an approved use case. Team and Enterprise organizations should require the admin toggle.
* Require managed devices, strong account authentication, screen lock, and timely lost-device revocation.
* Use short session names that do not expose sensitive repository or customer names in notifications.
* Prefer worktree spawning for concurrent remote sessions so edits do not collide.
* Keep sandboxing enabled for Remote Control server mode and set a reasonable session capacity.
* Review local prompts from the remote device as carefully as prompts entered at the workstation.

### Automation and CI/CD

* Run noninteractive jobs in disposable, isolated runners.
* Use a dedicated identity with repository and API permissions limited to the job.
* Pin workflow actions and dependencies.
* Deny production deployment, secret rotation, security-policy changes, and destructive infrastructure actions unless a separate approved control performs them.
* Require branch protection, tests, review, and deployment gates after Claude creates a change.
* Set budget, concurrency, and timeout limits.

## Monitoring and data

* Use OpenTelemetry where a managed deployment needs usage, approval, tool, and error signals.
* Redact prompts, command bodies, file contents, and tool results unless the organization has an approved need to collect them.
* Test telemetry separately for CLI, IDE, Desktop, cloud, Remote Control, and CI. Coverage can differ.
* Confirm current data retention and Zero Data Retention eligibility for the exact authentication and execution path.
* Keep an inventory of plugins, MCP servers, connectors, hooks, cloud environments, scheduled tasks, Git integrations, and Remote Control usage.
* Be able to revoke Claude sessions, long-lived tokens, API keys, Git provider grants, cloud environments, connectors, and MCP credentials.

## Claude Code security review checklist

* Each approved surface has a named owner and a documented execution location.
* Managed settings cannot be weakened by user or repository configuration.
* Sensitive paths and production credentials are explicitly denied for local sessions.
* Network access matches the surface: host policy for local work, environment policy for cloud work, and runner policy for automation.
* Desktop local, SSH, and cloud sessions have been tested separately.
* Git provider grants are repository-scoped and periodically recertified.
* Remote Control cannot be enabled outside policy and lost devices can be removed quickly.
* CI and scheduled tasks use service identities and isolated runners.
* Human review remains required before merge, deploy, destructive changes, or changes to security controls.

## Claude Code provider documentation

* [Claude Code overview](https://code.claude.com/docs/en/overview)
* [Platforms and integrations](https://code.claude.com/docs/en/platforms)
* [Security](https://code.claude.com/docs/en/security)
* [Permissions](https://code.claude.com/docs/en/permissions)
* [Sandboxing](https://code.claude.com/docs/en/sandboxing)
* [Settings and managed configuration](https://code.claude.com/docs/en/settings)
* [Use Claude Code Desktop](https://code.claude.com/docs/en/desktop)
* [Claude Code on the web](https://code.claude.com/docs/en/claude-code-on-the-web)
* [Remote Control](https://code.claude.com/docs/en/remote-control)
* [Enterprise network configuration](https://code.claude.com/docs/en/corporate-proxy)
* [Monitoring with OpenTelemetry](https://code.claude.com/docs/en/monitoring-usage)
* [Data usage](https://code.claude.com/docs/en/data-usage)

*Last reviewed: August 18, 2026*

## Applicable handbook articles

These handbook articles cover the controls most directly relevant to this product.

| Handbook area                            | Applicable articles                                                                                                                                                                                                                                                                                                                           | Why they apply                                                                                                                                           |
| ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1. Identity & access                     | <p>1.1 SSO & SCIM for AI platforms<br>1.2 RBAC across AI platforms<br>1.3 Tenant restrictions: blocking personal accounts<br>1.5 Agent and non-human identity<br>1.6 API keys and service accounts governance<br>1.7 Human-in-the-loop and approval policies</p>                                                                              | Managed authentication, roles, tenant enforcement, automation identities, service credentials, and command approvals all apply.                          |
| 2. Connectors, extensions & supply chain | <p>2.1 Connectors and apps: the integration backbone<br>2.2 MCP servers: securing the protocol<br>2.3 MCP gateways and allowlisting<br>2.4 Analyzing skills for risk<br>2.5 Plugins and marketplaces<br>2.6 Hooks and lifecycle scripts<br>2.7 The supply-chain review workflow<br>2.8 Signing and packaging</p>                              | Repositories can supply MCP configuration, skills, plugins, hooks, packages, and agent instructions; connectors and extensions add further dependencies. |
| 3. Runtime, sandboxing & autonomy        | <p>3.1 Sandbox and isolation models<br>3.2 Approval policies and least-privilege autonomy<br>3.3 Network egress control<br>3.4 Internet access and browser automation<br>3.5 Computer Use / desktop control risks<br>3.6 Scheduled and background tasks<br>3.7 Remote access, dispatch and SSH<br>3.8 File and filesystem access controls</p> | Claude Code spans local, IDE, SSH, cloud, browser, remote-control, scheduled, CI, filesystem, and egress boundaries.                                     |
| 4. Data protection                       | <p>4.1 DLP for GenAI<br>4.2 Data classification for AI prompts and outputs<br>4.3 Data residency and regional inference<br>4.4 Retention and Zero Data Retention<br>4.5 Training opt-out and data usage<br>4.6 Cross-app data flow and live artifacts<br>4.7 Secrets and credential hygiene in prompts and tools</p>                          | Source code, environment variables, repository secrets, connected data, cloud sessions, and telemetry engage the full data-control set.                  |
| 5. Threats & adversarial testing         | <p>5.1 Prompt injection: the connective risk<br>5.2 Data exfiltration via tools and connectors<br>5.3 Supply chain attacks and notable CVEs<br>5.4 Agent-specific threats: tool poisoning and confused deputy<br>5.5 Red-teaming AI systems<br>5.6 Incident response for AI systems<br>5.7 Threat modeling AI systems</p>                     | Repository instructions, build scripts, tools, plugins, MCP, remote execution, and unattended automation expose every covered threat family.             |
| 6. Observability, audit & evidence       | <p>6.1 The audit gap: what you can and can't see<br>6.2 OpenTelemetry for AI runtime<br>6.3 Compliance APIs by platform<br>6.4 Analytics and usage APIs<br>6.5 Routing AI telemetry to your SIEM<br>6.6 Evidence by surface and investigation paths<br>6.7 Continuous review cadence</p>                                                      | CLI, IDE, Desktop, cloud, Remote Control, and CI have distinct analytics, telemetry, compliance, SIEM, and investigation paths.                          |
| 7. Rollout & operations                  | <p>7.1 Roll out by risk: the phased plan<br>7.2 Pilot design and success metrics<br>7.3 The security team checklist<br>7.4 The vendor-neutral control matrix</p>                                                                                                                                                                              | Each execution surface needs risk-tiered access, a representative pilot, checklist evidence, and a vendor-neutral baseline.                              |

## Applicable Harmonic guide

* [Securing Claude Products](https://www.harmonic.security/resources/guide-securing-claude-products)

## Related handbook guidance

* [Anthropic](/by-ai-vendor/anthropic.md)
* [2.2 MCP servers: securing the protocol](/handbook/2.-supply-chain-and-extensibility/2.2-mcp-servers-securing-the-protocol.md)
* [2.6 AI hooks: inference controls and lifecycle automation](/handbook/2.-supply-chain-and-extensibility/2.6-ai-hooks-inference-controls-and-lifecycle-automation.md)
* [3.1 What Even is an AI Sandbox?](/handbook/3.-runtime-sandbox-and-autonomy/3.1-what-even-is-an-ai-sandbox.md)
* [6.2 OpenTelemetry for AI runtime visibility](/handbook/6.-observability-audit-and-evidence/6.2-opentelemetry-for-ai-runtime-visibility.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://handbook.harmonic.security/by-ai-vendor/anthropic/claude-code.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.