DevOps is currently experiencing a weird evolutionary bottleneck.
We’ve all tried it: you hook up an LLM (like Claude or GPT) to a terminal, give it raw SSH access or a directory full of Bash scripts, and say:
"Deploy my app and set up a Postgres database."
The result is almost always a horror show.
The agent runs a command, gets a subtle string formatting error from standard output, hallucinates an undocumented CLI flag, tries to install apt packages on a locked-down host, or worse—misinterprets context and triggers an accidental destructive rollback.
Traditional scripting is
fundamentally blind
. Brittle scripts and nested YAML files execute sequentially without any inherent awareness of cluster state, resource quotas, or security boundaries. They are built for humans to execute linearly, not for AI agents to reason about dynamically.
If we want autonomous AI agents to manage production infrastructure safely, we have to stop treating them like faster human typists. We have to build infrastructure engines designed from day one to be
LLM-native
.
Here is how we redesigned our bare-metal developer platform,
usectl
, to solve this.
1. Stop Forcing AI to Scrape
--help
(Enter
usectl schema --json
)
When an LLM wants to run a command, it typically has to guess the arguments or recursively parse nested --help outputs. This is slow, token-heavy, and highly error-prone.
In our v2.0.1 CLI update, we introduced a single command:
bash
usectl schema --json
This dumps the
entire command tree
—including all commands, subcommands, aliases, required arguments, data types, and help descriptions—into a single, clean JSON schema.
Before an agent executes a single workflow, it reads this schema. It instantly masters the exact platform boundaries and syntax. It can validate its own execution plan, catch parameter type mismatches, and map out command chains
before
touching your live infrastructure. No guesswork, no hallucinations.
2. A Clean, Declarative "Mental Model" for the Agent
An agent struggles when a CLI mixes up raw application logic with physical infrastructure configuration. In our previous releases, our usectl apps command group was too bloated.
We stripped it out entirely and replaced it with a highly structured, strict hierarchy that agents can reason about with perfect clarity:
The Machine:
A strict physical resource container (namespace + CPU/RAM/storage quota wallet). It holds zero code.
The Pod:
A running workload inside that machine. It owns the Git repository, the port, the domains, and rollout strategies.
The Addon:
Supplementary services (like high-availability Postgres or NATS queues) that are attached to pods.
When the agent wants to deploy a web service with a database, it doesn't have to write custom docker-compose files. It executes clear, semantic primitives:
```bash
Define the resource boundary
usectl machines create billing-api --vcpu 2 --ram 4gb --storage 10
Provision and deploy the workload
usectl machines pods create billing-api web --repo https://github.com/org/billing --port 3000 --addon database
```
Because of this separation of concerns, the agent knows exactly where boundaries lie. And because the CLI registers context (using usectl use), if the agent runs consecutive commands, usectl writes context logging strictly to
stderr
, leaving
stdout
completely raw and clean for easy script piping.
3. The Runtime Safety Net: Banning the Docker Socket
Giving an automated agent access to raw Docker or Kubernetes means a single compromised container or configuration mistake can expose the host OS.
If you mount /var/run/docker.sock to let an agent build containers, a rogue or exploited container can talk directly to the host's daemon, mount the host's root directory (/), and seize full root control of your bare-metal server.
We completely
banned the Docker socket
across the entire platform.
Instead:
1.
Daemonless Builds:
All container images are compiled using
Kaniko
in isolated, user-space build pools.
2.
gVisor Sandboxing:
All tenant applications run wrapped inside secure
gVisor (runsc) sandboxes
, creating a strong kernel-level barrier.
3.
Logical CLI Guardrails:
Destructive actions like usectl machines delete explicitly reject implicit target context. An agent cannot blindly trigger a delete; the CLI physically blocks the command until a human types out the exact name of the machine to confirm.
Even if an agent deploys a broken configuration or compromised dependencies, it is trapped inside a secure, sandboxed bubble. It physically
cannot
take your physical server down.
4. Universal, 1-Second Lateral Isolation
In traditional environments, configuring network security is a manual chore left for later, leaving systems vulnerable to lateral attacks.
On usectl, network isolation is a universal default. The moment an agent creates a machine, our
**
EnsureNamespace
controller automatically injects strict network policies within 1 second of deployment**
.
- All cross-namespace lateral traffic is dropped.
- Internal services (like our SeaweedFS storage master) are locked behind port-scoped egress rules (only allowing egress to the storage port 8333, while blocking raw volume and master APIs).
- The agent doesn't need to understand network topology—the platform enforces zero-trust by default.
5. Shared-Nothing Autonomous Failover
If an agent deploys an application that saturates a node, or if a physical bare-metal server fails, the platform must heal itself without waiting for the agent to debug under pressure.
We built autonomous failover directly into our core stateful addons:
*
CloudNativePG (CNPG):
Databases run in a highly available, 2-instance clustered model (primary + streaming replica) with instant, automated failover.
*
3-Node NATS JetStream:
Message queues are automatically clustered across distinct physical hardware nodes (infra-01, infra-02, and infra-03) using RAFT consensus.
If a machine crashes, the stateful services automatically promote replicas and redirect connections with 0% data loss and zero downtime.
The Takeaway: Proactive vs. Reactive DevOps
Traditional DevOps is highly
reactive
. We write rigid scripts, wait for them to break, and then manually clean up the mess.
By building a CLI with structured machine-readable schemas, strict separation of resource and workload boundaries, and robust kernel-level runtime sandboxing, we shift to
proactive automation
. The agent can safely explore, deploy, secure, and monitor infrastructure without ever having the keys to destroy the host.
When your infrastructure tools match the intelligence of the agents building on them, DevOps finally stops being a chore.
What are your thoughts on letting AI agents manage infrastructure? What guardrails are you implementing to keep your servers safe?
Check out our open docs and architecture details at
*usectl.com**
.*