Claims last verified 2026-07-28 22 confirmed · 6 documented · 1 stale risk verification log →

Anthropic's policies and products change frequently — always confirm current specifics with your Anthropic contact before relying on this for a compliance decision.

API Keys & Secrets

Passwords, API keys, and credentials should never travel through a Claude conversation or sit in a folder Claude can read — the same way you wouldn't email them. This domain covers where secrets *should* live and what to ask about the edge cases.

Where this comes from: the findings below are drawn from the working group's own document (its “§” numbers are that document's sections) and, where marked Confirmed, checked against Anthropic's primary pages — see the verification log. This module is a teaching aid, not compliance or legal advice — patient-data decisions belong to your organization, its counsel, and its Anthropic contact.

How to read the chips

What we found

Each finding opens with the plain-language version; the detail, the source, and the related claims sit one click below. The chips tell you how much to lean on it.

✓ checked against Anthropic's page · ▪ carried from the group's doc, not re-checked · ⚠ treat as a question

Never paste credentials into a chat, a shared folder, or an artifact

Documented our practice source: working-group doc

Treat a Claude conversation the way you'd treat email or Slack — a place where a password or API key simply doesn't belong. Not in the chat, not in a document Claude has folder access to, not in an artifact.

Detail, source & related

Detail

General security practice (the source doc’s own caveat: not Claude-specific): never paste API keys, passwords, or credentials directly into a Claude chat, a document sitting in a folder Claude can access, or an artifact. Once a secret transits a channel, you no longer control where it’s copied, logged, or displayed — the cure is expensive (rotation, audit), the prevention is free. What Claude actually retains from such channels is a live open question for the contact: Whether Claude retains credentials that appear in content.

Source & currency

  • Source: the working-group document §2 (“What we found — general security practice, not Claude-specific”).
  • Status: DOCUMENTED · register: recommendation — our practice guidance, not an Anthropic product fact.

Secrets live in a secrets manager or environment variables — outside any shared folder

Documented our practice source: working-group doc

Keep keys in a purpose-built home — a secrets manager like 1Password, AWS Secrets Manager, or Doppler, or in environment variables — never in a plain text file, and never anywhere inside a folder you've shared with Claude.

Detail, source & related

Detail

Store keys in a dedicated secrets manager or as environment variables that live outside any folder shared with Claude, rather than in a plain text file. Secrets managers give you the things plain files can’t: access control, audit history, and one-click rotation. The boundary rule compounds with Use a dedicated working folder, not broad desktop access: a narrow working folder plus secrets stored elsewhere means there is simply nothing sensitive inside the granted scope.

Source & currency

  • Source: the working-group document §2 (“general security practice, not Claude-specific”).
  • Status: DOCUMENTED · register: recommendation — our practice guidance, not an Anthropic product fact.

.env files stay out of version control and out of Claude working folders

Documented our practice source: working-group doc

If nobody on your team writes code, you can skip this one. For teams that use the Claude API directly: the file that holds your keys (a `.env` file) has to be kept out of two places — out of *version control* (the system, such as Git, that tracks every change to a codebase; you exclude the file with a `.gitignore` entry), and out of any folder Cowork or Claude Code can see.

Detail, source & related

Detail

For developers using the Claude API: keep keys in environment variables or a .env file that is excluded from version control (.gitignore) and excluded from any Cowork/Claude Code working folder. The two failure modes it prevents are the classic ones — a key committed to a repo’s history, and a key sitting readable inside an agent’s granted scope. Whether any built-in safeguard catches a .env that lands in a connected folder anyway is an open question for the contact: Built-in safeguard if a .env file lands in a granted folder.

Source & currency

  • Source: the working-group document §2 (“general security practice, not Claude-specific”).
  • Status: DOCUMENTED · register: recommendation — our practice guidance, not an Anthropic product fact.

Scope keys narrowly; rotate on schedule and immediately on exposure

Documented our practice source: working-group doc

Every key should be able to do only the one job it exists for (least privilege), and keys should be replaced periodically — immediately if one may have leaked.

Detail, source & related

Detail

Scope each key narrowly (least privilege) and rotate keys periodically, or immediately if one may have been exposed. Least privilege caps the blast radius of any single leak; routine rotation caps its lifetime. For a small nonprofit, “rotation” can be as simple as a calendar reminder plus the secrets manager’s regenerate button — the organizational version of this practice is an open question for the contact: Best practices for organizing and rotating API keys.

Source & currency

  • Source: the working-group document §2 (“general security practice, not Claude-specific”).
  • Status: DOCUMENTED · register: recommendation — our practice guidance, not an Anthropic product fact.

When a key slips into a chat by accident: destroy it, then store it properly

Documented our practice source: working-group doc

If a credential ever lands somewhere it shouldn't — pasted into a chat, dropped in a shared file — treat it as burned. Destroy (rotate) it right away, then put the replacement where secrets actually belong. A working-group member did exactly this, and it worked.

Detail, source & related

Detail

A working-group member shared a lived incident: they accidentally pasted a cloud-service API key into a Claude conversation. Rather than ignoring it, the response modeled the correct recovery — destroy the exposed key (rotate it so the leaked value is worthless), then store the replacement properly instead of leaving it in the chat. The prevention rule (Never paste credentials into a chat, a shared folder, or an artifact) is free; the cure is the two-step recovery this vignette teaches: (1) rotate immediately on exposure — the same “immediately if one may have leaked” reflex as scheduled rotation (Scope keys narrowly; rotate on schedule and immediately on exposure); (2) relocate to where secrets live — a secrets manager or the appropriate credential-storage location (Secrets live in a secrets manager or environment variables — outside any shared folder), never the conversation.

Two things this vignette does and does not do:

Source & currency

  • Source: a working-group member’s comment on the source document (§2 “never paste keys into chat”), captured 2026-07-23. Sanitized per SO#1 — no member name, org, or service beyond “a cloud-service API key.”
  • Status: register: recommendation — a member’s lived practice, not an Anthropic-documented product fact. It teaches a response pattern; it makes no claim about Anthropic’s retention behavior (that stays OPEN). Not compliance-flagged.

Bring to the call

This module's open questions for the Anthropic contact — also in the consolidated printable register.

  1. Whether Claude retains credentials that appear in content

    Ask specifically what happens if a credential accidentally appears in a conversation, upload, or connected file — is it stored anywhere, and for how long, separate from the general retention rules.

  2. Built-in safeguard if a .env file lands in a granted folder

    Ask whether Claude has any automatic protection against reading or exposing a secrets file that accidentally ends up inside a folder it's been given access to — the practical answer today is "keep it out," but ask if there's a backstop too.

  3. Best practices for organizing and rotating API keys

    Ask for a concrete key-management routine sized for a small nonprofit team, not an enterprise security department.