AI coding agents need security gates before they touch production

AI coding agents are moving from helpful side tools into the delivery path.

That shift showed up clearly on X this week. Developers were comparing Claude Code, Cursor, Codex, and multi-agent worktree setups. Others were sharing prompts that force agents to run OSV checks, gitleaks, SBOM generation, and security scans before shipping. The thread underneath all of it was simple: these tools are becoming useful enough to touch real code, so the risk model has changed.

For founders and CTOs, the lesson is not that AI coding agents are unsafe.

The lesson is that a coding agent is now a technical actor with access.

If it can read a repository, run shell commands, install packages, inspect logs, modify configuration, or open pull requests, then it needs the same kind of delivery control you would expect around any powerful automation.

Speed is useful. Ungated speed is a production risk.

Agent speed changes the risk model

Classic AI-assisted coding was usually bounded by a human copy-and-paste step. A developer asked for a function, reviewed the answer, adapted it, and committed manually.

Agentic coding is different.

An agent can plan a task, edit several files, run tests, install dependencies, call tools, fix lint errors, and continue until it thinks the work is done. In more advanced setups, several agents can work in parallel branches or git worktrees while another process reviews CI failures.

That is a meaningful productivity jump.

It also means mistakes can travel further before a human notices.

The risks are not theoretical:

• a secret is read, logged, or copied into an unsafe context;
• a dependency with known vulnerabilities is added because it solved the immediate task;
• a shell command runs with broader filesystem or network access than the task requires;
• generated code bypasses an architectural boundary because the agent optimized locally;
• tests pass, but the change quietly weakens authorization, tenancy, or data handling;
• multiple agent branches create review fatigue and architecture drift;
• nobody can later explain which prompt, tool call, or command produced a risky change.

These are normal software delivery risks, amplified by autonomy.

The answer is not to ban the tools. The answer is to put production gates around them.

A practical gate model

Security gates work best when they are specific, automated where possible, and tied to the seriousness of the change.

For AI coding agents, the useful model is layered.

1. Runtime isolation

The first gate is where the agent is allowed to operate.

An agent should run in an isolated workspace with clear filesystem boundaries, limited network access where possible, and no default path to production credentials. Worktrees, containers, ephemeral environments, and sandboxed shells are not bureaucracy. They reduce the blast radius of a mistaken command or over-eager tool call.

For serious teams, the question is not “Can the agent run commands?”

The question is “Which commands can it run, in which environment, with which data, and with which audit trail?“

2. Least-privilege credentials

Agents should not inherit a developer’s full local environment.

That includes cloud tokens, database URLs, SaaS API keys, Git credentials, production .env files, and access to customer data. If an agent needs credentials, they should be scoped to the task, time-limited where possible, and safe to revoke.

The same applies to tool integrations. MCP servers, log systems, ticketing tools, observability dashboards, and internal APIs can be useful context. They can also expose sensitive operational data. Connect only what the task needs.

3. Secrets scanning before review

Every agent-produced change should pass secrets scanning before a human reviewer spends time on it.

Tools such as gitleaks, trufflehog, or platform-native secret scanning can catch obvious mistakes early. The important point is not the specific scanner. The important point is that secret detection is automatic, repeatable, and blocks the path forward.

If the team is relying on a reviewer to notice a leaked key in a large AI-generated diff, the process is already too weak.

4. Dependency and vulnerability checks

Agents are very good at finding a package that solves the immediate problem.

They are not automatically good at judging whether that package belongs in a production system.

Before agent-generated code ships, dependency changes should trigger vulnerability and license checks. OSV, npm audit, pnpm audit, GitHub dependency review, Snyk, or similar tooling can all be part of the gate. The team should also ask whether the dependency is necessary, maintained, and aligned with the architecture.

The fastest package is not always the cheapest package.

5. SBOM and supply-chain visibility

If AI agents are accelerating dependency changes, the company needs better inventory.

A software bill of materials is not only an enterprise compliance artifact. It is a way to know what the product contains when a vulnerability lands, when a customer asks for assurance, or when an acquisition or security review requires evidence.

For agentic delivery, SBOM generation should sit close to build and release workflows, not as a once-a-year exercise.

6. Tests and CI as a hard gate

Agent output should not bypass the ordinary engineering bar.

Unit tests, integration tests, type checks, linting, build checks, migration checks, and end-to-end tests still matter. In fact, they matter more because agents can produce plausible code quickly.

The test suite becomes the contract that tells the agent where the boundaries are.

If the product has weak tests, adopting coding agents should start with strengthening the delivery harness. Otherwise the team is multiplying code output without multiplying confidence.

7. Human architecture review

Automation can catch secrets, dependencies, syntax errors, and many regressions.

It cannot fully decide whether a change belongs in the system.

That is still an architecture question.

Before agent-generated work reaches production, a senior human should review changes that affect boundaries: authentication, authorization, data models, tenancy, billing, infrastructure, migrations, background jobs, public APIs, and operational recovery paths.

The review should ask:

• Does this change respect the existing architecture?
• Did the agent solve the local task by creating a wider system problem?
• Are new responsibilities in the right module or service?
• Is the change observable and reversible?
• Would we still be comfortable owning this code six months from now?

That review is not anti-AI. It is what makes AI useful in serious delivery.

8. Audit trail

When an agent changes production-bound code, the team should be able to reconstruct what happened.

At minimum, keep the issue or task, prompt or instruction summary, agent branch, tool permissions, commands run, CI results, reviewer, and final approval connected to the pull request or release artifact.

This matters for debugging. It matters for security incidents. It matters for compliance. It also matters for improving the workflow over time.

If the process cannot explain how a change happened, it is not ready to scale.

What founders and CTOs should ask

You do not need to become an AI tooling specialist to manage this well.

You do need to ask sharper questions.

Ask internal teams or vendors:

• Where do AI coding agents run?
• Which files, tools, networks, and credentials can they access?
• Can they see production data or secrets?
• Which scans are mandatory before review?
• What happens when an agent adds or updates a dependency?
• Are SBOMs generated as part of release?
• Which changes require senior architecture review?
• Can we trace agent-produced work from task to commit to deployment?
• How do we stop an agent from repeatedly making the same architectural mistake?

The answers do not need to be complicated. They do need to be real.

How we think about it at McDougall Digital

AI can make product delivery faster. Used well, it can also make teams more disciplined because it forces clearer tasks, stronger tests, better documentation, and more explicit boundaries.

But AI does not remove the need for engineering judgement.

For client work, the useful standard is not “Did the agent finish the task?”

The useful standard is:

Can this change be understood, reviewed, tested, operated, and safely owned?

That is the difference between AI-assisted output and production software.

Coding agents belong in modern delivery workflows. They just need to pass through the same gates as anything else that touches production.