Feature Request: Zero-Trust Architecture for Environment Variable Security

Summary

Implement client-side secret detection and replacement to prevent real secrets from being transmitted to Claude
Code's API, even when users explicitly read environment files.

Problem Statement

Multiple issues have highlighted serious security concerns with Claude Code's current environment variable
handling:

Issue Potential Security Risk: Claude Code Accessing Local .env File Environment Variables #112: "Potential Security Risk: Claude Code Accessing Local .env File Environment Variables"
Issue [BUG] Claude loads my projects .env into its bash environment (!) #401: "Claude loads my projects .env into its bash environment (!)" - User experienced unexpected
behavior when Claude automatically loaded their .env file, including dropping their local development database
Issue How to securely provide env variables to MCP servers? #2065: "How to securely provide env variables to MCP servers?" - Users seeking secure ways to handle
secrets, noting that "env variables and code should not go together"

These issues demonstrate that the current trust-based model creates real security risks for developers.

Current Security Model Limitations

Relies on user awareness to avoid reading files with secrets
Automatically loads .env files from projects (Issues [BUG] Claude loads my projects .env into its bash environment (!) #401, Potential Security Risk: Claude Code Accessing Local .env File Environment Variables #112)
Real secrets transmitted when .env files are explicitly read via tools
Trust-based approach where users must remember what's sensitive
No protection against accidental secret exposure

Proposed Zero-Trust Architecture

Client-Side Secret Protection

Automatic Detection: Pattern-based recognition of common secrets (API keys, tokens, connection strings)
Pre-transmission Replacement: Replace real values with temporary placeholders before API calls
Local Resolution: Real secrets only used during local execution, never transmitted
MCP Server Integration: Secure environment variable handling for MCP servers (addresses How to securely provide env variables to MCP servers? #2065)

Example Flow

# Local .env.local (never transmitted)
CLOUDFLARE_API_TOKEN=real_secret_value_123abc
DATABASE_URL=postgres://user:pass@localhost:5432/db

# What Claude receives (safe for analysis)
CLOUDFLARE_API_TOKEN=<PLACEHOLDER_TOKEN_001>
DATABASE_URL=<PLACEHOLDER_DB_URL_002>

Benefits

- Solves existing security issues: Addresses concerns raised in #112, #401, #2065
- Defense in Depth: Protection even if users accidentally share sensitive files
- Enterprise Compliance: Better alignment with security policies
- Developer Experience: Focus on code without constant secret management anxiety
- Audit Trail: Clear separation of transmitted vs. local-only data
- Backward Compatibility: Existing workflows continue to work

Implementation Approaches

1. Pattern Matching: Detect common secret formats (base64, UUIDs, API key patterns, connection strings)
2. Allowlist: Only specific non-secret env vars transmitted
3. Local Execution Proxy: Sensitive operations resolved locally
4. Encrypted Secret Store: Optional integration with system keychains
5. Configuration Override: Allow users to mark specific variables as sensitive

Use Cases

- Reading configuration files for architecture analysis without exposing credentials
- Code review of deployment scripts while keeping secrets local
- Debugging environment setup issues safely
- Security audits without credential exposure
- Safe MCP server configuration (addresses #2065)

Related Issues

This proposal directly addresses security concerns raised in:
- #112 - Potential security risk with .env access
- #401 - Automatic .env loading causing issues
- #2065 - Secure environment variable management for MCP servers

This would significantly enhance Claude Code's security posture while maintaining its powerful code analysis
capabilities and solving multiple existing user-reported security issues.

Implement Zero-Trust Environment Variable Accountability System

Implement shell wrapper solution for Issue anthropics#2695

Add working hook-based solution for Issue anthropics#2695

feat: Zero-trust environment variable security with Byzantine fault t…

feat: Add minimal security demo hook for Issue anthropics#2695

Hey, this is a fantastic and well-researched proposal. I completely agree that handling secrets and environment variables is a critical security area for any agentic tool. The zero-trust model you've outlined is definitely the right direction to aim for.

While we wait for something like automatic, client-side redaction to be implemented, I've found a couple of existing features in Claude Code that help mitigate these risks pretty effectively. It's more of a manual "blocklist" approach rather than your proposed automatic "redaction" approach, but it has worked well for my team.

1. Using `deny` Rules in `settings.json`

The most direct way to prevent Claude from accessing sensitive files is by using the deny permission rules in a .claude/settings.json file at the root of your project. This file can be checked into source control, so the whole team gets the same protection.

The documentation for this is under the "Excluding sensitive files" section in the settings page. You can explicitly block Read access to any file pattern.

Here’s an example .claude/settings.json that I use:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./*.pem)",
      "Read(./*.key)",
      "Bash(printenv)",
      "Bash(export)"
    ]
  }
}

This configuration:

Blocks Claude from reading any .env file or files in a secrets/ directory.
Blocks it from running printenv or export to dump environment variables.
If Claude tries to access these, it will be told it doesn't have permission, and it won't see the contents.

This directly addresses the concerns from issues #112 and #401 by making those files invisible to the agent.

2. Using Hooks for More Advanced Logic

For even more granular control, you could use the Hooks feature. You could set up a PreToolUse hook that runs a script to inspect every Bash or Read command.

For example, a hook script could:

Check if a Read command is targeting a file with a name like .env.
Check if a Bash command contains strings like cat .env, aws configure, etc.
If it finds a match, the hook can exit with a status code 2 to block the tool call and feed a custom error message back to Claude (and the user).

This is more complex to set up, but it gives you total client-side control over what the agent is allowed to even attempt.

Again, your proposal for automatic secret redaction is a much better long-term solution because it doesn't rely on developers remembering to configure blocklists. It would be a huge step forward for security and enterprise adoption.

But in the meantime, the deny rules in settings.json provide a pretty solid safety net. Hope this helps!

+1 from me on this feature request.

feat: Add minimal security demo hook for Issue anthropics#2695\n\nAdd…

feat: Add Zero-Trust Security Framework for Issue anthropics#2695\n\n…

docs: Add enhancement documentation and finalize implementation\n\nCo…

Add minimal security hook implementation

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

It is still an outstanding feature request.

This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.

This issue was closed incorrectly despite recent human comments. This behavior of the bot is reported at #16497. Upvote or comment on that issue, so maybe it gets noticed.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.

Navigation Menu

Repository navigation

Feature Request: Zero-Trust Architecture for Environment Variable Security #2695

Summary

Problem Statement

Current Security Model Limitations

Proposed Zero-Trust Architecture

Client-Side Secret Protection

Example Flow

1. Using `deny` Rules in `settings.json`

2. Using Hooks for More Advanced Logic

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Feature Request: Zero-Trust Architecture for Environment Variable Security #2695

Description

Summary

Problem Statement

Current Security Model Limitations

Proposed Zero-Trust Architecture

Client-Side Secret Protection

Example Flow

Activity

coygeek commented on Aug 24, 2025

1. Using deny Rules in settings.json

2. Using Hooks for More Advanced Logic

github-actions commented on Dec 7, 2025

coniferconcepts commented on Dec 13, 2025

github-actions commented on Jan 13, 2026

marcindulak commented on Jan 13, 2026

github-actions commented on Jan 20, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

1. Using `deny` Rules in `settings.json`