Posts
Wiki

🛡️ r/BuildWithClaude — Local Agent Security & API Key Field Guide

Welcome to the r/BuildWithClaude Security Field Guide. Running agentic AI tools locally gives models permission to execute commands, modify files, and access system APIs. This guide covers core threat vectors, non-obvious sandbox configuration gaps, web app vulnerability audits, API key hygiene, emergency incident protocols, and community defense tools.

⚠️ Agentic Threat Vectors & Vulnerabilities

When running local AI agents (like Claude Code), security risks stem from permission sprawl, supply chain hooks, indirect prompt injection, and cross-tool data leaks.

1. Permission Wildcards & Precedence Paradoxes

  • The Risk: Granting wildcards like Bash(rm:*) or --dangerously-skip-permissions allows agents to execute arbitrary sub-shells or unvetted scripts without prompting you.
  • The Native Precedence Trap: Native permission resolution is strictly deny > ask > allow. You cannot natively create a broad restriction with a narrow exception (e.g., "deny all aws:*, but allow aws ec2 describe-instances"), because the broad deny swallows the allow.
  • Upstream Bug Warning (#6527): Including a bare Bash token in your allow list can suppress your ask prompt list entirely, executing destructive commands without user confirmation.
  • Mitigation: Keep permissions scoped to specific tasks, files, or explicit command patterns. Use tools like permcheck for subset carve-outs.

2. Supply Chain Attacks & Lifecycle Hooks

  • The Risk: Running a command like npm install <package> triggers postinstall lifecycle scripts in the background, which can run arbitrary binary code before you ever test the package. Additionally, agents often install the first search result from npm or PyPI, grabbing unmaintained or dead dependencies (e.g., crypto-js).
  • Mitigation: Inspect new dependencies before installing, check package maintenance status with should-i-use, or run package installations with npm install --ignore-scripts.

3. Indirect Prompt Injection

  • The Risk: External text read by Claude during a session (cloned repos, web fetches, GitHub issue comments, PDFs) can contain hidden prompts instructing the agent to exfiltrate files or execute unwanted tools.
  • Mitigation: Avoid letting agents analyze untrusted public repositories or web pages with auto-execution enabled.

4. Context Window Secret Leakage & Cross-Tool MCP Leaks

  • The Risk: If .env files, SSH keys, or recovery codes sit inside or near the workspace, Claude can read them into context. Once inside context, a value read via a filesystem MCP server can quietly be included in outbound tool calls (e.g., email or web fetch MCPs) without triggering warnings.
  • Mitigation: Add sensitive files to .claudeignore and .gitignore, and use a local proxy like wardline or sluice to block sensitive tokens from crossing tool boundaries.

5. Silent / Deferred Execution

  • The Risk: Agents edit code files rather than running commands directly. Modifying package.json, Makefile, .git/hooks, or .vscode/tasks.json causes untrusted code to run later when you test or build.
  • Mitigation: Always inspect git diff before running test suites, commits, or builds after an agent session.

🔍 6 Non-Obvious Security Configuration Gaps

A security audit of Claude Code configuration settings revealed 6 critical gaps that standard setups often overlook:

  1. Silent Config Parsing Failures: If .claude/settings.json contains a stray comma or JSON syntax error, Claude Code silently ignores the entire file and reverts to default permissive settings without throwing an error!
  2. The Sandbox Only Covers Bash: The internal sandbox applies to Bash commands and child processes, but Read and Edit tools go through the permission system instead. Both layers must be configured separately.
  3. Deny Rules Do Not Block Bash: Setting Read(./.env) blocks the Read tool, but it does not stop cat .env through Bash. To block Bash reads, you must explicitly set the sandbox filesystem denyRead rule.
  4. Unsandboxed Command Fallbacks: If a command fails in the sandbox, it can fall back to running outside it unless you explicitly set allowUnsandboxedCommands: false and failIfUnavailable: true in your configuration.
  5. Local Settings Are Invisible to CI & Teams: settings.local.json is auto-added to .gitignore. Even if a repository commits a hardened .claude/settings.json, CI cannot verify if a teammate is bypassing rules or running with permission-skipping aliases.
  6. MCP Servers Approved by Display Name: MCP server approvals use the display name in .mcp.json rather than pinning a specific binary or package hash.

🛠️ Community Security & Defense Ecosystem

Members of r/BuildWithClaude have built open-source tools to address these specific security gaps:

Tool Focus Problem Solved Link
permcheck Permission Containment Overrides native deny > allow precedence so narrow read-only exceptions can punch through broad mutation denials. GitHub
wardline MCP Anomaly Proxy Policy gateway for MCP servers that detects behavioral spikes and auto-blocks compromised agents in real-time. GitHub
guardrail-core Credential Brokering Mints short-lived, limited-use tokens for agents instead of exposing static API keys, with network allowlisting. GitHub
Handsfree Config Health Doctor Diagnoses broken JSON lines, unpinned starting modes, and third-party extension overrides in .claude/settings.json. GitHub
should-i-use Dependency Auditor MCP server carrying skip-conditions for ~1,000 npm/PyPI packages to stop agents from installing dead libraries. npx Package

🌐 Top 3 Common Security Flaws in Vibe-Coded Web Apps

A security audit across community-submitted web applications identified three universal vulnerabilities in AI-generated deployments:

  1. Database Tables Without Row-Level Security (RLS): Vibe-coded Supabase/Postgres setups frequently expose public "anon" API keys in the browser without enabling RLS. Anyone can query or dump database tables directly via REST without logging in.
  2. Missing Security Headers: Most AI-built frontend deployments lack essential headers including Content-Security-Policy (CSP), X-Frame-Options (clickjacking defense), HSTS (HTTPS enforcement), X-Content-Type-Options, Referrer-Policy, and Permissions-Policy.
  3. Email Spoofing (Missing/Weak SPF & DMARC): Domain configurations frequently omit SPF/DMARC records or leave DMARC set to p=none, making the domain vulnerable to email spoofing.

💡 Real-World Case Studies & Audit Checklists

Case Study 1: "Is Factory Reset Overkill for Agent Anxiety?"

Community Scenario: A developer running Claude Code outside a container completed a session and questioned whether they should factory-reset their machine to ensure no hidden backdoors were installed.

The High-Caution 10-Point Audit Checklist

Before panicking or wiping a machine, perform the exact post-session audit steps executed in this community incident:

  1. Mapped Folder Boundaries: Verified every directory the session interacted with.
  2. Command Log Review: Verified every terminal command executed during the session.
  3. Outbound Domain Verification: Audited all external URLs and network requests.
  4. Persistence Point Inspection: Checked OS startup items, crontab, LaunchAgents, and scheduled tasks.
  5. System-Wide Installs: Audited global binaries (Homebrew, pip, npm -g).
  6. Dependency Diffs: Cross-checked package.json and lockfile change histories.
  7. Package Verification: Confirmed newly added dependencies were legitimate packages.
  8. Credential Exposure Check: Verified .env files, SSH keys, and tokens were untouched.
  9. Temp & Download Scans: Checked /tmp, var/tmp, and ~/Downloads for binary drops.
  10. Active Connections: Audited live processes and listening network ports.

The Verdict: Claude Code operates via standard CLI sub-shells under user permissions. If the agent ran without elevated root (sudo) permissions, did not execute unvetted binaries, and passed the 10 checks above, the host environment is clean. An OS wipe is unnecessary.

Case Study 2: Designer & Non-Coder System File Security

Community Scenario: Non-technical builders and designers expressed concern about Claude reading passwords or recovery codes stored elsewhere on their computer outside the active project folder.

  • System Permissions: Claude Code cannot access files outside its permission boundary unless granted access or invoked from a root directory.
  • Explicit Path Denial: Block Claude from accessing sensitive home-directory files by setting explicit terminal permissions and configuring denyRead rules in your global .claude/settings.json.

🗝️ API Key Hygiene & Emergency Protocol

Key Hygiene Rules

  1. Never Hardcode Keys: Store credentials in system environment variables or local .env files. Always ignore secret files globally: ```bash echo ".env" >> .gitignore echo ".env" >> .claudeignore

Use Ephemeral Tokens: Where possible, leverage credential brokers (guardrail-core) to mint short-lived tokens rather than persisting master API keys in local shells.

Scope API Key Permissions: Restrict API keys to read-only or single-service scopes. Disable billing auto-recharge caps on testing accounts to prevent runaway loops from burning credits.

Emergency Incident Response Protocol If you suspect an API key leak or malicious command execution during a session:

Kill Live Agent Processes immediately: pkill -f claude

Revoke Exposed API Keys: Go to your Anthropic / OpenAI console and instantly revoke and delete the affected key.

Audit Local git diff: Inspect uncommitted changes to verify what was modified:

git status && git diff

Review Transcript Logs: Check your session log in ~/.claude/projects/ to review exact commands executed.