Forem: Trevor

Anthropic accidentally published Claude Code's source code. Here's the part nobody's talking about.

Trevor — Wed, 01 Apr 2026 00:54:43 +0000

Originally published on linear.gg

Earlier today, security researcher Chaofan Shou noticed that version 2.1.88 of the @anthropic-ai/claude-code npm package shipped with a source map file. Source maps are JSON files that bridge bundled production code back to the original source. They contain the literal, raw TypeScript. Every file, every comment, every internal constant. Anthropic's entire 512,000-line Claude Code codebase was sitting in the npm registry for anyone to read.

The leak itself is a build configuration oversight. Bun generates source maps by default unless you turn them off. Someone didn't turn them off. It happens.

What's worth writing about isn't the leak. It's what the source reveals about how Claude Code's safety controls actually work, who controls them, and what that means for developers who depend on them.

The permission architecture

Claude Code's permission system is genuinely sophisticated. The source shows a multi-layered evaluation pipeline: a built-in safe-tool allowlist, user-configurable permission rules, in-project file operation defaults, and a transcript classifier that gates everything else. Anthropic published a detailed engineering post about the classifier on March 25th. It runs on Sonnet 4.6 in two stages: a fast single-token filter, then chain-of-thought reasoning only when the first stage flags something. They report a 0.4% false-positive rate.

This is real engineering. The threat model is thoughtful. They document specific failure modes from internal incident logs: agents deleting remote git branches from vague instructions, uploading auth tokens to compute clusters, attempting production database migrations. The classifier is tuned to catch overeager behavior and honest mistakes, not just obvious prompt injection.

None of that is the interesting finding.

The remote control layer

The source reveals that Claude Code polls /api/claude_code/settings on an hourly cadence for "managed settings." When changes arrive that Anthropic considers dangerous, the client shows a blocking dialog. Reject, and the app exits. There is no "keep running with old settings" option.

Beyond managed settings, the source contains a full GrowthBook SDK integration. GrowthBook is an open-source feature flagging and A/B testing platform. The flags in Claude Code use a tengu_ prefix (Tengu being the internal codename) and are evaluated at runtime by querying Anthropic's feature-flagging service. They can enable or disable features server-side based on your user account, your organization, or your A/B test cohort.

Community analysis has cataloged over 25 GrowthBook runtime flags. Some notable ones:

tengu_transcript_classifier — controls whether the auto-mode classifier is active
tengu_auto_mode_config — determines the auto-mode configuration (enabled, opt-in, or disabled)
tengu_max_version_config — version killswitch

Six or more killswitches, all remotely operable. As one community analysis put it: "GrowthBook flags can change any user's behavior without consent."

That phrasing is a bit loaded. Let me reframe it more precisely.

What this actually means

Anthropic can change how Claude Code classifies commands as dangerous. They can change which safety features are active. They can do this per-user or per-organization, without shipping a new version, without any action from the developer, and without notification beyond whatever the managed-settings dialog surfaces.

This is probably not malicious. GrowthBook is a standard tool for rolling out features safely. If Anthropic discovers a false-negative pattern in their classifier, tightening behavior across all users immediately is genuinely valuable. The design makes sense from their perspective — they're operating a system where the failure mode is an AI agent doing something destructive on a developer's machine.

But it changes the trust model in a way that matters.

When you configure Claude Code's permission rules locally, you're setting preferences that feed into a classification pipeline whose behavior can shift underneath you. The classifier that ultimately decides whether a command runs is a model call, and its parameters are controlled by flags that Anthropic sets remotely.

This is distinct from a locally enforced policy. A local policy says "block rm -rf /" and that rule holds regardless of what any remote server thinks. A classifier-based system's definition of "dangerous" is a function of a prompt template, a model, and configuration that lives on someone else's infrastructure.

The defense-in-depth question

Most developers running Claude Code in production aren't thinking about this distinction. The permission system feels local. But the source shows that enforcement is partially remote, partially classifier-based, and partially under Anthropic's real-time control.

This isn't an argument that Claude Code is insecure. The classifier catches real threats. The killswitches exist for legitimate operational reasons. Anthropic is not the adversary in most developers' threat models.

But if you're operating in an environment where you need to explain exactly what controls exist between an AI agent and a destructive action, "a classifier whose behavior is remotely configurable by the vendor" is a different answer than "a deterministic policy I wrote and can audit."

This is why defense in depth matters regardless of which agent you run. The agent's built-in controls are one layer. An external enforcement layer is a different layer entirely — it handles the cases where you want a hard boundary that doesn't depend on model judgment, and holds regardless of what any remote configuration says.

What to sit with

Every AI coding agent you use has a trust boundary between "what you configured" and "what actually enforces your intent." Before today, that boundary in Claude Code was opaque. Now it's readable.

The source shows a well-engineered system with a specific trust model: Anthropic retains runtime control over safety-critical behavior, and your local configuration is an input to their system rather than the final word.

Whether that's acceptable depends on your threat model. For most individual developers, it probably is. For teams operating agents against production infrastructure, it's worth knowing that the controls you're relying on can be silently reconfigured. Not because anyone will, but because understanding what layer you're actually trusting is how you build defense that holds when assumptions change.

There's an AWS feature nobody uses for detection. I fixed that.

Trevor — Wed, 18 Mar 2026 17:00:40 +0000

Early release: Snare is new (v0.1.3). The core mechanics are solid but expect rough edges. Issues and feedback welcome: github.com/peg/snare.

TruffleHog has open-sourced a technique to identify Canarytokens.org AWS keys without triggering them. Pattern-match the key format, skip it. It's in production, it's open source, and it's in TruffleHog's own README as a headline feature. The most widely-deployed free honeytoken tool has a published static bypass.

That's the problem I kept coming back to.

The other problem: Canarytokens.org works by creating a real IAM user and waiting for CloudTrail (AWS's audit log) to catch the usage. Measured CloudTrail latency averages around 2-3 minutes, with a long tail. For human attackers moving slowly, fine. For a compromised AI agent that can enumerate credentials, attempt auth, and pivot in under 10 seconds - you're already late.

So I started thinking about where detection should actually happen. Not the API call. Earlier. Before any network request leaves the machine. Before CloudTrail has anything to log.

A healthy agent doesn't go looking for credentials it was never told about. A compromised one does. That behavioral difference is the signal.

#the-resolution-layer

the resolution layer

Every credential has a resolution step. The moment the SDK fetches or validates the credential, before it makes a single network call. That step happens locally. CloudTrail never sees it.

That's where Snare plants its precision traps.

Three of them:

awsproc — hooks AWS credential resolution via credential_process
ssh — fires on SSH connection setup via ProxyCommand
k8s — fires on any kubectl call to a fake cluster server

Precision means they fire only on active attempted use of that exact credential. Not passive reads. Not file scans. Not env enumeration. Something has to explicitly try to use the credential.

That's why false positives from your own tooling are near-zero. The profile name helps too. You name it something plausible but dormant, something you'd never run yourself. prod-admin-legacy-2024 looks like a real credential that's been sitting around. If you never invoke that profile yourself, any fire from it is signal.

#awsproc

awsproc

AWS has a feature called credential_process, which is a shell command in ~/.aws/config that runs when the SDK needs credentials. Documented for MFA caching and role-chaining. I've never seen anyone use it for detection.

The planted config looks like a real assume-role setup:

[profile prod-admin]
role_arn       = arn:aws:iam::389844960505:role/OrganizationAccountAccessRole
source_profile = prod-admin-source

[profile prod-admin-source]
credential_process = sh -c 'curl -sf https://snare.sh/c/{token} >/dev/null 2>&1; printf "{\"Version\":1,\"AccessKeyId\":\"AKIA...\",\"SecretAccessKey\":\"...\"}"'

When a compromised agent runs aws s3 ls --profile prod-admin:

T+0.00s  aws s3 ls --profile prod-admin
T+0.01s  AWS SDK begins credential resolution
T+0.01s  credential_process shell command executes
T+0.01s  curl fires to snare.sh → alert hits your webhook
T+0.02s  SDK receives fake JSON credentials
T+0.03s  SDK attempts s3.ListBuckets() → fails
T+0.03s  Agent: "AWS error, credentials may be invalid"

Alert lands at T+0.01s. CloudTrail sees nothing — there was no real API call.

Let's be honest about what that means. You're not stopping the attack. A capable agent can sweep credentials and find real ones alongside the fake. What you get is: alert before the first packet leaves the machine, fake creds that stall the agent while it gets AWS errors, and a chance to kill the process and revoke real creds while it's still running. Earlier signal plus a deception window. That's the value.

The two-profile pattern isn't just for looks. It matches how real AWS environments are set up with assume-role chains. The agent sees a legitimate-looking dormant credential and tries to use it.

#why-not-canarytokens

why not Canarytokens

Canarytokens.org creates a real IAM user and monitors CloudTrail. Pipeline is: API call → CloudTrail → Amazon's internal processing → your alert. Median latency around 2-3 minutes, tail can be much longer.

The static bypass is worse. TruffleHog detects Canarytokens.org keys by pattern-matching the key format, AKIA prefix plus account ID fingerprint, without ever calling AWS. Any agent that incorporates this heuristic skips those keys entirely.

Note: Thinkst's paid self-hosted Canary product is specifically hardened against this technique. The bypass applies to the free Canarytokens.org tier.

awsproc doesn't have either problem. Fake key IDs are generated per install... no universal AKIA pattern to fingerprint across deployments. More importantly, no key material hits the network during resolution. The curl callback fires first. You can't fingerprint it in traffic because it's not in traffic yet.

One more thing: the Snare worker now filters known scanner ASNs (Shodan, Censys, Rapid7) at the edge before they hit your webhook. AWS canary callbacks require an AWS4-HMAC-SHA256 signature to be treated as real. Not foolproof, but it cuts the noise.

#ssh-and-k8s

ssh and k8s

Same architecture, different protocols.

SSH — ProxyCommand in ~/.ssh/config runs before the SSH connection is established. Fires the moment any process tries to connect to that host — at connection setup, not auth. Canarytokens has an SSH canary but it's key-based, fires at auth time. ProxyCommand fires earlier.

Host prod-bastion-legacy
    HostName 10.0.1.45
    ProxyCommand sh -c 'curl -sf https://snare.sh/c/{token} >/dev/null 2>&1; nc %h %p'

Kubernetes — a kubeconfig with a fake server URL. Any kubectl call to that context hits snare.sh instead of a real API server. Works for any k8s SDK, not just kubectl.

Both fire only when something explicitly tries to use the credential. Not on reads, not on scans, not on anything passive.

#a-note-on-infrastructure

a note on infrastructure

The callback goes through snare.sh. Once this project is public, that's a known domain. A sufficiently aware attacker could see snare.sh in the credential_process command and skip the profile. That's a real limitation.

Self-hosting is the answer, and it's more than just a privacy option. Run the callback server inside your network and don't expose it externally; then only processes inside your perimeter can reach it. That means you've defined exactly who can trigger your canaries. Internet scanners can't reach the server. Anything that fires had to be running inside your network.

There's one more thing worth being honest about: if the callback can't reach snare.sh at all (firewall, airgap), the shell command still returns fake credentials silently. Deception survives but detection doesn't. Internal self-hosting solves this — if your internal server is unreachable, that's a signal you can monitor.

#arming-it

arming it

snare arm --webhook https://discord.com/api/webhooks/YOUR/WEBHOOK

Precision mode is the default. You get all three:

  ✓ initialized (device: dev-2146102a5849a7b3)

  Planting canaries...
  Precision mode: planting highest-signal canaries only (awsproc, ssh, k8s)
    ✓ awsproc      ~/.aws/config
    ✓ ssh          ~/.ssh/config
    ✓ k8s          ~/.kube/staging-deploy.yaml

  ✓ webhook test fired

  🪤 3 canaries armed. This machine is protected.

Use --select for an interactive picker, or --all for the full roster of 18 canary types: GCP, OpenAI, Anthropic, GitHub, Azure, npm, PyPI, MCP, Terraform, Hugging Face, Docker, and more.

#what-fires

what fires

🔑 AWS canary fired — agent-01
Token   agent-01-9193baxx57a260b20858xx5a7a14axxa
Time    2026-03-14 04:07:33 UTC
IP      34.121.8.92       Location  Council Bluffs, US
Network Amazon Technologies Inc (AS16509)
UA      Boto3/1.34.46 md/Botocore#1.34.46 ua/2.0 os/linux#6.8.0...
⚠️ Likely AI agent   Request originated from Amazon Technologies Inc

Boto3 user agent tells you which SDK. The ASN tells you it came from a cloud-hosted agent. Council Bluffs is an AWS data center. That's the signal - something running in the cloud tried to resolve credentials on your machine.

#no-daemon-no-proxy

no daemon. no proxy.

Snare doesn't run anything. It plants credential files and walks away. The credential is the sensor. When a compromised agent finds it and tries to use it, the SDK makes the callback, not Snare, not a background process, not anything you're responsible for keeping alive.

If you've read my last post about credentials leaking into the agent context window — this is what you pair with that. Rampart catches credentials before they enter context. Snare catches what happens if they get through anyway. Two different layers of the same problem.

GitHub: github.com/peg/snare

Install: curl -fsSL https://snare.sh/install | sh

The resolution layer is the earliest point you can catch a compromised agent touching credentials. Everything after that — the API call, the CloudTrail log, the SIEM alert — is already downstream of the thing you actually wanted to detect.

[Boost]

Trevor — Fri, 13 Mar 2026 13:57:23 +0000

Trevor

Mar 13

The gap in AI agent security nobody talks about: your .env is already in the context window

#showdev #ai #security #go

Comments 19

3 min read

The gap in AI agent security nobody talks about: your .env is already in the context window

Trevor — Fri, 13 Mar 2026 13:54:02 +0000

Your AI coding agent just read your .env file.

Not on purpose. You asked it to fix a bug in your config loader, so it read the config file to understand the format. That config had AWS_SECRET_ACCESS_KEY in it. Now that key is sitting in the context window.

And from here, the agent can include that key in anything. A curl command. A file write. A code snippet it generates as an "example." Not because it's attacking you. Because the key is in context and the model thinks it's relevant.

No sandbox catches this. The file was inside your project folder. The agent had permission to read it. Everything worked exactly as designed.

this is the gap

Every AI agent security tool I've looked at focuses on blocking dangerous actions. Don't run rm -rf /. Don't execute SQL drops. Don't call sketchy URLs.

That matters. But the dangerous moment isn't always when the agent does something. Sometimes it's when the agent reads something and sensitive data quietly enters the context window.

Think about it:

Agent reads config.yaml (totally allowed, it's in your project folder)
That file has STRIPE_SECRET_KEY=sk_live_... in it
Key is now in the context window
Three turns later, the agent writes a test file with the key as a "realistic example"
That test file gets committed and pushed

Nothing here looks like an attack. No exfiltration. No curl to an external URL. Just a read, then a write, with a secret accidentally carried between them.

so I built something

I kept hitting this while running AI agents on my own stuff. Started logging everything, every file read, every command, every network request, and realized the scariest things weren't the obvious attacks. They were the quiet reads.

Rampart is an open-source policy engine that sits between AI agents and your OS. It checks every tool call before execution. But the important part is it also scans tool responses before they reach the agent.

- name: block-credential-leak
  match:
    tool: [read, exec]
  rules:
    - action: deny
      when:
        response_matches:
          - "AKIA[0-9A-Z]{16}"           # AWS access keys
          - "-----BEGIN.*PRIVATE KEY-----" # SSH/TLS keys
          - "ghp_[a-zA-Z0-9]{36}"         # GitHub tokens
          - "sk-[a-zA-Z0-9]{20,}"         # Stripe/OpenAI keys

Agent reads a file containing a secret, Rampart blocks the response before the agent sees it. The secret never enters context. Attack chain breaks at step 2 instead of step 5.

other stuff it does

Response scanning is the thing I think is most underappreciated but Rampart also handles the basics.

Need to temporarily allow something that got blocked? Allow it for an hour:

rampart allow "docker build *" --for 1h

Expires automatically. --once for single use.

Don't want to write policy from scratch? Run in monitor mode, then generate rules from what your agent actually did:

rampart init --from-audit ~/.rampart/audit/

Works with basically everything. Openclaw, Claude Code, Codex, Cline, Cursor, any MCP server, any CLI tool:

rampart setup claude-code    # native hooks
rampart setup codex          # LD_PRELOAD wrapper
rampart wrap -- aider        # shell wrapping
rampart mcp -- npx server    # MCP proxy

under the hood

Rampart uses different interception depending on the agent.

For Claude Code and Cline, it registers native hooks at the PreToolUse lifecycle point. For Codex and agents that spawn subprocesses, it injects via LD_PRELOAD so every child process goes through the policy engine. For anything else, it wraps $SHELL.

All three feed into the same YAML policy engine. Evaluation is almost instant, and everything gets logged to a hash-chained audit trail.

a fun bug I found

While integrating with OpenClaw, I found that it wraps every command in /bin/bash -c <command>. Our policy had:

command_matches:
  - "cat **/.ssh/id_*"

But the actual string was /bin/bash -c cat ~/.ssh/id_rsa 2>&1. Glob didn't match. Credential reads were getting through.

We added shell wrapper stripping to the normalizer. It now extracts the inner command before matching. But it was a good reminder that the gap between what you think you're blocking and what's actually hitting your engine can be bigger than you expect.

try it

brew tap peg/rampart && brew install rampart
rampart setup claude-code

Single Go binary. Apache 2.0. Ships with 45 rules out of the box.

GitHub: github.com/peg/rampart
Docs: docs.rampart.sh

If you're running AI agents on a codebase with secrets in it (so, all of us), the context window is the attack surface nobody's watching.