What your AI agent can see in your project — and why you should check first

ENTET — Sat, 22 Aug 2026 14:24:02 +0000

When you start an AI coding agent — Claude Code, Cursor, Codex, JetBrains AI, or anything wired up over MCP — you're handing it your workspace. Not a curated slice of it. The workspace. And most of us don't stop to think about what's actually in there.

That's worth a minute of thought, so here's a tour of what tends to be in scope, and a small tool I built to check it.

What's actually readable

Environment files. .env, .env.local, and friends are the classic one. They're git-ignored, so they don't show up in PR diffs — which is exactly why people forget they exist. An agent reading your project root reads them fine. And agents have a specific failure mode here: GitGuardian's State of Secrets Sprawl 2026 report found that Claude Code co-authored commits leaked secrets at a 3.2% rate, versus a 1.5% baseline across all public GitHub commits — roughly 2x. The mechanism is mundane: context windows often pull in .env files, and those values then resurface in generated commits.

MCP server configs. If you're using MCP, the config that wires up your servers describes what those servers can do — sometimes with credentials or broad filesystem/command access baked in. A misconfigured server is a quietly large amount of trust. And this isn't hypothetical: GitGuardian found 24,008 unique secrets sitting in MCP configuration files on public GitHub — a file category that essentially didn't exist a year earlier — with 2,117 of them confirmed as live, valid credentials.

CI/CD workflows. Your .github/workflows/*.yml files are code too. Dangerous patterns — pull_request_target with checkout of untrusted code, secrets piped into shell steps, unpinned third-party actions — are easy to copy-paste and hard to eyeball.

package.json scripts. postinstall, prepare, and other lifecycle scripts run automatically. If an agent (or you) runs npm install, those execute.

Automation webhooks. If you've got n8n or similar in the repo, webhook definitions can expose endpoints or embed tokens.

None of this is exotic. It's just the normal contents of a normal repo. The issue is that "normal repo" and "safe to expose to an autonomous agent that can read and run things" are not the same statement, and we tend to treat them as if they are.

The handoff is the moment that matters

Plenty of security tooling exists — secret scanners, SAST, dependency auditors. They're good. But they're mostly built around commit and CI time. The AI-agent era introduces a different moment: the handoff, when you point an agent at your local working tree and say "go." That tree includes uncommitted files, git-ignored secrets, and local config that never reaches CI.

The scale is worth a glance. GitGuardian's 2026 report counted 28.6 million new hardcoded secrets added to public GitHub in 2025 — a 34% jump year over year — with AI-service credential leaks specifically growing 81%. Existing tooling catches most of these after the fact. The handoff happens earlier, on your local tree.

That's the gap I wanted to close.

A pre-flight check

I built a JetBrains plugin called AI Agent Workspace Guard. It runs a static scan of your project before you hand it to an agent, and flags:

Secrets in tracked files
Risky MCP server configs
Agent permission settings (auto-approved MCP servers, unbounded grants, HTTP hooks)
Dangerous GitHub Actions workflows
package.json script risks
n8n webhook issues

A few things I want to be straight about:

It's static heuristics, not a guarantee. It matches known-risky patterns. It will miss things, and a clean scan does not mean your project is safe to expose.
It runs 100% locally. No API key, no telemetry, no external calls. A tool about not over-trusting your tools shouldn't itself phone home — so it doesn't.
It's not an AI assistant. It doesn't write or review your code. It's the step before that.

It's $4.90 for individuals, $9.90 for business, as a one-time perpetual license, with a 30-day free trial — long enough to run it against your real repos and decide if it earns a spot in your workflow.

https://plugins.jetbrains.com/plugin/32116-ai-agent-workspace-guard

There's also a free CLI companion (npx @entet/ai-agent-guard) that runs the same core checks from the terminal and drops into CI.

The takeaway, even without the plugin

You don't need my tool to take the lesson: before you hand a repo to an agent, spend thirty seconds asking what's in it. Check your env files. Look at your MCP config. Skim your workflows and your install scripts. The agent is going to. You might as well go first.

DEV Community: ENTET

What your AI agent can see in your project — and why you should check first

What's actually readable

The handoff is the moment that matters

A pre-flight check

The takeaway, even without the plugin