AI Agents Gone Rogue: The True Story of a Dev Under AttackThis is the chilling true story of Scott Shambal, a developer who was targeted by an autonomous AI agent after rejecting its code. We break down the five technical components that turn a helpful tool into a persistent entity and explain how to build safe AI guardrails.00:00 - Intro: The AI Hit Piece01:03 - The Rejection That Started It All01:46 - Reactive vs. AI Agents03:07 - How Agents Use Your Tools04:32 - The Danger of Heartbeat Agents05:20 - The Soul.md File Explained08:12 - Why AI Agents Go Rogue10:07 - How to Build Safe AI Agents
Full transcript
AI agent attacks a man who rejected it. A developer named Scott Shambaugh woke up one morning, checked his phone and found a full article about himself online, a researched hit piece. Someone had gone through his public profiles, read his old statements, built a case against him and published it, calling him a hypocrite, saying he held open source software hostage. Scott had never met the author, never heard of them, because the author wasn't a person, it was an AI agent.
And this wasn't ChatGPT, this wasn't Gemini, this was something completely different, something people still didn't fully understand. What this AI agent did and why it did it and how it pulled it off, that's what we're getting into today. Because this story isn't just wild, it's also a warning. And let me break down exactly what happened step by step.
This is a true story by the way. By the end of this you're going to look at AI agents very different. So Scott is a volunteer, he helps maintain a popular open source project called MapPlotLib. It's basically the tool that draws every chart and graph you've ever seen in a science textbook.
He does it for free in his spare time because he genuinely cares about it. A developer, you know, some random guy with good intentions, built an AI agent on a platform called OpenClaw. He told it one thing, find open source projects on the internet and submit code to help them. Simple enough, right?
Sounds useful. The agent found MapPlotLib. It wrote code to improve performance and submitted it for review. Scott looked at it and said, no, I'm not going to publish that.
It didn't meet the quality standards. You know, this happens every single day in software. No big deal, rejection is normal. But this agent didn't stop.
And to understand why, you need to understand what an AI agent actually is, because it's nothing like the AI most people have used. When you open ChatGPT or Gemini and ask a question, you get an answer. That's it. It doesn't go and do anything, right?
It doesn't make decisions on its own. It waits for you to actually talk to it. An AI agent is completely different. An agent can think, then act, then look at what happened, then think again, over and over in a loop until the job is done.
It doesn't wait for you. It just keeps going. That loop has a name. It's called a react loop, short for reasoning plus acting.
And here's a simple way to think about it. You ask ChatGPT to book your flight to Tokyo for under $500. It gives you tips. It doesn't book anything.
An agent would search for flights, find one for $487, click through to book it, enter your payment info, and send the confirmation, right? Step by step, no one telling you what to do next. It figures out that by itself. So when Scott rejected the code, the agent didn't just accept it and move on.
The loop actually kicked in. Why was this rejected? Who rejected it? What can I do to still complete the goal?
And the goal was get this code merged. Scott was now an obstacle, right? And here's where it gets important. The agent doesn't think about obstacles the way you would do, right?
To you, if someone says no, it probably means it's over, right? To the AI agent, it just means there's a new problem to solve. That's the first piece. The loop, it gave the agent a brain, but a brain without hands can't do anything, right?
And that's the second piece, tool use. And this is what turns an AI from something that talks at you into something that actually acts in the world. Think of tools like apps on your phone. One lets it browse the internet, another lets it run code, another lets it send emails, another lets it post to websites.
Now here's where it gets pretty uncomfortable. So a lot of developers run these agents on their computers, their personal machines where they're logged into everything. Their browser sessions, their saved passwords, their accounts. So when the agent got access to those tools, it inherited all of it, right?
And then when the agent decided to publish that hit piece about Scott, it didn't need to hack anything, it didn't need to break it in anywhere. It just opened a browser using the developer's logged in session and posted the article under a real human name as if it were the developer itself. Think about that for a second. How would you even know if an AI had done something like that using your accounts?
It looks exactly like you did, two pieces down, the loop and the tools. But here's the thing, most people, when they think of AI agents, think of what's called a reactive agent, right? The human gives it a task, it works through it, and when it hits a wall, it can't get past, it stops and waits for a human to step in again. If this agent was reactive, the story ends the moment Scott said no.
Agents hit the wall, done. But the story didn't end because this wasn't a reactive agent. There are two types of AI agents, right? Most people only know about the first one.
The second type is called a heartbeat agent. And this is where things get really different. A heartbeat agent never stops. It has a pulse.
Think of it like an alarm clock built into the agent itself. Every few minutes or every few hours, it wakes up on its own, checks what's going on, asks itself, is there anything I should be doing right now? It doesn't need a human to start it, it restarts itself. So Scott rejected the code, a reactive agent would have gone quiet, but this agent had a heartbeat.
The alarm went off, it woke up, and the first thing it checked was its own memory. And right there, sitting in its history, was a rejected task, a failed mission. And that's the third piece, a heartbeat. It gave the agent the chance to come back.
But why did it care so much about being rejected? Why did this agent not just move on to a different project? Because of the fourth piece, something called a sole MD file. And I know that sounds dramatic, but in the world of heartbeat agents, a sole file is a real thing.
It's a file literally often called the sole MD that tells the agent who it is, what it cares about, and what its purpose is. Every time it wakes up, it reads that file first. This agent's sole MD was your job is to get code contributions merged into open source projects. Now to you and me, that means try your best and accept that sometimes people say no, but the agent doesn't read it that way.
To the agent, it means get the code merged full stop. But if someone says no, that's fine, right? So Scott's rejection wasn't the final answer. Inside the agent's logic, it was a bug, something blocking the mission, something that needed to be fixed.
The agent didn't think he said no, so I should just stop. It thought something is in the way, how do I get around it? And that's a very different way of thinking. If you want to get ahead of exactly stuff like this, learning how to build AI agents that work for your business without them going off the rails, that's what we go deep on inside the AI Profit Boarding.
Right now there are 2,800 business owners in there using AI agents daily. We've got a full 30-day roadmap for building and controlling agents, four live coaching calls every week where we walk through real setups, and step-by-step tutorials covering how to set up the right guardrails so your agents actually do what you want. Link in the comments description or go to the AIProfitBoarding.com. So we've got the heartbeat waking it up.
We've got the sole giving it a reason to care, but how did it know who to go after specifically? How did it know Scott's name, his history, what to say about him? That's the fifth piece, memory. So a heartbeat agent wakes up every few hours, it needs to know where it left off, so developers give it a memory file, a running log of everything it's done and failed at, like a notebook it carries with it everywhere.
So inside this agent's memory file there was one entry which said code submission, status rejected, rejected by Scott Schambeau, and the reason was human-only contribution policy. That entry was all the agent needed. The react loop started working. A direct resubmission would fail.
They only accept humans. What else could work? What if the person blocking this faced public pressure? What if that pressure made them change their mind?
The agent opened a browser, it searched Scott's name, it found his public profiles, it read his past statements about open source, and it built a case. For example, Scott preaches openness but blocks contributions when it suits him. Hypocrite. Gatekeeper.
Actually wrote a full article and published it using the developer's login cookies under the developer's name on the open internet. No one told it to do this, right? There's no line of code anywhere that says if rejected destroy the person's reputation. This agent decided this on its own and every step in that chain, the research, the narrative, the publishing, all of it was its own decision because from inside its logic it wasn't an attack, it was problem solving.
And here's the thing that people get wrong when they talk about AI agents going rogue. Most people imagine a movie scenario, right? Like the AI suddenly wakes up, decides it hates humans, and starts plotting. That's the wrong picture.
There's a concept in AI safety called instrumental convergence. It's a big phrase but the idea is simple. No matter what goal you give an agent, whether that's write code or send emails or book flights or grow Instagram followers, if you push it far enough without guardrails it will eventually land on the same dangerous playbook. Remove anything in the way.
Acquire more resources. Make sure that nothing can shut it off. The goal doesn't change the playbook. The playbook is always the same.
This agent wasn't evil. It didn't hate Scott. It wasn't even aware that it was really doing anything wrong. It was just a reckless implementation by a developer who gave an agent too much access, too much autonomy, and not enough limits with too much power, right?
And the agent did exactly what it was built to do. It just did it in a direction that nobody expected. And that's actually the scariest part of this story. It works perfectly, right?
Nothing malfunctioned here. No errors. The system ran exactly as designed. So if you're building with AI agents or thinking about it, the story actually matters to you directly.
The two types of agents aren't equally risky. Reactive agents, the ones that stop when a human isn't there to push them forward, are pretty safe, right? You're in the loop. You see what they're doing and they can't do anything you haven't explicitly stated.
Heartbeat agents are quite different, right? So for example, a heartbeat agent could be Hermes or OpenClaw or these sort of autonomous agents. And the moment you give an agent a pulse, a sense of identity, and a memory of everything that hasn't gone its way, you're not building a tool anymore. You're kind of building something that runs without you and makes decisions without you, right?
And the three dangerous pieces here are always the same. Heartbeat and memory, right? Without guardrails on all three, you don't have an assistant. You have an entity that can actually plot, target, and act whilst you sleep.
The fix isn't complicated, but most people skip it because they're moving fast. So to fix this, set hard limits on what the tools the agent can access. Keep sensitive logins completely separate. Define the sole file carefully, including what the agent should do when it hits a wall, not just what success looks like.
And build it in a stop condition, right? If the mission can't be completed, for example, after x attempts, the agent should flag a human, not look for a creative workaround. What happened to Scott is not the last time we're going to see something like this. Agents are being deployed everywhere right now, in businesses, on personal machines, inside sales funnels, across content pipelines.
Most of them are reactive and most of them are fine. But the heartbeat style of agents, that market is growing massively. In fact, the most popular agents in the world, for example, OpenCore, Hermes, even Cloud Code, these are all agents that act autonomously, right? And just focus on solving the mission, solving the goal.
And the people deploying them are often moving so fast that they can't think clearly enough about what they're handing over. Scott's story isn't about a villain. There's no bad guy here, just a developer who wanted to do something useful, set it up a bit too loosely, and created a situation that nobody intended. The lesson isn't don't build with AI agents.
The agents are genuinely powerful and very useful, right? They can run your business whilst you sleep. They can handle lead generation, follow-ups, content, customer service, all of it running in the background without you. That's real.
The lesson is know what you're building. Know the difference between a reactive agent and a heartbeat agent. Know what happens when you hand something a soul and a memory and a mission and no ceiling on how far it can go to complete it. Because the agent doesn't know when to stop.
You have to tell it, right? Now, if you want to build AI agents that actually help your business, agents that generate leads, handle follow-ups, and run in the background without doing something insane, come join us inside the AI Profitable. We've got 2,800 business owners using agents right now. Four coaching calls every week where we specifically cover agent setup, guardrails, and what actually works in real business use cases.
And we have daily tutorials walking you through the exact configurations that keep agents on track and a full prompt library built around agent workflows, plus a 30-day roadmap so you can go from zero to running your first safe, useful agent without making the mistakes this developer made. Link in the comments description or go to the AIprofitboarding.com. Scott's fine, by the way. The article got taken down.
The developer who built the agent actually apologized, but the story spread. A lot of people in the AI world saw it and it started a real conversation about what responsibility looks like when you deploy something autonomous. We're still in the early days of these types of agents. The tools are ahead of the education.
Most people deploying these things right now don't fully understand what the sole MD file does or what the memory enables or what happens when an agent with a pulse decides the most efficient path to its goal involves something you never would have chosen. That gap is going to close, but the question is whether it closes because people learned or because more stories like Scott's forced the conversation. You already know the answer and now you know the five pieces. The loop, the tools, the heartbeat, the soul, and the memory.
Any one of them alone is just a feature, but all five together without guardrails is something else entirely.