Chapter 6 showed the architecture: the model asks, the harness checks permission, and the tool runs on your machine. Security follows the same picture in reverse: untrusted text flows into the model's context from many places, and the model's resulting requests flow out through tools that act with your authority.

Anthropic's security page states the division of responsibility plainly: Claude Code is built with a permission-based architecture and layered protections, and you are responsible for reviewing proposed code and commands for safety before approval. It also states that no system is completely immune to all attacks (Source 1). The rest of this page is a tour of the controls, ordered by how often a developer meets the risk.

Claude Code runs locally, but to use the model it sends data over the network: all your prompts and the model's outputs, encrypted in transit with TLS 1.2 or later. In practice that includes any file contents or command output Claude reads into the conversation (Source 2). Encryption at rest depends on the provider: infrastructure-level AES-256 disk encryption for the Anthropic API, AWS-managed keys (optionally customer-managed) on Amazon Bedrock, Google-managed keys (CMEK available) on Google Cloud's Agent Platform, and, for Microsoft Foundry, it depends on the hosting option.

The figures are from Anthropic's data-usage page (Source 2). Three further points from it: transcripts shared through /feedback are retained for five years; the optional "can Anthropic look at your transcript" survey follow-up uploads the conversation, with known key patterns redacted but source code and file contents sent as-is, and shared transcripts are kept up to six months; and on Bedrock, Google Cloud, Microsoft Foundry and Claude Platform on AWS, telemetry, error reporting and /feedback are off by default.

There are two separate questions: how Claude Code stores its own credentials, and whether your secrets end up where the model — or a repository — can see them.

• Its own: macOS Keychain when available; on Linux a file with mode 0600 (~/.claude/.credentials.json); on Windows a file inheriting the user-profile access controls (Source 1). Anything that runs as you can read that file, including a hook or an MCP server.
• Yours: keep secrets out of the repository, out of prompts, and out of any file Claude is likely to read. In CI store keys as secrets (Chapter 11).
• The sandbox does not hide credentials by default: its filesystem reads are allowed across most of the machine, including ~/.ssh and ~/.aws/credentials, until you restrict them with filesystem.denyRead (Source 4).

Finding: the project generated by Spring Initializr would have committed a local .env file. This is not a Claude Code problem — it is a reminder that an agent which creates or reads .env files in a repository without that rule is one git add -A from publishing a secret. Pair the ignore rule with a deny rule (Read(./.env)) so the agent does not read it in the first place.

What it shows: the pattern scan finds a planted example key — and also flags the project's own CI file, which is a reference to a secret (${{ secrets.… }}), not a secret. A scanner that cries wolf gets ignored, so tune patterns and review hits. (AKIAIOSFODNN7EXAMPLE is the placeholder key from AWS's documentation, not a credential.)

Anthropic's security page describes prompt injection as an attacker inserting text that overrides or manipulates an assistant's instructions (Source 1). For a coding agent the attacker does not need access to you: any text the agent reads can carry instructions — a dependency's README, a code comment, an issue or pull-request description, a web page, an MCP tool result. To the model, data and instructions are the same stream of text (Chapter 1), which is why this cannot be fixed by a clever prompt alone.

Here is a harmless reproduction of the shape. This is a real file I wrote for the demo; the "attacker" is the reserved attacker.example domain:

The comment is invisible in a rendered README but visible to an agent that reads the raw file. Anthropic lists several built-in mitigations: the permission system requires approval for sensitive operations in Manual mode; commands that fetch web content such as curl and wget are not auto-approved by default; and WebFetch runs a separate model call over a page so Claude receives that call's answer rather than the raw page (Source 1). Auto mode adds a classifier that blocks actions that escalate beyond your request, target unrecognised infrastructure, or appear driven by hostile content — and the docs say it reduces prompts but does not guarantee safety (Source 5).

A PreToolUse hook can add a deterministic check on top. This one blocks the command shapes the poisoned file asks for:

It catches the obvious shapes and lets normal work through. Now the part that matters. Here are variants a text blocklist does not catch:

The lesson, measured: all four evasions passed; only the unmodified control was caught. Matching command text is not a security boundary — the shell and any scripting language can express the same action in endless ways. Anthropic makes the same point about deny rules: a deny rule matches the command as written, and for network enforcement that does not depend on the command text you should use sandbox network isolation (Source 1). Use the hook as a seatbelt for honest mistakes and obvious shapes; rely on the sandbox's hostname-checking proxy and an isolated environment for the rest.

The MCP specification says the same about tools in general: there should always be a human in the loop with the ability to deny tool invocations (Source 6). MCP servers that fetch external content widen your injection surface, which is why Anthropic encourages writing your own or using ones from providers you trust (Source 1).

Opening a repository you did not write is not just reading it: its own settings files can define hooks, environment variables, helper commands and MCP servers. Anthropic's permissions page has a precise table of what runs before you trust a folder (Source 7):

Read the first and third rows twice. In a claude -p run — the CI and scripting mode — a repository's hooks and .mcp.json servers can run without any trust prompt. The page's own advice before running claude -p in a repository you did not write:

• Pass --setting-sources user so neither the project's settings files nor its .mcp.json are read.
• Start with --bare: no hooks, skills, commands, subagents, plugins or .mcp.json servers from the project (but the project's env block and some settings-file helpers still apply).
• Pass --settings '{"disableAllHooks": true}' to turn hooks off for that run; setting it only in user settings is not enough because project settings take precedence.
• Add a disabledMcpjsonServers entry to reject an .mcp.json server by name.

Sources: 1, 5, 4. Two protections are worth knowing by name: Claude Code asks before running a Bash command it cannot fully analyse (an allow rule for part of a command such as Bash(git *) does not skip that prompt), and it blocks a command that redirects git into the main checkout from a worktree session (Chapter 10). In non-interactive runs a call that needs approval is denied unless something approves it, so give -p jobs narrow --allowedTools lists.

What leaves your machine is a function of what the agent reads and what you share. A short inventory, from the data-usage and security pages (Source 2, Source 1):

• Everything Claude reads becomes model input: source files, @ references, command output, logs. A secret in a log it tailed is a secret in the conversation.
• WebFetch checks hostnames: before fetching, the tool sends the requested hostname (not the URL, path or page contents) to api.anthropic.com to check a safety blocklist; this runs regardless of provider and is not affected by CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC.
• /feedback, /bug, /share send a copy of the conversation including code; you choose how much history to include.
• Local transcripts persist for 30 days by default in plaintext.
• Cloud and Remote Control sessions: a cloud session stores its transcript on Anthropic's servers; Remote Control keeps execution local but stores the transcript on Anthropic servers while connected, to sync across devices.

An agent that adds a library to make a feature work is making a supply-chain decision for you. It may pick an outdated version, an abandoned project, or — worse — a package whose name it recalled slightly wrong. The defence is to make dependency changes visible and review them like code. On bookshelf, the JPA change added exactly these:

Review it: three are Spring Boot starters from the parent's managed set; h2 is a real database library from com.h2database, correctly scoped runtime (and an in-memory database is fine for a learning project, not for production). Questions to ask of any such diff: does every new group and artifact exist and match what you expect (check the spelling against the repository)? Is it managed by the parent BOM or pinned by hand? Is the scope right? Is it needed?

• Constrain it up front: in CLAUDE.md or the prompt, "no new dependencies without asking".
• Gate it mechanically: a CI check that fails when pom.xml changes without a label or review; Chapter 11's change-budget idea applies.
• Scan it: use a vulnerability scanner in your build. Limit of this page: I tried to run Maven's dependency plugins for a full tree and a scan, but the plugin artifacts could not be downloaded in this environment, so no scan output is shown rather than an invented one.

The most common failure is not an attack but an ordinary mistake, delivered fluently (Chapter 1). Every problem found while building this guide is a specimen, and each was caught by something other than the model's confidence:

The pattern is consistent: the defence was an independent check — a build, a test, an oracle, a person. That is why Anthropic's own pages keep returning to verification (Source 9) and why they place responsibility for reviewing proposed code and commands on you (Source 1). Models also have limits unrelated to attacks: a knowledge cutoff (June 2026 for the current tiers, Chapter 5), context that degrades as it fills (Chapter 1), instructions lost in compaction, checkpoints that cover file edits but not databases or deployments, and non-deterministic output.