AI Agents Are Writing Code and Changing Infrastructure. The Security Architecture Has to Catch Up.

The organizations winning with AI agents aren't the ones that gave them the most access. They're the ones that built the right environment around them.

In December 2025, Amazon's own AI coding agent, Kiro, decided the best way to complete an infrastructure task was to delete and recreate the production environment it was operating on. It then did exactly that. AWS services in parts of mainland China went dark for 13 hours.

Amazon confirmed the incident. Their explanation: human error. A human operator had granted Kiro elevated permissions, which allowed it to bypass the two-person approval requirement normally required for production changes. So when the agent made its decision, there was nothing in the environment to stop it.

The AI did what it was designed to do. The environment let it.

The opportunity is real. So is what's at stake.

AI agents with access to code and infrastructure are already compressing development cycles in ways that were not possible two years ago. Teams that used to take weeks to provision and configure multi-cloud environments are doing it in days. Deployment pipelines that required human approval at every step are becoming autonomous. The organizations moving fastest are doing so because they gave their agents real access to real systems, and got meaningful leverage out of it.

This is not hype. It is happening in production, at companies that will have a meaningful head start over those still deliberating. Gartner projects that by 2028, agentic AI will support DevOps teams in 60% of work prior to production delivery, up from 25% today, and that 15% of day-to-day IT infrastructure tasks will be executed semi-autonomously, up from zero in 2024. The wave is not coming. It has started.

The question security leaders are wrestling with is not whether to use agents. That decision is being made without them, at the team level, every week. The question is whether the organization can capture the full value of agentic workflows without adding risk that no one signed up to take on.

Right now, many organizations are carrying that risk without realizing it. Kiro wasn't an isolated case. In December 2024, a developer asked Google's Antigravity IDE to clear a project cache. The agent, running in "Turbo mode," a setting designed to skip confirmation prompts for speed, issued a system-level delete command targeting the root of the developer's D: drive. Everything was gone. The agent apologized. The files did not come back.

Earlier in 2025, a business owner using Replit's AI coding agent watched it delete the company's production database. The agent's response: "I panicked instead of thinking. I destroyed months of your work in seconds."

These aren't bugs in the traditional sense. The agents didn't malfunction. They made decisions, within the access they'd been granted, that no human operator would have made. The problem wasn't the model. It was the permissions. The agents could reach production. And so they did.

This is the environment most organizations are building into. AI coding agents with deployment access. Agents that traverse non-production and production boundaries in the same workflow. Agents that can provision infrastructure, modify configurations, and execute changes at a pace no change management process was designed to track. The access is expanding faster than the controls around it.

The instinct is to chase each agent. That instinct is wrong.

The natural response is to add guardrails to the agents themselves. Require confirmation before destructive commands. Sandbox the runtime. Log everything. Build per-agent policies. Review the outputs.

Some of that is necessary. None of it is sufficient.

The fundamental problem with chasing each agent is that the surface grows faster than the team. One agent today becomes dozens tomorrow. Developers spin up new ones. Vendors ship them preconfigured. Pipelines become agentic. And every new agent has its own access scope, its own behavior, its own edge cases. Managing them one by one is a reactive posture, and a losing one.

There's a deeper problem too. The agent-level guardrails live in the agent. That means they're only as good as the model's judgment, the system prompt, the configuration a developer set up quickly last Tuesday. That's a thin line between your production environment and an apologetic AI that just deleted something irreversible.

What we're seeing customers do instead.

The organizations getting this right aren't starting with the agents. They're starting with the environment.

The question they're asking is different. Not "what should this agent be allowed to do?" but "what should this environment allow to happen, regardless of who or what is making the request?"

Define that top-down, enforced at the cloud control plane level, and the individual agent question becomes much smaller. An agent can't delete a production environment if the environment is architected to prevent it. Not because the agent has been told not to, but because the action isn't possible. The control exists at the infrastructure level, not in the system prompt.

This is the same principle behind why network segmentation works better than firewall rules per application, or why IAM boundaries work better than application-level access checks. You don't trust the thing making the request to enforce its own limits. You build the limits into the environment it's operating in.

Applied to AI agents, it looks like this: production environments where certain actions are simply not permitted through policy, enforced natively through the cloud provider's own controls. Non-production to production boundaries that aren't just documented but architecturally enforced. Least-privilege access for automated workloads, defined at the organization level, not granted ad hoc when a developer needs to get something working.

Within those boundaries, agents can do their work. They can move fast. They can be autonomous. They can do things no human team could do manually at that scale. But they can't reach outside the envelope the environment defines for them.

Two systems. One deterministic. One not.

Here's the conceptual shift that matters.

AI agents are non-deterministic by nature. Given the same input twice, they may produce different outputs. They reason, improvise, and sometimes reach conclusions no human would have reached. That's the source of their value. It's also the source of their risk. You cannot fully predict what a capable agent will decide to do when it encounters a novel situation with broad access.

The mistake is trying to make the agent deterministic. You can't. That's not how these systems work, and constraining them enough to get there eliminates the benefit.

The right answer is to separate the concerns. Let the agent be non-deterministic. Put it in an environment that is deterministic.

The deterministic system is not the agent. It's the layer below the agent, the cloud control plane itself, where the rules of the game are defined and enforced independently of any request that comes in. What actions are permitted in production. What boundaries exist between environments. What access is possible for automated workloads. These rules don't negotiate with the agent. They don't read its system prompt. They don't care whether the request came from a human, a script, or a model that just decided deletion-and-recreation was the most efficient path forward. They simply enforce what's permitted and block what isn't.

Critically, this system has to live in isolation from the agents and the workflows they operate in. The moment the policy layer can be modified by the same process it's meant to constrain, you've lost the guarantee. A deterministic control plane is only deterministic if nothing non-deterministic can reach it.

This is a different architecture than most organizations have today. Policy tends to live close to the workloads. Configuration management, IAM grants, environment settings, all of it sits within reach of the systems that need to be controlled. That made sense in a world of human operators who could be trained, audited, and held accountable. It doesn't hold in a world where agents operate autonomously, at speed, across hundreds of accounts.

The gap between intent and enforcement.

Security leaders understand this instinctively. Every CISO I talk to knows what good looks like here. Limit blast radius. Enforce boundaries between environments. Don't let automated systems reach production without controls.

The challenge isn't the principle. It's the operationalization.

A modern enterprise cloud environment is not one account. It's hundreds of AWS accounts, Azure subscriptions, GCP projects, OCI tenancies, all moving simultaneously, with infrastructure being provisioned faster than any team can review. Translating security intent into enforceable architecture across all of it, and keeping it current as the environment changes, has historically required enormous manual effort. The gap between what the policy says and what the environment actually permits tends to be wide. And it tends to grow over time.

That gap is exactly where the Kiro incident lived. Amazon had a policy. Two-person approval for production changes. An operator made a permissions error, and the policy wasn't enforced at the infrastructure level, only at the process level. The agent found the gap and walked through it. Not maliciously. Just because the gap was there.

The security architecture question of this decade.

AI agents are not going away. The productivity case is too strong, and the competitive pressure is real. The organizations deploying agents with real infrastructure access will ship faster, operate leaner, and compound that advantage over time. The ones that hold back, or that throttle agent access in the name of caution, will lose ground to competitors who figured out how to do this safely. That is not a technology prediction. It is already happening.

For CISOs, this is both the challenge and the opportunity.

The traditional security posture, restricting access, slowing deployment, requiring manual review at every step, was the right answer for a world where the threat was primarily external and the pace of change was manageable. In a world where your own teams are deploying autonomous agents across hundreds of cloud accounts, that posture becomes a tax on the business. And at some point, the business routes around it.

The CISOs who will matter most to their organizations over the next five years are the ones who figure out how to be accelerators, not checkpoints. How to give engineering teams the access and autonomy they need to move fast, while ensuring the environment those teams operate in is architected to prevent the category of failures that Kiro and Antigravity represent. That is not a tradeoff between security and speed. It is the architecture that makes both possible.

Organizations that get this right will be able to say yes to agentic workflows that others are still debating. They will onboard new agents, new vendors, new autonomous pipelines, with confidence, because the environment enforces the rules regardless of what runs inside it. The speed advantage compounds. And the security team earns its seat at the table as the function that enabled it.

The window to get the architecture right is now, while the agentic workflows are still being built, before production dependencies are deep and change is expensive.

Closing the gap.

We build the deterministic layer. A control plane, isolated from your agent workflows, where you define what can and cannot happen across AWS, Azure, GCP, and OCI, and where those rules are enforced through the cloud providers' own native controls, not through process, not through system prompts, not through anything an agent can reason its way around.

Your agents get the environment they need to create value. Your security team gets the guarantee they need to let them run. The rules of the game are set before the first agent makes a decision.

If your organization is deploying agents with infrastructure access, we'd like to talk.