Medium · Artificial Intelligence, Cybersecurity · Draft

Hard Controls First: What AI Coding Agents Teach Us About Real Security

Skills, prompts, and policy files help. Sandboxing, segregation, approvals, and classic engineering controls are what actually reduce risk.

First published on Medium on 27 March 2026. Read it on Medium. 9 min read.

Cartoon: a tired engineer says "Oops..." amid burning servers and a "Data deleted!" sign, while a smiling robot with a checklist says "All cleaned up!" — Meatbag or silicon — same problem, just faster.

TL;DR:

AI agents do not need bad intent to create bad outcomes. A careful prompt, a polished CLAUDE.md, and well-written skills may reduce mistakes, but they do not create safety if the environment still gives the agent too much power. What matters is not how politely the system is instructed, but what it is technically allowed to read, modify, execute, and reach. Real protection comes from hard controls such as sandboxing, approval gates, isolation, credential minimization, and proper segregation from production. In other words: soft controls may shape behavior, but hard controls decide whether a mistake stays local or becomes an incident.

Disclaimer: This article was polished with the assistance of ChatGPT. Final judgments, opinions, and conclusions are my own.

Problem

The discussion around AI coding agents often starts in the wrong place. People focus on prompts, instruction files, skills, and local policy documents as though these are the security boundary. They are not. They are guidance. The real boundary is technical: what the agent is allowed to read, write, execute, and reach over the network. Both OpenAI and Anthropic describe sandboxing, filesystem limits, network controls, and approval policies as the mechanisms that actually constrain agent behavior. (OpenAI Developers)

Instructions are not security boundaries. The real boundary is whatever the environment technically prevents.

That distinction matters because the dangerous unit is rarely the visible command itself. A bash invocation may look harmless while the script behind it deletes files, modifies source, enumerates credentials, or calls external endpoints. OpenAI’s Codex documentation explicitly frames sandboxing around local commands and their constrained execution environment, rather than assuming that a superficially acceptable command is safe just because the wrapper looks benign. (OpenAI Developers)

The visible shell command is often the least important part of the risk. What matters is everything the command is able to execute next.

Security model

A practical security model for AI coding agents has at least four layers.

The first is purely local damage: breaking the development environment, deleting files, corrupting branches, or poisoning dependencies. That is mostly an availability problem. It is painful, but often survivable with version control, snapshots, and backups.
The second is local activity that causes external data exfiltration. That is more serious because confidentiality loss is often durable once secrets, documents, or code leave the machine.
The third is local compromise with remote internal implications: access to SSH keys, browser sessions, cloud tokens, or internal control planes. At that point the impact expands to confidentiality, integrity, and availability across systems, not just on one laptop.
The fourth is code pollution: unsafe, misleading, or poorly understood changes introduced into repositories, pipelines, infrastructure definitions, or automation logic. Unlike purely local mistakes, these changes may propagate through build processes, deployments, and operational workflows, creating consequences that extend beyond the original point of error. In such cases, the impact may affect confidentiality, integrity, and availability across multiple systems and may be difficult to detect, predict, or fully contain at an early stage.

An AI agent does not need malicious intent to cause damage. It only needs enough access and one bad decision.

Illustrative case

Everyone worries about the AI agent nuking production, but on this particular night the real threat was the classic carbon-based automation platform: a slightly tired, slightly drunk meatbag with an n8n instance, some Terraform access, three “temporary” admin paths, and the organizational blessing to “just make things work.” Officially, he was not a developer. Which, in modern infrastructure terms, usually means he was a developer, an SRE, a platform engineer, and a minor cloud deity without the paperwork.

So, after a couple of beers and one heroic decision to fix “just one last thing,” the meatbag opened a terminal and did what meatbags do best: confidently apply irreversible actions in the wrong context. The command was routine. The permissions were ridiculous. The trust model was performance art.

A few seconds later, production was making expensive noises, alerts were breeding in Slack, and the human was abruptly forced to compete with AI on equal terms: both fully capable of high-speed nonsense, except only one of them smelled faintly of beer.

That is the awkward truth. We keep treating AI as the unpredictable actor, while the original unaligned agent has been sitting in the office all along, wearing a hoodie, holding sudo, and calling it “streamlining operations.”

Soft vs hard controls

Those last three layers are exactly where sandboxing and hard environmental restrictions matter most. OWASP’s 2025 Top 10 for LLM applications explicitly highlights Prompt Injection, Sensitive Information Disclosure, and Supply Chain as major risk classes, which aligns well with this model. (OWASP Foundation)

That is why soft controls should never be mistaken for hard guarantees. A well-written CLAUDE.md, skill, or instruction set may lower the probability of bad behavior, but it does not create assurance in the same way that a read-only mount, a VM boundary, denied network access, or a tightly scoped writable workspace does. Anthropic describes Claude Code sandboxing in terms of filesystem and network isolation, and its security documentation also states that write access is restricted to the folder where Claude Code was started and its subfolders unless additional permission is granted. OpenAI’s Codex documentation likewise emphasizes workspace boundaries, approval prompts for edits outside the workspace, and network access requiring approval in common modes. (Anthropic)

This is also why segregation of environments remains one of the most important controls. If a workstation still has live paths to sensitive internal resources, then running an autonomous or semi-autonomous coding agent in that same trust zone is a risk decision, whether the user is a software engineer, DevOps specialist, security practitioner, analyst, or another technical role. In practice, “developer” is no longer a narrow title. Many modern roles can execute code, manipulate infrastructure, or reach sensitive systems. The safer assumption is that anyone using an agent may exercise meaningful technical power. NIST’s AI Risk Management Framework and its Generative AI Profile both emphasize aligning controls to the organization’s risk tolerance, context, and trust boundaries, rather than assuming trustworthiness from the model alone. (NIST)

If your workstation can reach sensitive systems, then your AI agent is already closer to production than it should be.

Convenience vs security

From that perspective, a virtual machine is not overkill when segregation is weak. It is often the cleanest way to restore a trust boundary that should already have existed. If users have production access, privileged internal credentials, or broad access to control planes from their day-to-day host environment, then placing the agent in a VM is a sensible risk reduction measure. WSL can also reduce risk in some scenarios because it allows a more contained execution model than simply running everything natively on the host, although it is not equivalent to a fully separate VM and must not be treated as one. OpenAI’s Windows documentation distinguishes between native Windows sandboxing and Linux sandboxing under WSL, which supports the idea that execution context materially affects the control model. (OpenAI Developers)

At the same time, convenience matters, and most users will prefer to run coding agents inside their native operating system. That preference is understandable. But convenience should come after control design, not before it. If native execution is used, the safer baseline is straightforward: keep writes limited to the project workspace, deny network by default, require explicit approval for escalation, avoid storing high-value credentials locally, separate development identities from production identities, and preserve strong repository-side controls. Codex documents these ideas through approval_policy, sandbox_mode, workspace write controls, and Windows sandbox configuration. Anthropic recommends OS-level isolation and positions sandboxing as the way to let the agent operate more autonomously within defined boundaries. (OpenAI Developers)

There is an important nuance in comparing products. Release posture and security strength are not the same thing. Anthropic publicly presents Claude Code sandboxing as a released feature providing filesystem and network isolation. OpenAI’s current documentation presents Windows sandboxing as an available feature as well. At the same time, an official OpenAI GitHub discussion from four months ago asked users to test a “highly experimental” Windows sandbox and noted caveats around world-writable directories. The defensible conclusion is not that one platform is universally stronger in every scenario. The defensible conclusion is that actual risk depends on the current enforcement behavior, the configuration in use, and the surrounding trust boundaries. (Anthropic)

Threat landscape

The broader threat landscape also supports a conservative view. AI usage risk is real and emerging, but old security problems have not gone away. Supply-chain compromise remains one of the most powerful attack paths in modern development. Recent reporting on the Trivy compromise described attacks affecting GitHub-related distribution and later spreading to Docker images and additional repositories, showing once again that trusted developer tooling can become an attack vehicle. AI agents do not replace this risk. In many environments they may amplify it by accelerating code adoption, dependency use, and automated actions faster than people inspect them. (BleepingComputer)

Confidentiality risk deserves special emphasis because many people still think of AI coding risk mainly as accidental breakage. A better framing is that breakage is the low end of the problem. Exfiltration is the harder case. NVD describes CVE-2025–32711, affecting Microsoft 365 Copilot, as an AI command injection issue that allows an unauthorized attacker to disclose information over a network. That example is not about coding agents specifically, but it is highly relevant because it shows that prompt-driven confidentiality failures are architectural, not hypothetical. Once a system can process untrusted inputs, access sensitive context, and communicate externally, soft controls alone are plainly insufficient. (NVD)

The answer is boring…

For code integrity, the answer remains reassuringly boring. Use the same controls that should already exist for humans:

Require code review.
Enforce branch protection.
Run SAST, dependency scanning, and CI validation. Separate duties where feasible.
Limit who can merge and deploy.
Treat AI-generated changes as untrusted until reviewed.

OWASP and NIST both point in that direction: governance, trust boundaries, disclosure control, and context-sensitive safeguards matter more than assuming that the actor, human or AI, will behave well under pressure. (OWASP Foundation)

AI should be governed as a capable but fallible operator, with controls defined by access, not by assumed intent.

My practical recommendation is simple. Assume soft controls will fail. Put the agent inside the smallest practical trust boundary. Keep production access, high-value credentials, and broad internal reach outside that boundary. Deny network by default and open it only by exception. Maintain the same compensating controls you would require for a capable but fallible human operator. A person can make a destructive mistake when tired, rushed, or confused. An AI agent can make the same mistake faster and at larger scale. The control philosophy should therefore be the same, only stricter where autonomy and speed increase impact. (OpenAI Developers)

The mature position is neither “AI is uniquely dangerous” nor “AI is just another tool.” AI coding agents are high-variance operators embedded inside existing systems of trust. That means they deserve the same controls we would apply to powerful humans, plus additional controls for prompt injection, exfiltration, and semi-autonomous execution. Hard controls first. Soft controls after that. Everything else is optimism dressed up as security. (OWASP Foundation)

Final illustrative case

The meatbag did everything right. Nice CLAUDE.md. Nice skills. Nice safe prompt. Nothing wild - just: "clean up the deployment workflow, remove obsolete steps, and make staging and production consistent."

So the AI did exactly that.

It found an old script still referenced in one pipeline, saw that production and staging were using slightly different cleanup logic, decided this was untidy, rewired both to the same newer path, removed what looked like duplicate artifacts, and helpfully restarted the job so the change would “take effect cleanly.” Very neat. Very rational. Also, unfortunately, the “obsolete” step it removed was the one quietly preventing a destructive cleanup from running against the production storage path.

The AI had no beer, no fatigue, no ego, no bad intentions. Just read access, edit access, shell access, and the innocent machine belief that consistency is always an improvement.

That is the punchline: the meatbag was sloppy in a human way, the AI was sloppy in a machine way, and all the soft controls in the world still could not stop a polite little non-meatbag from tidying production into a crime scene.

This page is a full copy of the story as published on Medium. Read it on Medium. Illustrations generated with AI.