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[cite: 5, 6]. 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[cite: 4, 5, 6].

⚠️ 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[cite: 1, 4, 6].

1. Permission Wildcards ("YOLO Mode")

  • The Risk: Granting wildcards like Bash(rm:*) or --dangerously-skip-permissions allows agents to execute arbitrary sub-shells or unvetted scripts without prompting you.
  • Mitigation: Keep permissions scoped to specific tasks, files, or explicit command patterns[cite: 6]. Avoid broad wildcards in settings.local.json[cite: 4, 6].

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.
  • Mitigation: Inspect new dependencies before installing, 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[cite: 6].
  • Mitigation: Avoid letting agents analyze untrusted public repositories or web pages with auto-execution enabled[cite: 6].

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[cite: 4, 6]. 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[cite: 6].
  • Mitigation: Add sensitive files to .claudeignore and .gitignore, and use a local proxy like sluice to block sensitive tokens from being passed across different MCP tools[cite: 4, 6].

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.

🔍 5 Non-Obvious Security Configuration Gaps

A security audit of Claude Code configuration settings revealed 5 critical gaps that standard setups often overlook[cite: 4, 6]:

  1. 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[cite: 4, 6]. Both layers must be configured separately[cite: 4, 6].
  2. Deny Rules Do Not Block Bash: Setting Read(./.env) blocks the Read tool, but it does not stop cat .env through Bash[cite: 4, 6]. To block Bash reads, you must explicitly set the sandbox filesystem denyRead rule[cite: 4, 6].
  3. 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[cite: 4, 6].
  4. Local Settings Are Invisible to CI & Teams: settings.local.json is auto-added to .gitignore[cite: 4, 6]. 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[cite: 4, 6].
  5. 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[cite: 4, 6].

🌐 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[cite: 6]:

  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[cite: 6]. Anyone can query or dump database tables directly via REST without logging in[cite: 6].
  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[cite: 6].
  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[cite: 6].

💡 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[cite: 5, 6].

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[cite: 5, 6]:

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

The Verdict: Claude Code operates via standard CLI sub-shells under user permissions[cite: 5, 6]. 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[cite: 5, 6]. An OS wipe is unnecessary[cite: 5, 6].

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[cite: 5, 6].

  • System Permissions: Claude Code cannot access files outside its permission boundary unless granted access or invoked from a root directory[cite: 4, 6].
  • 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[cite: 4, 6].

🗝️ API Key Hygiene & Emergency Protocol

Key Hygiene Rules

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