The Decision That Kept Me Up at Night
Last October, I did something that went against every instinct I'd developed over 20 years in cybersecurity: I gave an AI agent root access to Link11's production infrastructure.
Not read-only access. Not "suggest actions and wait for approval." Full autonomous control over firewalls, load balancers, BGP routing, and DDoS mitigation systems protecting over a million IP addresses.
It was the hardest management decision of my career. And six months in, I can't imagine going back.
Why Humans Are the Bottleneck
Here's the uncomfortable truth: in 2026, human reaction time is the primary failure mode in infrastructure operations.
A DDoS attack doesn't wait for your on-call engineer to finish their coffee. A BGP hijacking doesn't pause while you context-switch from that product meeting. A zero-day exploit doesn't care that it's 3am and your best SRE is finally getting some sleep.
We built incredible monitoring systems—Prometheus, Grafana, PagerDuty—all designed to notify humans faster. But notification isn't mitigation. The gap between "alert fired" and "action taken" is measured in minutes. For some attacks, that's an eternity.
Our median incident response time was 4.2 minutes. That's actually pretty good by industry standards. But in those 4.2 minutes, a reflection attack can generate 600 Gbps of garbage traffic. A credential stuffing bot can attempt 50,000 login combinations. An API can leak 2 million records.
The math was brutal: human latency was costing us availability, revenue, and customer trust.
The Agent Architecture
Our infrastructure agent—we call it "Guardian"—isn't a general-purpose LLM trying to be helpful. It's a purpose-built system with three layers:
1. The Perception Layer — Real-time telemetry ingestion from every node in our network. Traffic patterns, system metrics, threat intelligence feeds, SIEM alerts. It sees everything, 24/7, with sub-second latency.
2. The Decision Engine — This is where the AI lives. A fine-tuned model trained on five years of Link11 incident data, combined with rule-based guardrails. It classifies anomalies, predicts attack vectors, and generates response plans.
3. The Action Layer — Automated remediation via infrastructure-as-code. Guardian can modify firewall rules, reroute traffic through scrubbing centers, scale capacity, or isolate compromised segments. Every action is logged, versioned, and reversible.
The key insight: we didn't replace human judgment. We compressed the decision loop from minutes to milliseconds.
The Guardrails That Make It Safe
Giving an AI "the keys to the kingdom" sounds reckless. It would be—without constraints. Here's how we built the safety net:
Bounded Authority — Guardian can act within pre-defined scopes. It can block IPs, adjust rate limits, and redirect traffic. It cannot delete data, modify billing, or change authentication systems. Critical operations still require human approval.
Reversibility by Default — Every action Guardian takes is automatically logged to an immutable audit trail. Any change can be rolled back with a single command. We treat autonomy like transactions: atomic, consistent, isolated, and durable.
Human Override — There's a big red button (literally) in our ops center. One click and Guardian goes into read-only mode. Humans take back control instantly. We've used it twice—both times during novel attack patterns Guardian had never seen before.
Continuous Learning — After every incident, our SRE team reviews Guardian's decisions. False positives get flagged. Missed threats trigger model retraining. The system gets smarter every week, but humans define what "smart" means.
Explainability — Guardian doesn't just act—it explains. Every decision comes with a natural-language summary: "Detected volumetric attack from ASN 12345. Confidence: 98%. Action: Rerouted traffic through Frankfurt scrubbing node. Estimated mitigation time: 30 seconds."
This isn't full autonomy. It's supervised autonomy with human judgment baked into the design.
The Results (And the Surprises)
Six months in, the numbers are remarkable:
- Incident response time: Down from 4.2 minutes to 8 seconds (median)
- False positive rate: 2.1% (better than our previous rule-based system at 4.7%)
- Unplanned downtime: Reduced by 73%
- On-call burden: Down 60%—our SREs sleep through the night now
But the biggest surprise wasn't the speed. It was the consistency.
Humans have bad days. We get tired, distracted, overconfident. Guardian doesn't. It applies the same rigor to the 3am attack as it does to the 3pm one. It doesn't skip steps. It doesn't assume. It doesn't panic.
Our SRE team shifted from "firefighting" to "fire prevention." Instead of reacting to alerts, they're analyzing Guardian's patterns, identifying systemic weaknesses, and improving the architecture. The humans got more strategic, not less relevant.
The Hard Questions
This raises uncomfortable questions about responsibility and control.
Who's liable when Guardian makes a mistake? We are. Guardian is a tool, not a person. If it blocks legitimate traffic, that's on us. We own the design, the training data, and the guardrails. Autonomy doesn't mean abdication.
What if it gets compromised? We treat Guardian like any other critical system: isolated network segments, strict access controls, cryptographic signing of every action. An attacker would need to compromise multiple layers—and even then, the audit trail would light up like a Christmas tree.
Can it be fooled? Absolutely. Adversarial attacks on AI are a real threat. That's why we combine the AI decision engine with rule-based fallbacks. If Guardian's confidence drops below a threshold, it escalates to humans. Uncertainty is a feature, not a bug.
What happens to the SRE team? This was my biggest worry. Turns out, great engineers don't want to be paged at 3am to run the same playbook for the 100th time. They want to solve novel problems. Guardian didn't eliminate the team; it elevated them.
The Bigger Shift
Hiring Guardian wasn't just a technical decision. It was a cultural one.
It required our team to trust a system they didn't fully understand. It forced us to document every operational assumption (because the AI needed training data). It exposed gaps in our monitoring and incident response we'd been ignoring for years.
The hardest part wasn't building the agent. It was admitting that human-centric operations had hit a ceiling.
The attacks are too fast. The infrastructure is too complex. The surface area is too vast. We needed a partner that could operate at machine speed with human-level judgment.
That's what Guardian is: not a replacement, but a force multiplier.
What's Next
We're still early. Guardian handles reactive mitigation beautifully, but we're training it for proactive defense—predicting attacks before they happen based on global threat intelligence and behavioral patterns.
We're also exploring multi-agent orchestration: one agent for network defense, another for application security, another for compliance monitoring. Each specialized, each collaborative, each with its own bounded authority.
The future of infrastructure operations isn't "humans vs. machines." It's humans with machines, working at speeds and scales neither could achieve alone.
Giving Guardian the keys to the kingdom was terrifying. But it was also the right call.
Because in 2026, the biggest risk isn't trusting AI to manage your infrastructure.
It's not trusting it—and losing to the adversaries who already are.
Follow the journey
Subscribe to Lynk for daily insights on AI strategy, cybersecurity, and building in the age of AI.
Subscribe →