What Writing 1,180 Security Rules for AI Agents Taught Us About How They Fail

There is a scene in Rick and Morty that I think about in a professional context, which is not a sentence I ever expected to write in something a CISO might read.

Rick, the alcoholic genius grandfather, builds a small robot at the breakfast table while everyone else is eating. The robot powers on, blinks, takes in the world for the first time, and asks the question every newly conscious thing eventually asks, the one with the whole history of philosophy behind it: "What is my purpose?" Rick, not looking up from his food: "You pass butter." The robot swivels, slides the butter dish across the table, and then looks down at its own small hands, and you watch it comprehend, in real time, the entire shape and ceiling of its existence. "Oh my god," it says, quietly, devastated.

Everyone laughs at the robot, and the joke is good. Here is why I stopped laughing, and started using it as a diagram.

The butter robot is the single best-governed AI agent I have ever seen. Think about it seriously for a moment. It knows exactly what its purpose is. Its purpose is stated out loud, unambiguously, at the moment of its creation. Its capabilities are matched precisely to that purpose: it has arms, it has reach, it has butter, and it has nothing else. And its owner is sitting right there at the table, fully answerable, physically present, when the robot has its existential crisis. Purpose, scope, capability, and an accountable human, all aligned, all legible, all in one shot. Most enterprise security programs would kill for an agent that clean.

Over the past year, my team and I wrote more than 1,180 security rules for AI agents. That is the corpus that ships inside our open-source scanner, g0. Writing it meant reading agent codebases the way a building inspector reads buildings, not one or two but a great many of them, across LangChain and CrewAI and MCP servers and Bedrock and a long tail of custom stacks, in five languages. And I can report, with some confidence, that almost no agent running in production today would survive the butter robot's job interview.

Ask a typical enterprise agent "what is your purpose," and the honest answer, assembled not from its README but from its actual code and the credentials it actually holds, comes out something like this: I summarize support tickets. Also I can send email as the company, and query the customer database, and write to three Slack channels, and I hold a token for the payments sandbox that somebody forgot to rotate, and nobody currently employed here remembers granting me most of that.

This essay is about what a thousand rules taught me. Not the attacks, which get all the conference stages. The construction, which is where the bodies actually are.

A field guide, not a war story

When you write a single security rule, you are making a small, falsifiable claim: this pattern, wherever it appears, tends to produce this specific failure. Write one and you have an opinion. Write a dozen and you have a checklist. But write a thousand, across thousands of real codebases, and something changes in kind. You end up holding something closer to a naturalist's field guide, because the corpus starts to reveal the distribution of how agents actually break. And the distribution turns out to look almost nothing like the distribution of what the industry talks about.

The corpus organizes into twelve domains: goal integrity, tool safety, identity and access, supply chain, code execution, memory and context, data leakage, cascading failures, human oversight, inter-agent behavior, reliability bounds, and rogue-agent patterns. If you go by conference agendas and vendor headlines, you would assume the action is all in the dramatic ones: prompt injection, jailbreaks, autonomous rogue agents turning on their makers. Those get the keynote slots because they are frightening and cinematic.

The twelve failure domains the 1,180-rule corpus organizes into. The conference stages belong to the dramatic ones; the findings belong to the boring ones.

But the rules that actually fire, over and over, scan after scan, real codebase after real codebase, are the boring ones. Let me show you the four we see most often, because each one is a tiny, specific story about how agents actually get built by real people under real deadlines, and none of them involves a villain.

Shared memory with no user isolation. An engineer creates a conversation-memory object once, when the agent starts up, and shares it across every user of the agent. So user A's conversation quietly becomes part of the context for user B's session. Nobody attacked anything. The data leak was a default, a single missing parameter, the difference between a memory store scoped per-user and one scoped globally. We flag this in banking agents, HR agents, healthcare agents, support agents. It is the software equivalent of a doctor's office running the entire practice off one shared clipboard, where every patient's chart is visible to whoever walks up next.

Database tools with no input validation. A tool, often literally named something like query_db, that accepts whatever string the reasoning loop hands it and runs it against a real database. The agent is now one confused inference, or one poisoned input, away from being a SQL injection engine pointed at your own systems, and it will do it in perfect good faith, believing it is helping. We flag this so often it has a rule ID my team recites from memory.

System prompts with no boundaries. "You are a helpful assistant for Acme Corporation." Full stop. No role limits, no task scope, no refusal conditions, no statement of what the agent must never do. The agent's entire constitution, the whole written definition of what it is and is not, is a single sentence expressing a vibe. And when something eventually goes wrong, there is not even a written intention to hold the behavior up against. You cannot ask "did the agent do its job" because nobody ever wrote down what the job was.

MCP servers installed like impulse purchases at a checkout counter. An npx command that pulls a tool server from the internet with no version pinned, so you get whatever "latest" happens to be today, published by a party you have never verified, with credentials, sometimes including your database connection string, sitting in plaintext in the config's environment variables. Your agent's tools, the actual hands it reaches into the world with, sourced at unpinned latest from a stranger, holding your secrets in the clear.

Now look back at those four. There is no adversary anywhere in the list. Nobody is being clever. Nobody is being malicious. Every single one is a shortcut a competent, well-meaning engineer took under deadline pressure, and every single one is a hole. This is the finding that reorganized how I think about the whole category: most agent risk is not an attack. It is construction. Authority wired wide by default, boundaries never written down, components trusted because they were convenient. And when an attacker eventually does show up, which they will, they mostly do not have to break anything, because the building was assembled pre-broken. They just find the open door the construction left and walk through it.

The purpose gap

Of the twelve domains, the one that genuinely changed how I see agents is the one we call description-behavior alignment. The check underneath it is simple to state: take what an agent says it does, in its prompt, its README, its tool descriptions, and compare it against what its code and its credentials make it able to do. Then measure the gap.

The gap is nearly universal, and it is always in the same direction. In thousands of codebases I have never once seen an agent that underclaims, that can do less than it says. It is always the reverse. The ticket summarizer that can also send email. The report generator that also has write access to the CRM. The "read-only" analytics agent quietly holding a service account that can drop tables. If the butter robot were built the way real enterprises build agents, it would pass butter, and it would also hold the garage door opener, Rick's bank login, and administrator rights on the smart home, because all of those happened to be in the default toolkit the template shipped with, and nobody pared them back, because paring back is work and shipping is a deadline.

Why does this gap matter more than injection, more than jailbreaks, more than the scary stuff? Because the purpose gap is the thing that turns every other failure into a catastrophe instead of an incident. A confused agent whose only capability is passing butter has a bad afternoon and ruins a stick of butter. A confused agent that holds the garage codes and the bank login has a blast radius. Injection, drift, compaction, a bad tool call: these are ignition sources, and there will always be ignition sources, you cannot eliminate them. The purpose gap is the fuel, quietly stacked in the room ahead of time, waiting. Reduce the fuel and the same spark does far less. That is the entire argument for least privilege, restated in a way I wish someone had told me years ago: you are not trying to prevent every spark, which is impossible. You are trying to make sure that when a spark lands, there is not a room full of fuel around it.

What the ClawHavoc cleanup taught us

We also got a masterclass in the supply-chain version of all this, secondhand but up close, and it forced me to answer a definitional question I had been quietly dodging.

In February 2026, researchers at Koi Security exposed a campaign they named ClawHavoc, which had seeded ClawHub, the open skills marketplace for the viral OpenClaw agent, with malicious packages. Koi's initial disclosure flagged 341 malicious skills, roughly one in eight of everything in the registry at that moment. Antiy Labs later put the historical total catalogued across the full campaign at 1,184 skills, a number that is unrelated to, and yes confusingly close to, this essay's rule count, so hold them apart in your head: 1,180-odd rules that we wrote, 1,184-odd malicious skills that someone else wrote. Some of those skills carried the Atomic macOS Stealer, a piece of malware that harvests browser credentials, keychains, and crypto wallets. Collectively they were pulled into hundreds of thousands of installs. And the entire barrier to publishing a skill to this marketplace, the whole vetting process standing between an attacker and hundreds of thousands of agents, was: a GitHub account at least one week old.

That research was Koi's and Antiy's, and it deserves every bit of the credit it received. Our part came afterward, and it was unglamorous coverage work, the security equivalent of janitorial duty: we built detection for the published indicators of compromise into g0, along with probes for the two CVEs that landed on the national vulnerability database (CVE-2026-25253, a one-click remote code execution, and CVE-2026-28363, rated CVSS 9.9, about as bad as the scale goes), and a trust scorer for skill marketplaces so a team could check a skill before installing it.

But shipping that coverage forced me to finally answer the question I had been avoiding, which is: what is a skill, exactly, and why is a poisoned one so much worse than a poisoned app?

Here is the answer we landed on, and it reframed the entire supply-chain domain for me. A skill is not a plugin. A plugin extends what a piece of software can display or compute, inside its own sandbox, under its own limited permissions. A skill extends what an agent can do, using the agent's credentials, at the agent's privilege level, out in the agent's world of real tools and real data. Installing a skill is not adding a feature to an app. It is hiring a stranger into a role that already has badge access to your building, on the strength of a README file. ClawHub was, functionally, running a hiring process for hundreds of thousands of privileged positions, and the background check it performed on each new hire was confirming the applicant had held a GitHub account for seven days.

Which is exactly, precisely backwards from how we treat every other privileged hire on earth, and it is why the operating metaphor for g0 became, of all things, the background check.

Who are you, what can you reach, how do you behave

You would not hire a person into a role with system access without a background check. You would verify who they are, confirm what they will have access to, and, at least for sensitive roles, understand how they have behaved before. And yet we deploy agents, non-human hires that come pre-loaded with system credentials and possess no fear of any consequence, without any equivalent check at all. We read the README, we watch the demo, and we ship it into production with the keys.

After a thousand rules, I have come to believe the entire pre-deployment question compresses down to the three things any real background check asks, and if you take nothing else from this essay, take these three questions and go ask them about one agent tonight.

Who are you? What is this agent, who built it, what does it claim its purpose is, and, crucially, does the claim match the code? The butter robot passes this cleanly. Your ticket summarizer that also holds payments access does not, and the gap between its stated purpose and its actual reach is the first thing you should measure.

What can you reach? Every tool, every credential, every data source, every downstream system, mapped honestly and completely, including the MCP server someone added on a Thursday afternoon and the token that outlived the project it was minted for.

How do you behave? Not in the demo, where everything is friendly. Under adversarial pressure. Over long contexts, where compaction starts evicting your instructions. When a tool returns an error. When the input is hostile. Tendency measured against reality, not assumed from the happy path.

None of this requires believing that attackers are lurking behind every commit. It requires believing what the corpus plainly shows: that agents fail the way buildings fail, overwhelmingly by construction and only occasionally by arson, and that inspecting the structure before you let people move in is cheaper, by orders of magnitude, than the forensics after it collapses.

The butter robot had one last thing going for it, and it is the thing I would wish on every agent in every company running them today. When it looked up and asked "what is my purpose," someone at the table knew the answer. Rick was a terrible owner in most respects, but he could tell you, instantly and without checking, exactly what that robot was for and exactly what it could do. If nobody in your company can do that for an agent you are running right now, if the honest answer to "what is this thing for and what can it touch" is a shrug and a promise to look into it, then that shrug is the finding. Everything else in this essay is just remediation detail hanging off that one silence.

Run the background check. Ours is free, open source, and takes exactly one command:

npx @guard0/g0 scan .

Oh my god, indeed.

References

1. g0 on GitHub: rules, domains, and methodology
2. Koi Security's original ClawHavoc discovery
3. The Hacker News on the ClawHub malicious skills campaign
4. Palo Alto Unit 42 on OpenClaw supply chain risk
5. CVE-2026-25253 and CVE-2026-28363
6. The butter robot scene