The Guardrails Belong to Whoever Runs It

Between January 11 and February 18, 2026, an attacker got into more than 600 FortiGate firewalls in more than 55 countries. Amazon Threat Intelligence, which documented the campaign, was blunt about how: "No exploitation of FortiGate vulnerabilities was observed." It rated the attacker's skill as "low-to-medium baseline technical capability, significantly augmented by AI."

In a March 2 report, Team Cymru said an address Amazon had shared from that campaign had been running a service that announced itself as CyberStrikeAI. Its flow data showed the same address talking to FortiGate devices it was targeting. Amazon's report never names the tool, so that link is Team Cymru's.

Since then, the project has learned to talk about governance. It's worth asking whose.

---

The tool on that server

CyberStrikeAI is an open-source, self-hosted platform, written in Go, where AI agents orchestrate more than 100 security tools. It had 7,202 stars on GitHub as of October 8. Between January 20 and February 26, 2026, Team Cymru counted 21 different IP addresses running it.

Team Cymru assesses that the developer "has some ties to the Chinese government." Amazon describes the attacker as Russian-speaking and suspected to be financially motivated. Whoever wrote the tool, what it did on that server was up to whoever ran it.

Who wrote a tool matters less than who runs it.

---

Governed by whom?

In January and February, while the campaign ran, the project's README offered a "password-protected web UI, audit logs, and SQLite persistence." By May it asked you to "use CyberStrikeAI only on systems you own or are explicitly authorized to test." By July it promised "human oversight," role-based access control and "one auditable workspace." Its GitHub description now calls it the place "where intent becomes governed execution."

Grant that every one of those features works as described. Every one still belongs to whoever runs the server. The oversight is whoever the administrator appoints, and the permissions are whatever the administrator grants. The authorization rule is a sentence in a README, under a license that lets anyone change the code that enforces everything else.

Role-based access control decides what each user can do. It can't decide what the server's owner does, because the owner writes the roles.

A guardrail the operator can edit is only a preference.

That isn't a defect in this project. It's true of every self-hosted tool, offensive or not. Those 21 addresses meant as many as 21 sets of guardrails, each tuned by whoever set that server up.

On October 15 I argued that whoever runs an agent answers for what it does. This is the same fact seen from the attacker's side: whoever runs an agent also decides what its guardrails are.

---

The doors were ordinary

Here's the part defenders should sit with. Amazon found the campaign "succeeded by exploiting exposed management ports and weak credentials with single-factor authentication." Those are the oldest findings in any assessment report, and they were enough.

Amazon's profile of the attacker is just as telling. This was someone who "can run standard offensive tools and automate routine tasks but struggles with exploit compilation, custom development, and creative problem-solving during live operations." AI didn't lift that ceiling. It lifted the floor and the volume.

What AI changed was the price of trying. Amazon calls the weaknesses "fundamental security gaps that AI helped an unsophisticated actor exploit at scale." The attacker didn't need to be good, or even persistent.

Faced with hardened environments, Amazon says, they "simply moved on to softer targets rather than persisting." They needed volume, and the tooling made volume cheap.

Cheap attempts find every door you left open.

So the defense is boring, and that's good news. Take management interfaces off the internet. Retire default and reused passwords, and put a second factor on every admin and VPN login. By Amazon's account, those three gaps were the way in.

---

Your agent has the same problem

If you run agents, read the first half of this story again with your own stack in mind. Your agent has guardrails too: a system prompt, a tool list in a config file, the model's own refusals. Static guardrails like these have a rough record in production, and they share one weakness. They answer to whoever controls the agent.

Most days that's you. After one poisoned dependency or one stolen admin credential, it's someone else, and every setting you were counting on is theirs.

A guardrail inside the agent changes hands with the agent.

The controls that survive a change of hands live outside it. What the agent can reach is set by the network, not the prompt. Its credentials should be small, scoped and short-lived, so a stolen one buys little. Its spending should stop at a hard ceiling held by someone other than the agent.

Four questions cover most of it: what can the agent reach, what can its keys do, what can it spend, and who can stop it without asking it first? If the only off switch is a setting inside the agent, it doesn't have one.

Whatever you bought or built to enforce those limits, prove it in your own environment. A control nobody has tested against a hostile operator is a guess. So test it like one: change a setting from inside the agent and see whether anything outside it stops you.

---

Where it won't run

When CyberStrikeAI crossed my desk, my first question was whether we could stand it up and look at it. On paper, easily: it builds from source.

It isn't going anywhere near production. I'd be parking a fully equipped attack platform next to the systems this business runs on, with guardrails that belong to whoever reaches its keyboard.

Build the room before you let anything loose in it.

Somewhere, CyberStrikeAI answered on 21 addresses in just over five weeks, each one governed exactly as well as its operator wanted. Your agents are governed exactly as well as your controls hold on the day someone else is at the keyboard. Build for that day.