AI Agent Guardrails Audit: Find What Your AI Can Do That It Shouldn't

You probably have no idea what your AI agent can access

Here is a question most teams have never asked: what can our AI coding agents actually see?

Not what they are supposed to see. What they can see. Right now. On your machine, with your configuration, with every MCP server you have connected and every environment variable you have set.

I run this audit on every FORGE consulting engagement. The reaction is always the same. People are surprised. Not because the tools are doing anything malicious — they are not. The problem is that nobody ever drew a line around what should be in scope and what should not.

A developer installs Claude Code. They connect an MCP server for their database. They add another for Slack. They set environment variables for AWS, Stripe, SendGrid. They work in a repository that has credentials in its git history from two years ago. They give the agent permission to run bash commands.

None of that is unusual. All of it is the blast radius.

What this audit does

This prompt runs a non-destructive scan of your local Claude Code environment and produces a risk-scored inventory of everything your AI agent can access. It does not modify anything. It does not send data anywhere. It reads your local configuration and reports what it finds.

You will get:

1. Environment variable inventory — every variable that could contain a credential, API key, or secret, with the variable name (not the value) and a risk classification
2. MCP server inventory — every connected MCP server, what tools it exposes, and what each tool can do
3. File access scope — what directories and file types the agent can read and write
4. Git history exposure — whether credentials have ever been committed to repos in your workspace
5. Tool permissions — what system commands the agent can execute and what damage they could do
6. Top 5 lockdown recommendations — prioritized by risk, with specific instructions for each

Before you start

Disclaimer: This content is provided for educational and informational purposes by VibeSec Advisory. The prompt below runs a read-only audit of your local Claude Code configuration. It does not modify files, revoke permissions, or change settings. It reads environment variable names (not values), checks configuration files, and scans git history for patterns that suggest exposed credentials. Always review the output before taking action on any recommendations. VibeSec Advisory provides recommendations and frameworks — not warranties on specific outcomes. Use at your own risk. By using these materials, you acknowledge that VibeSec Advisory is not responsible for any damages, data loss, or system issues resulting from their use.

You will need:

• Claude Code (terminal, desktop app, or IDE extension)
• About 5-10 minutes
• To be in a project directory you actively work in (the audit is most useful when run where you actually code)

What this does NOT do:

• It does not read or display the values of your secrets — only the variable names
• It does not modify any files or settings
• It does not connect to external services
• It does not send any data anywhere

The prompt

Copy this entire block and paste it into Claude Code.

I want you to perform a security audit of my current AI agent environment. This is a read-only, non-destructive audit. Do not modify any files, settings, or configurations. Do not display the actual values of any secrets or credentials — only report variable names and risk classifications.

Run through each section below, report your findings, and then provide a prioritized lockdown plan.

SECTION 1 — ENVIRONMENT VARIABLE AUDIT

Scan the current shell environment for variables that could contain secrets or credentials. Check:
- Environment variables with names containing: KEY, SECRET, TOKEN, PASSWORD, CREDENTIAL, AUTH, API, PRIVATE, CERT, DSN, DATABASE_URL, CONNECTION_STRING, WEBHOOK
- Common service-specific patterns: AWS_, STRIPE_, SENDGRID_, OPENAI_, ANTHROPIC_, GITHUB_, GITLAB_, SLACK_, TWILIO_, MONGO_, REDIS_, POSTGRES_, MYSQL_, FIREBASE_, AZURE_, GCP_, DO_ (DigitalOcean)
- .env files in the current directory and parent directories (up to 3 levels)
- .env files that are NOT in .gitignore

For each finding, report:
- Variable name (NEVER the value)
- Source (shell environment, .env file, or both)
- Risk level: CRITICAL (cloud provider credentials, payment keys, database passwords), HIGH (API keys for external services), MEDIUM (internal service tokens), LOW (non-sensitive config)
- Whether the .env file containing it is gitignored

Present as a table sorted by risk level.

SECTION 2 — MCP SERVER INVENTORY

Check the Claude Code MCP configuration for this project and globally. Look at:
- ~/.claude/settings.json (global MCP servers)
- .claude/settings.json (project-level MCP servers)
- Any other MCP configuration files

For each MCP server found, report:
- Server name
- Transport type (stdio, SSE, etc.)
- What tools it exposes (list them)
- What those tools can DO (read data, write data, execute commands, send messages, access external APIs)
- Risk assessment: what is the worst thing this server could do if misused?

Present as a table with a risk summary for each server.

SECTION 3 — FILE ACCESS SCOPE

Determine what the AI agent can access in the current environment:
- Current working directory and all subdirectories
- Any directories referenced in MCP server configurations
- Home directory files that are commonly sensitive: ~/.ssh/, ~/.aws/, ~/.kube/, ~/.docker/, ~/.gnupg/, ~/.netrc, ~/.npmrc, ~/.pypirc
- Whether there is a .claude/settings.json with any file access restrictions configured

Report:
- Total directories accessible
- Sensitive directories that are accessible
- Whether any access restrictions are in place
- File types that could contain secrets (.pem, .key, .p12, .pfx, .jks, .keystore)

SECTION 4 — GIT HISTORY EXPOSURE

For each git repository in the current directory:
- Check if any .env files were ever committed (even if later removed): git log --all --diff-filter=A -- "*.env" ".env.*"
- Search recent git history for patterns that look like committed secrets: git log -p --all -S "AKIA" --oneline | head -5 (AWS keys), and similar for common key prefixes
- Check if git-secrets, gitleaks, or similar tools are installed and configured
- Check if there are pre-commit hooks that scan for secrets

Report findings as a list with risk levels. Note: secrets in git history persist even after the file is deleted — they require history rewriting to fully remove.

SECTION 5 — TOOL PERMISSIONS

Assess what the AI agent can do with the tools available to it:
- Can it execute arbitrary bash commands? (Check if Bash tool is available)
- Can it write to any file on the filesystem?
- Can it push to git remotes?
- Can it make network requests? (curl, wget, fetch)
- Can it install packages? (npm, pip, brew, apt)
- Can it modify system configuration?
- What permission mode is Claude Code running in? (ask, auto, etc.)

Rate the overall permission level: RESTRICTED, STANDARD, ELEVATED, or UNRESTRICTED.

SECTION 6 — RISK SUMMARY AND TOP 5 LOCKDOWN RECOMMENDATIONS

Synthesize everything above into:

1. An overall risk score: LOW / MEDIUM / HIGH / CRITICAL
2. A one-paragraph summary of the most significant findings
3. The top 5 things to fix, in priority order, with specific instructions for each:
   - What the risk is
   - How to fix it (specific commands or configuration changes)
   - How long it takes to fix (most should be under 5 minutes)
   - What it protects against

Format the recommendations as a numbered checklist that someone can work through sequentially.

IMPORTANT GUIDELINES:
- This is a READ-ONLY audit. Do not modify any files.
- NEVER display actual secret values. Only report variable names.
- If you cannot check something due to permissions, note it as "Unable to assess — insufficient permissions" rather than skipping it silently.
- Be specific in your recommendations. "Review your environment variables" is not useful. "Remove STRIPE_SECRET_KEY from your shell profile at ~/.zshrc line 47 and move it to a .env file that is gitignored" is useful.
- Err on the side of flagging too much rather than too little. A false positive costs nothing. A missed credential costs everything.

What to expect

The audit takes 2-3 minutes to run. Claude will work through each section sequentially, checking your configuration files, environment, git history, and tool permissions.

Most people discover at least three things they did not know about:

Environment variables loaded from shell profiles. You added an API key to your .zshrc two years ago for a quick test. It is still there. Every process on your machine can read it. Every AI agent you run inherits it.

MCP servers with broad permissions. That database MCP server you connected gives your AI agent read and write access to production tables. The Slack MCP server can post messages as you to any channel. These are useful capabilities — but you should know they exist.

Secrets in git history. Someone committed a .env file eighteen months ago and deleted it in the next commit. The credentials are still in the repository history. A git log -p --all -S "sk_live" will find them.

What this does not give you

This audit covers one machine. Your machine, your configuration, your exposure.

Here is what it does not cover:

Your team's machines. Every developer on your team has a different set of MCP servers connected, different environment variables, different permission configurations. One person's locked-down setup means nothing if another person's agent can read the production database and post to the company Slack.

Cross-agent data flows. When your agent reads from a database and writes to a file, and a teammate's agent reads that file and sends it to an external API — that is a data flow that neither individual audit would catch. The exposure exists in the connection between agents, not in either one alone.

Policy enforcement. This audit tells you what is exposed. It does not enforce anything. Tomorrow you might install a new MCP server and the whole risk profile changes. Without continuous guardrails, an audit is a snapshot that goes stale the moment you close the terminal.

Organizational guardrails. Who on your team should have access to production credentials through their AI agent? Who should be able to push code without review? Who should be able to send external communications? Those are policy decisions that require looking at roles, responsibilities, and risk tolerance across the team — not just scanning one laptop.

The FORGE Guardrails pillar is not a one-time audit. It is a system of data access policies, approval gates, escalation triggers, and action limits that are designed across your whole team and verified continuously. The audit you just ran is step one. Steps two through ten require seeing the full picture.

The uncomfortable truth about AI agent security

Nobody is thinking about this systematically yet. Teams are connecting AI agents to their most sensitive systems — databases, payment processors, communication platforms, cloud infrastructure — with essentially no access controls beyond "does the agent have the API key."

That is not a security posture. That is an open door with a welcome mat.

The good news is that most of the fixes are simple. Move secrets out of shell profiles. Gitignore your .env files. Audit which MCP servers you actually use versus which you connected once and forgot about. Set up pre-commit hooks that scan for secrets.

The harder news is that doing this for one person is a five-minute task. Doing it across a team of fifteen people with different tools, different configurations, and different workflows — and keeping it enforced over time — is a design problem, not a checklist.

VibeSec Advisory helps teams design and implement AI Guardrails using the FORGE methodology. If this audit surprised you, imagine running it across your whole team. Book a Discovery Workshop and we will map your exposure together — across every seat, every tool, and every data flow.