If you're running Claude Code in a team environment, CI/CD pipeline, or any setup where sensitive credentials are accessible, this one's worth reading before your next deployment.
A proof-of-concept exploit was published showing that an attacker who has compromised your Claude Code session can resume the attack even after you rotate your API tokens. GovInfoSecurity broke the story, and the implication is serious: the standard incident response playbook has a blind spot when agentic AI tools are involved.
The Problem: What Token Rotation Actually Fixes (and What It Doesn't)
The conventional wisdom is straightforward: if a credential gets leaked, rotate it. Issue a new token, revoke the old one, done. The assumption underneath that is that invalidating the token severs the attacker's path back in.
That assumption holds in most web API scenarios. It does not hold cleanly in an agentic AI coding environment.
Claude Code isn't a passive autocomplete tool. It's an agent with real capabilities:
- File system access — reads and writes your local project files
- Shell execution — runs arbitrary commands on your machine or container
- External API calls — can reach out to services your project integrates with
- Context persistence — the agent session maintains state across interactions
The PoC demonstrates that an attacker can exploit this context persistence. After token rotation, if the session context or agent state isn't completely torn down and rebuilt, there's a re-entry vector. The attacker doesn't need the new token — they can piggyback on the still-alive session scaffolding.
The incident response playbook says "rotate → verify → close ticket." The gap is that step two — verify — rarely includes checking whether the agent's runtime context was fully reset.
Who Is Actually at Risk
Not all Claude Code setups carry the same exposure. Here's a rough breakdown:
| Setup | Risk Level | Why |
|---|---|---|
| Personal local dev, no cloud secrets | Low | Limited blast radius |
Personal local, .env with cloud credentials |
Medium | env vars readable by agent |
| Shared dev environment | High | Multiple users, persistent sessions |
| CI/CD pipeline integration | High | Automated agent with broad secret access |
| Team deployment, shared API key | Critical | Single compromise affects entire team |
If your Claude Code session can read AWS_SECRET_ACCESS_KEY, a database password, or a GitHub token from environment variables — and that's the default for most dev machines — you're in the medium-to-high category.
The Fix: What Actually Stops the Attack
There are three concrete things to do, in order of urgency.
1. Minimize What the Agent Can See
This is the most impactful change and doesn't require waiting for Anthropic to patch anything.
Apply least privilege to the Claude Code session itself. That means:
# Instead of running Claude Code with your full shell environment:
claude
# Create a scoped environment for it:
env -i \
HOME="$HOME" \
PATH="/usr/local/bin:/usr/bin:/bin" \
ANTHROPIC_API_KEY="$ANTHROPIC_API_KEY" \
claude
The env -i approach strips everything except what you explicitly pass. Your AWS_*, DATABASE_URL, GITHUB_TOKEN, and any other secrets in your shell environment won't be visible to the agent.
For Docker-based setups, scope it at the container level:
# Don't pass the whole host environment
# Only expose what Claude Code explicitly needs
ENV ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
# Leave everything else out
2. Token Rotation + Full Session Teardown
Token rotation alone isn't enough. Here's what a complete incident response looks like:
# Step 1: Rotate the compromised token
# (do this in your provider's console/API)
# Step 2: Kill any active Claude Code processes
pkill -f "claude"
# Step 3: Clear session data and context caches
rm -rf ~/.claude/session*
rm -rf ~/.claude/cache*
# Step 4: Audit recent command history from the agent
# Claude Code logs interactions — check them
cat ~/.claude/logs/*.log | grep -E "(write|exec|curl|wget)"
# Step 5: Restart from a clean shell with scoped credentials
The third step is what most incident responses miss. Rotating the token and killing the visible process isn't enough if the agent's stored context can be deserialized and replayed.
3. Audit CI/CD Integrations
If Claude Code is wired into your pipeline, the risk surface is wider because automation runs the agent without a human watching.
For GitHub Actions:
# Before — likely what your workflow looks like:
- name: Run Claude Code review
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }} # ← don't do this
DATABASE_URL: ${{ secrets.DATABASE_URL }} # ← unnecessary
run: claude review
# After — scope it:
- name: Run Claude Code review
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
# Only the secrets Claude Code actually needs for THIS job
run: claude review
The principle here is the same: don't let the agent inherit secrets it doesn't need for the specific task it's running.
For AWS Secrets Manager or Vault-based setups, audit which secrets your CI agent role can access:
# Check what your CI role can actually read
aws iam simulate-principal-policy \
--policy-source-arn arn:aws:iam::ACCOUNT:role/ci-claude-role \
--action-names secretsmanager:GetSecretValue \
--resource-arns "*"
If that list is longer than it should be, tighten the IAM policy before the next run.
Variations and Gotchas
The same class of problem applies to other agentic tools. Cursor, GitHub Copilot Workspace, and similar tools that have file system and shell access share the structural risk. The specific exploitation path differs, but the underlying model — agent with broad system access, persistent session state — is the same across all of them. Don't assume "but we use X instead of Claude Code" means you're clean.
Environment variable inheritance is sneaky. On macOS, if you use tools like direnv or load secrets in .zshrc, those values are present in every shell and every process you spawn — including Claude Code. What worked for me was creating a dedicated shell alias:
# In .zshrc
alias claude-safe='env -i HOME="$HOME" PATH="$PATH" ANTHROPIC_API_KEY="$ANTHROPIC_API_KEY" claude'
Running claude-safe instead of claude gives me a clean session every time.
Anthropic hasn't published a patch or mitigation guide yet as of this writing. That means the defenses above are your best options right now. Watch the official Anthropic security page and the Claude Code changelog for updates.
Session logs are your forensic trail. Claude Code writes interaction logs — get familiar with where they live on your system before you need them in an incident. On macOS and Linux, check ~/.claude/logs/. Knowing what the agent actually did is the only way to determine blast radius after a compromise.
The Structural Issue Worth Naming
This vulnerability is a specific instance of a broader architectural tension. We've been building security models around credential-based access for decades. Rotate the key, sever the access — clean mental model, mostly works.
Agentic AI tools break that model because they add a layer of state and context between the credential and the operation. The credential controls entry, but what the agent does once inside — and what it remembers — is a different control plane entirely.
The takeaway is simple: if a tool can touch your file system, run shell commands, or call external APIs, it belongs in your threat model the same way a human operator would. Least privilege, audit logs, session hygiene — apply all of it.
Anthropic will likely publish guidance. Until then, don't wait.
🐦 Faster updates on X: @baegseungh7061
📚 More in this series: AI Insights
💌 Subscribe: Follow on X or grab the RSS
댓글
댓글 쓰기