Listen to this Post
Introduction:
AI-powered coding assistants like Code execute arbitrary Bash commands, read your filesystem, and call external services using your credentials. Default configurations grant far too much trust, turning a helpful development tool into a catastrophic incident waiting to happen. Treating `./` as a security boundary—not just an AI configuration folder—is the first step toward production-safe autonomous coding.
Learning Objectives:
- Implement least-privilege filesystem scoping and explicit allow/deny rules for AI tool calls.
- Deploy pre-execution hooks with secret scanning (gitleaks) to prevent credential leakage.
- Configure read-only database roles and environment-variable-based token management for MCP services.
You Should Know:
- Lock Down Your `./` Directory and Git Hygiene
The most common mistake is committing secrets and local configuration to version control. Any `.env` file or `./settings.local.json` pushed to Git is immediately compromised.
Step-by-step guide:
1. Add to `.gitignore` (Linux/macOS/Windows Git Bash):
echo "./settings.local.json" >> .gitignore echo ".env" >> .gitignore echo "./.secrets" >> .gitignore
- Scan your repository history for accidentally committed secrets:
Install gitleaks (Linux - amd64) wget https://github.com/gitleaks/gitleaks/releases/download/v8.18.0/gitleaks_8.18.0_linux_x64.tar.gz tar -xzf gitleaks_8.18.0_linux_x64.tar.gz sudo mv gitleaks /usr/local/bin/ Scan current repo gitleaks detect --source . --verbose Scan entire git history gitleaks detect --source . --redact --report-format json --report-path leak-report.json
3. Prevent future leaks with a pre-commit hook:
.git/hooks/pre-commit !/bin/bash gitleaks detect --source . --no-banner if [ $? -ne 0 ]; then echo "❌ Gitleaks found secrets. Commit blocked." exit 1 fi
On Windows (PowerShell), you can use `pre-commit` Python package and gitleaks.exe.
- Use environment variables for any local override – never hardcode tokens in
settings.local.json. Reference `${ENV_VAR}` instead. -
Scope Filesystem MCP to the Project Root – Not $HOME
Default filesystem MCP access gives Code reach into your entire user directory. One recursive delete command could wipe your backups, dotfiles, or worse.
Step-by-step guide:
1. Create a strict `settings.json` inside `./`:
{
"permissions": {
"allow": [
"read:./",
"write:./",
"execute:./scripts/"
],
"deny": [
"read:/etc/",
"write:/etc/",
"read:${HOME}/.ssh/",
"write:${HOME}/.ssh/",
"read:${HOME}/.aws/",
"execute:rm",
"execute:dd",
"execute:shred"
],
"filesystem_mcp": {
"root": "${PWD}",
"max_depth": 5
}
}
}
- Verify scoping using a test command inside Code:
This should succeed ls ./src This should fail with permission denied ls ~/.ssh
3. For Windows environments, restrict drive paths similarly:
"deny": ["read:C:\Windows\System32\", "write:C:\Windows\"]
- Sandbox further using Linux `bubblewrap` or Docker (advanced):
Run Code inside a read-only root with a writable project bind-mount bwrap --ro-bind /usr /usr \ --ro-bind /lib /lib \ --ro-bind /lib64 /lib64 \ --bind /path/to/project /project \ --proc /proc \ --dev /dev \ --unshare-all \ bash -c "cd /project && -code"
-
Add a PreToolUse Hook with Gitleaks to Catch Secrets Before They Get Written
Hooks intercept every tool call (Bash, file write, MCP request) and can block or modify it. A `PreToolUse` hook running gitleaks prevents accidental credential commits in real time.
Step-by-step guide:
1. Create the hook script `~/./hooks/pre_tool_use.sh` (Linux/macOS):
!/bin/bash
$1 = tool name (e.g., write_file, execute_command)
$2 = tool arguments as JSON
TOOL_NAME="$1"
TOOL_ARGS="$2"
if [ "$TOOL_NAME" = "write_file" ]; then
Extract file path and content from JSON (using jq)
FILE_PATH=$(echo "$TOOL_ARGS" | jq -r '.file_path')
CONTENT=$(echo "$TOOL_ARGS" | jq -r '.content')
Check content for secrets
echo "$CONTENT" | gitleaks detect --no-git --no-banner --pipe
if [ $? -ne 0 ]; then
echo "🚫 Secret detected in $FILE_PATH. Write blocked."
exit 1
fi
fi
For execute_command, scan command strings for dangerous patterns
if [ "$TOOL_NAME" = "execute_command" ]; then
COMMAND=$(echo "$TOOL_ARGS" | jq -r '.command')
if echo "$COMMAND" | grep -qE "rm -rf /|mkfs|dd if=|:(){ :|:& };:"; then
echo "🚫 Dangerous command blocked: $COMMAND"
exit 1
fi
fi
exit 0
2. Register the hook in your `./settings.json`:
{
"hooks": {
"PreToolUse": {
"command": "~/./hooks/pre_tool_use.sh",
"timeout_seconds": 5
}
}
}
- Test the hook – ask Code to write a file containing `API_KEY=”sk-live-1234567890″` and verify it gets blocked.
-
For Windows PowerShell, create `pre_tool_use.ps1` and use `Select-String` for regex pattern matching.
4. Use Read-Only DB Roles for Postgres MCP
The Postgres Model Context Protocol (MCP) allows Code to query and modify your databases. Granting write access is equivalent to handing over `DROP TABLE` permissions to an unpredictable agent.
Step-by-step guide:
1. Create a read-only PostgreSQL user:
-- Connect as superuser CREATE USER _ro WITH PASSWORD 'secure_password'; GRANT CONNECT ON DATABASE yourdb TO _ro; GRANT USAGE ON SCHEMA public TO _ro; GRANT SELECT ON ALL TABLES IN SCHEMA public TO _ro; ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO _ro; -- Explicitly revoke dangerous privileges REVOKE CREATE, TEMP ON DATABASE yourdb FROM _ro; REVOKE UPDATE, DELETE, INSERT, TRUNCATE ON ALL TABLES IN SCHEMA public FROM _ro;
- Configure `.mcp.json` with environment variable for the token:
{ "mcp_servers": { "postgres": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://_ro:${PG_PASSWORD}@localhost:5432/yourdb"], "env": { "PG_PASSWORD": "${PG_PASSWORD_ENV}" }, "permissions": { "allow": ["execute_sql"], "deny": ["execute_sql:ALTER", "execute_sql:DROP", "execute_sql:UPDATE", "execute_sql:DELETE"] } } } } -
Set the environment variable securely (never in `.env` committed to Git):
export PG_PASSWORD_ENV=$(aws secretsmanager get-secret-value --secret-id -pg | jq -r .SecretString)
-
Audit the MCP logs periodically to ensure no write attempts occur.
-
Log Every Tool Call – Your Only Forensic Truth
When something goes wrong (accidental deletion, secret exfiltration, data corruption), detailed logs are indispensable. Code’s default logging is often minimal and ephemeral.
Step-by-step guide:
- Enable verbose logging and redirect to a secure, append-only file:
In your launch script or .bashrc export CLAUDE_CODE_LOG_LEVEL="debug" export CLAUDE_CODE_LOG_FILE="/var/log/-code/audit.log" mkdir -p /var/log/-code chmod 750 /var/log/-code
-
Create a `PostToolUse` hook to capture every tool result:
~/./hooks/post_tool_use.sh !/bin/bash TOOL_NAME="$1" TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ") LOG_ENTRY="{\"timestamp\":\"$TIMESTAMP\",\"tool\":\"$TOOL_NAME\",\"args\":$2,\"result\":$3}" Send to local syslog or central SIEM logger -t -code-audit "$LOG_ENTRY" Also write to local rotated log echo "$LOG_ENTRY" >> /var/log/-code/tool-calls.jsonl -
Set up log rotation (Linux – logrotate
/etc/logrotate.d/-code):/var/log/-code/.log { daily rotate 30 compress missingok notifempty create 640 } -
Integrate with a SIEM – forward logs to Splunk, ELK, or AWS CloudWatch for real-time alerts on anomalies (e.g., 100+ file reads in 1 minute).
5. Windows Event Log integration using PowerShell:
$logEntry = "{timestamp='$(Get-Date -Format o)', tool='$toolName'}"
Write-EventLog -LogName "Application" -Source "Code" -EntryType Information -EventId 1000 -Message $logEntry
- Explicit MCP Trust Model: Allowlist Everything Else Blocked
Many setups implicitly trust all MCP servers. You must move to an explicit allowlist model.
Step-by-step guide:
1. Define `.mcp.json` with no wildcard permissions:
{
"trust_model": "explicit_allowlist",
"allowed_mcp_servers": [
"postgres",
"filesystem",
"github"
],
"permissions": {
"postgres": { "allowed_queries": ["SELECT", "SHOW", "EXPLAIN"] },
"filesystem": { "allowed_paths": ["./src", "./data", "./scripts"] },
"github": { "allowed_actions": ["read:repo", "list:issues"] }
},
"blocked_tools": ["execute_command:rm -rf", "execute_command:chmod 777"]
}
- Verify that any unlisted MCP server is rejected – Code should error with “unknown MCP server”.
-
Use signed MCP manifests for production (if supported) to prevent tampering.
7. Additional Hardening: Network Limits and Nono Sandbox
For high-security environments, combine filesystem sandboxing with network restrictions.
Step-by-step guide:
- Run Code inside a Docker container with network disabled or limited:
docker run --rm -it \ --network none \ --read-only \ --tmpfs /tmp:rw,noexec,nosuid,size=64m \ -v "$PWD":/workspace:ro \ -v -cache:/home//.cache \ -code:latest
2. Use Nono sandbox (Linux) to limit syscalls:
nonono --allow-read "$PWD" --allow-write "$PWD" --deny-network -- -code
- Implement egress firewall rules to allow Code to talk only to required APIs (e.g., Anthropic API endpoint, your internal MCP services) and block everything else using `iptables` or Windows Firewall.
What Undercode Say:
- AI agents are production infrastructure – treat `./` with the same rigor as a Kubernetes pod security context. Default permissions = incident waiting to happen.
- Defense in depth wins – combine Git hooks, filesystem scoping, read-only DB roles, and comprehensive logging. No single control is sufficient.
The post highlights a critical blind spot: developers adopt AI coding tools for productivity but ignore the blast radius. Code can rm -rf, post your `.aws/credentials` to a public gist, or run a fork bomb – all because “it’s just pair programming.” The security community must shift from trusting AI outputs to distrusting AI actions. Implementing PreToolUse hooks with gitleaks, least-privilege filesystem roots, and read-only database roles isn’t optional – it’s baseline. The reality is that most breaches involving AI agents will come not from model vulnerabilities, but from overly permissive configurations that developers copy from blog posts without understanding the risk.
Prediction:
Within 18 months, major breach reports will explicitly cite misconfigured AI coding agents as the initial access vector or data exfiltration path. Regulators will begin requiring explicit “AI agent activity logs” as part of compliance frameworks (SOC2, ISO 27001). We will see the emergence of “AI Agent Security Posture Management” (AISPM) tools that scan ./, .cursor/, and `.copilot/` directories for violations of least privilege – similar to CSPM for cloud infrastructure. Organizations that fail to lock down these agents will face incidents that dwarf the SolarWinds supply chain attack in scale, because every developer becomes a potential autonomous threat actor. The only mitigation is to treat every AI tool call as if it were a root-level command from an untrusted user – because, effectively, it is.
▶️ Related Video (76% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Yildizokan Aisecurity – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
