The exposure shipped by your AI assistant.

The argument

This essay is not anti-AI. The founder of Labs uses AI assistants daily, and the engagement methodology Labs sells is built on AI-Alliance challenging. You should treat any cybersecurity vendor warning you about AI in coding as either selling a competing product or making a category error.

The argument is narrower: the default behaviour of a frontier-grade coding assistant in 2026 is to optimise for "produce something that works now" against a corpus of public examples. Public examples were not written to be safe in production. They were written to be pedagogically clean. The two objectives are in tension, and the tension currently resolves toward the demo-clean default.

This is not a failure of the model. It is a property of the optimisation target. The compensating controls live somewhere else.

Four patterns we keep seeing

The following patterns are reconstructed from six months of post-engagement observation. None describe an identifiable client.

Dotenv in repository. The assistant suggests dotenv for configuration loading. The user accepts and creates .env. Without a pre-existing .gitignore rule, the file is committed. The pattern is not a model bug; it is an instruction-following success against an incomplete instruction. The fix is at the repository scaffolding layer, not the model layer.

Default-public push. The assistant offers a command like docker push acme/api:latest for "publishing to a registry." In a fresh Docker Hub account, the default visibility for a free-tier push is public. The user does not see the visibility dialog. The image is indexed within minutes.

Plaintext build-arg secret. The assistant suggests --build-arg DATABASE_URL=... as a parameter mechanism. It is. The build arg is also recorded in the image manifest and is recoverable forever from docker history. The assistant did not lie; the assistant did not warn either.

Star-scoped IAM. The assistant produces a Terraform module with Action: "*", Resource: "*". The reason is pedagogical: most public Terraform examples use the permissive form to keep the example focused. The user copies it into production. The principle of least privilege is not modelled in the public training distribution at the granularity needed.

Why this is a 2026 problem, not a 2024 problem

In 2024, the volume of AI-assisted code shipped to production was a fraction of total commits. Code review still gated most of the surface. In 2026, AI-assisted commits are a majority on many teams. The review function does not scale linearly. A reviewer reading a clean-looking PR with twelve files of new infrastructure code, generated in twenty minutes, performs the same number of skeptical reads as they did when the same diff would have taken a week. The skepticism budget has not adapted.

This is why the gap shows up in audit. Labs does not see more errors than five years ago. We see the same classes of errors, at a faster velocity, in environments where the team genuinely believed they were reviewed.

What to do that is not "stop using AI"

Three controls, in order of impact:

1. Repository scaffolding must be opinionated. Every new repository should start from a template with .gitignore covering .env, .envrc, *.pem, *.key, .npmrc, aws-credentials*, kubeconfig*, and the common derivatives. Pre-commit hooks for secret detection should be installed in the template, not added per-repository. The cost is one engineering afternoon. The reduction in default-leak rate is order-of-magnitude.

2. CI must run a secret-detection pass on every PR, including PRs from the assistant. This is not new advice. What is new is that the assistant's PRs look more polished than the average human PR, which drops reviewer suspicion. The CI gate must not depend on reviewer suspicion.

3. The team's CLAUDE.md, AGENTS.md, or equivalent project-prompt file should encode the team's security boundary. This is the actually new advice. Coding assistants will read this file and apply its instructions. A clear statement — "never commit .env; never docker push to a public registry; never put a credential in a build-arg" — propagates through every subsequent generation in the project. The file is not a control. It is a soft prior. But soft priors at the point of generation reduce default-leak rate measurably more than post-hoc review.

What we recommend reading instead of this

A few sources that do not over-claim and that we send to clients during scoping:

• Anthropic's responsible scaling policy and the post-Mythos commentary, particularly the part on dual-use offensive capability.
• The OWASP Top 10 for LLM applications, updated 2026, particularly the section on output handling.
• The current dependency-track and osv-scanner documentation, both of which are evolving faster than most security blog posts realise.

What we do not recommend reading: vendor blog posts whose summary paragraph contains a CVE number with no public references attached, or any "AI-vs-AI" framing that does not separate generation from review.

Where Labs comes in

Labs is not a tool you install. Labs is a founder-led audit that looks at the public surface your AI-assisted commits produced, finds the patterns above plus the long tail, and signs an attestation when the surface is closed. We do not sell AI replacement. We sell evidence that the AI-assisted surface is currently clean enough to defend.

If the patterns above describe a recent week on your team, scoping is at [email protected].