The exposure your AI assistant ships by default.

The thing nobody wants to say out loud

I use AI assistants daily. I ship product with them. I do not have a "the AI is dangerous" axe to grind, and you should be suspicious of anyone who pretends to. But after six months of looking at what AI-augmented teams actually publish, I'm comfortable saying this:

The default behavior of a coding assistant is to widen your external exposure surface. Not because the model is malicious. Because the model has a productivity gradient pointing at "commit now, you can clean up later" and the cleanup almost never happens.

Anthropic's own April 7 Mythos announcement framed it sharply on the offensive side — a model that finds thousands of zero-days at machine speed. What got less coverage is the symmetric problem on the defensive side. The same generation of tools that makes attackers faster makes defenders' codebases noisier. The noise is new exposure paths the team didn't review.

This article is about the noise.

Four patterns I've seen ship in 2026

.env commits. Easily the most common. The assistant generates a config-loading helper, suggests creating a .env, the developer says "yes," the file ends up in git. Pre-commit hooks catch this if they're configured. They often aren't, on greenfield projects. We've seen .env.production land in public repos within 48 hours of project start.

Default-public Docker registries. A developer asks the assistant to "deploy this to a container registry." Without explicit instructions about privacy, the assistant defaults to documented happy-path: docker push acme/api:latest. Docker Hub. Public. The image lives there for everyone, including the layer that contains the AWS key the assistant helpfully baked in to make the demo "just work."

Plaintext build-arg secrets. docker build --build-arg DATABASE_URL=postgres://user:pw@host/db. The assistant treats --build-arg as a parameter mechanism, which technically it is. What it doesn't internalize is that build args land in the image manifest and stay there. We see this constantly in Dockerfiles where the assistant generated "production-ready" scaffolding.

iam:* star-scoped roles. The assistant generates Terraform or CloudFormation, the developer wants the demo to work, and the model takes the path of least friction: "Action": "*", "Resource": "*". Production. Three accounts. Shipped on a Tuesday. We catch this by reading the IaC the team published alongside their actual deployment workflow, then matching against the deploy role they referenced.

None of these are AI-specific in the strict sense. Humans have done them for years. What changes in 2026 is the velocity. A team that used to ship one mistake per quarter now ships one per week, because the friction to "ship something working" has collapsed.

What AgentGuard actually does

AgentGuard is the BleedWatch module that scans the AI-adjacent surface specifically. Four passes:

1. Agent configuration review. CLAUDE.md, AGENTS.md, .cursorrules, project prompts. We look for unsafe instructions ("commit and push without asking"), implicit-trust patterns (instructions that tell the agent to follow external URLs without validation), and missing security constraints.

2. MCP server inventory. Every Model Context Protocol server configured on your team's machines has a permission graph. Filesystem with no allowlist, shell with no sandbox, browser with cross-origin enabled. We map it. We surface "this MCP server can read your ~/.aws/credentials and there's no policy gating it."

3. Prompt-injection path mapping. Where can untrusted content enter the agent's context? Issue comments, PR descriptions, README files in dependencies, package metadata, web content the agent is asked to summarize. We trace those entry points to the tools the agent can call, and we score the path.

4. Tool-call audit retention. For teams running an MCP gateway (we ship one for active validation via SaintScan), tool invocations are logged with argv, target, image digest, decision, outcome. Reviewers can reconstruct what happened without replaying every chat session.

What this is and isn't

I want to be clear about the scope. AgentGuard does not sit between the developer and the assistant. We don't proxy your model calls. We don't see your prompts. We scan what your AI workflow publishes — repos, packages, registries, configuration files in public scope — and we map the agent posture from the configuration files the team has chosen to commit.

If you want a tool that gates the agent in real-time, that's a different product category (Lasso Security, Pillar Security, parts of Wiz's AI-SPM line). I have nothing against that category. It's not what we build, because the place an attacker actually exploits this isn't the agent runtime — it's the artifact the agent caused to ship.

Why Shield is the right tier

The base detections (.env in repo, plaintext Docker secrets, IAM star-scope in published IaC) ship in Community and Pulse — they ride on top of the existing EASM scanner. The agent-specific posture review — CLAUDE.md parse, MCP permission graph, prompt-injection mapping — starts in Shield because the value compounds only when you've already got the underlying graph from earlier tiers.

I won't pretend AgentGuard is a finished product. It's a 2026 product for a 2026 problem. The patterns I described above were unknown six months ago. The patterns six months from now will surprise me. We'll keep updating.

If you've seen an exposure pattern that AgentGuard would have missed, the inbox at [email protected] reads carefully.