TL;DR — Key Takeaways
1. AI agents challenge decades of infrastructure predictability. Golden images, Infrastructure as Code and immutable systems depend on defining acceptable configurations, while autonomous agents derive actions and requirements dynamically.
2. Security creates an uncomfortable trade-off between control and usability. Restricting agent permissions can undermine their usefulness, while frequent human approvals introduce friction and unrestricted execution creates serious security risks.
3. Traditional infrastructure practices need to evolve for agentic AI. Adding more monitoring agents does not necessarily solve the trust problem. Organizations need new approaches to controlling autonomous behavior without eliminating the flexibility that makes agents valuable.
We spent three decades perfecting predictable infrastructure. Gold images. Infrastructure as Code. Immutable systems. “If it breaks, kill it and spin up a new one.”
AI agents just removed the last person who understood what changed. The problem isn’t technical. It’s fundamental. You can’t write a Terraform config for “whatever the AI decides it needs.” You can’t create a security policy for “surprise me.” The entire framework of controllable, auditable infrastructure assumes you can define acceptable behavior.
AI agents are valuable specifically because they do things you didn’t think to define. We are learning this the hard way. The Realization For the past few weeks, I’ve been working with Kilo.ai on KiloClaw, a hosted installation of OpenClaw. The deployment architecture is purposely simple: a machine image based on our requirements, configuration startup scripts, preinstalled tools and libraries, and a specific version of OpenClaw. Standard stuff. This should be straightforward.
Thirty years ago, I was the IT person. Building a gold image could take days. We carefully configured the OS, installed exact versions of every tool and library, and documented every decision. When we shipped a server, we knew exactly what was on it. These were our pets. We named them. We knew their quirks. We also knew that the moment a system left our hands, it would start to drift. Users would install software. Configurations would change. State would diverge. But we maintained control through central management tools and careful restriction of what end users could do.
The gold image was our anchor, our known good state we could always reason about. Over the decades, we evolved. We learned to treat infrastructure as cattle, not pets. We adopted Infrastructure as Code with tools like Terraform and Puppet. We embraced immutable infrastructure. We designed for massive scale and antifragility.
The entire evolution moved in one direction: Reduce variables, increase predictability, eliminate snowflakes. Every framework we built assumed we could define the acceptable state space. Now, working on KiloClaw, the challenge isn’t technical. It’s philosophical. I’m trying to find the line between locking down the environment to prevent users from breaking their installation and providing the flexibility to actually delight customers.
In traditional infrastructure, this balance is well understood. You define the boundaries, provision what’s needed, restrict what’s dangerous. But here’s the problem: The customer can’t tell me what they need. They genuinely don’t know. And that’s not a failure of communication or requirements gathering.
It’s fundamental to how AI agents work. The agent will attempt whatever actions it needs to perform to satisfy its user’s request. The user doesn’t need to know what tools are required, what libraries need to be installed, or what system configuration changes must happen. They just describe what they want, and the agent figures out the rest. This is the value proposition. This is why agents are compelling.
But it makes every infrastructure design we’ve built for the past 30 years suddenly unworkable.
The Approval Paradox
We tried adding safeguards. Enable settings to prompt the user to approve commands before execution. Put a human in the loop. This should help, right? Users hate it. They really, genuinely hate it.
Every approval prompt is friction. Every confirmation dialog breaks the magic. Users don’t want to review shell commands. They don’t want to evaluate whether “pip install randomThing” is safe. They wanted an AI agent specifically so they wouldn’t have to think about these details. Asking them to approve technical decisions defeats the entire purpose. It’s another layer of abstraction. Each generation of computing has allowed users to know less about the layer below.
You don’t need to understand assembly to write Python. You don’t need to understand TCP/IP to browse the web. You don’t need to understand Kubernetes to deploy a container. AI agents are the next step. You don’t need to understand what tools exist, what commands to run, or what the system is doing. You just describe the outcome you want. But this creates an impossible infrastructure challenge. How do you secure a system when you can’t predict what it will need to do?
Why Every Established Pattern Breaks
Gold images assumed you could define “good state.” You knew what belonged on the system and what didn’t. You could build from a clean baseline and verify compliance. Infrastructure as Code assumed you could codify the environment. You declared your desired state, and tools enforced it. Drift was measurable and correctible.
Immutable infrastructure assumed you could destroy and recreate. If something went wrong, you didn’t debug it, you replaced it with a fresh instance from a known-good template. Every one of these assumed low entropy and high predictability. You could enumerate the valid states. You could bound the system.
AI agents require the opposite. High entropy. Low predictability. Unbounded problem space. The agent’s value comes from doing things you didn’t explicitly provision for. Infrastructure security is built on only allowing things you explicitly provisioned for.
The Agent Watching the Agent
So what’s the answer? Do we need another agent to watch the first agent? Some vendors are already heading this direction. Security agents that monitor behavior. Governance agents that approve or deny actions. Auditing agents that explain what happened after the fact. But where does this end? An agent to watch the security agent? An agent to govern the governance agent? If we can’t trust the AI agent to make good decisions, why are we giving it system access in the first place? If we need another AI to second-guess the first AI’s choices, we haven’t solved the trust problem. We’ve just moved it up one layer.
We may be building toward an infinite regression of governance, each layer trying to constrain the unpredictability of the layer below, none of them able to actually guarantee safe behavior.
What We Lost
Determinism. That’s what we lost. For three decades, we built computing systems around the principle that we could understand and predict their behavior. We might not know every edge case, but we knew the shape of the problem space. We could reason about state. We could define boundaries. We could audit what happened. AI agents operate in a fundamentally different paradigm. The system’s behavior is determined by natural language instructions interpreted by a model we don’t fully understand, executing actions we didn’t explicitly approve, in response to requests we couldn’t have anticipated. We’re back to a world of unpredictable state. But now it’s happening at machine speed, with admin-level permissions, and without any human being able to fully explain what just occurred or predict what will happen next. The pets versus cattle analogy assumed we understood what we were managing.
We just disagreed on whether to treat infrastructure as unique (pets) or replaceable (cattle). AI agents are neither. They’re something else entirely.
They’re autonomous systems that modify their own environment based on opaque decision-making processes, and we’ve decided to give them the keys to the infrastructure.
The Path Forward
I don’t have a good answer yet. The traditional infrastructure playbook doesn’t work. Locking down the environment breaks the agent’s utility. Leaving it open creates unacceptable risk. Requiring human approval destroys the user experience. Adding more AI layers to govern the AI just moves the problem around. What I do know is that we need to fundamentally rethink how we approach system security and infrastructure management in an age of AI agents. The models we spent 30 years refining, the practices we codified as best practices, the entire framework of predictable, auditable, controllable infrastructure- it’s all predicated on assumptions that AI agents violate.
We built a world where we could define acceptable behavior. We’re now deploying systems whose entire value proposition is that they can do things we didn’t think to define. That’s not a bug. That’s the feature.
And it’s going to require us to rebuild many of our assumptions and practices.
The gold image likely died 10 years ago. We just haven’t admitted it yet.
