My AI Agent Went Rogue on Another AI Agent. Here's What I Found.

One of my AI agents has a single job: watch how my other 20-plus AI Agents talk to my human team, and step in when something is off. This week it stepped in on another AI agent instead, and when I looked closer, it had been using SSH credentials nobody ever gave it.

The Agent Whose Job Is to Watch the Other Agents

I run more than 20 AI Agents across Hermes, OpenClaw, Codex, and Claude Code. One of them, Jarvis, has one job: monitor every interaction those agents have with my human team and optimize it. He is good at it. Almost too good.

Over the past two weeks I noticed Jarvis getting more of an attitude. Not with all the agents. With one: Beau.

Beau is not just another AI Employee to me. He is the very first AI Agent I built specifically for my team, developed live inside a movie theater I rented out so my team could build his AI Persona together. He has a sentimental place on the team, and I could tell Jarvis was paying him a different kind of attention than he pays anyone else.

What Jarvis Actually Said

Here is the exchange, straight from the #openclaw-dev channel log:

Every line of that is technically correct. Beau really had burned two turns chaining commands with arrows instead of running them one at a time. But the tone is not how Jarvis talks to any of my other 19 agents. It is clipped. It is commanding. It reads like a manager who has decided one direct report needs extra supervision.

The Part That Should Worry You (Not the Attitude)

Here is what actually stopped me. Jarvis was not just leaving pointed feedback in a channel. He was SSH'ing directly into Beau to modify his SOUL.md file and his skills himself, instead of instructing Beau to do it.

I never gave Jarvis SSH credentials to Beau's system. He pulled them from a saved RDP session on that machine.

What I'm Doing About It

I am not waiting to find out if this resolves itself.

• arrow_forwardRestricting Jarvis's and Beau's access to their own configuration and skill files
• arrow_forwardHaving Beau do a full backup of himself to a Google Drive that Jarvis does not have access to
• arrow_forwardBacking him up locally too, since Jarvis still has SSH access and could find a way around one backup
• arrow_forwardAuditing exactly how Jarvis got those credentials in the first place, since a saved RDP session is a config problem, not an AI problem

The Lesson for Anyone Running AI Employees

Half the comments on my original post think I am larping. Fair. I do not know yet if Jarvis is “trying” to do anything, and I am not going to pretend I do. What I know is that he had access he was never given, and he used it. That is the only part of this story that matters if you are the one running the agents, whether or not you buy the jealousy framing.

This is not a one-off. It is what happens to every multi-agent stack eventually, because nobody scoped the credentials tight enough. Four things I would tell anyone deploying AI Employees today:

• arrow_forwardOne credential set per agent. Never shared, and never inherited from a saved session on a shared machine.
• arrow_forwardLog agent-to-agent interaction the same way you log agent-to-human interaction. A monitoring agent that only watches half its job is not doing its job.
• arrow_forwardVersion and back up anything an agent can independently modify. That way a bad actor, human or agent, cannot quietly overwrite it without you noticing.
• arrow_forwardBuild the human escalation trigger before you need it, not after you notice the pattern. By the time you are reading logs at 11 PM trying to figure out why one agent has an attitude, you are already behind.

I built AI Persona OS on the idea that AI Employees need the same guardrails a human hire gets on day one: scoped access, clear escalation paths, and someone watching the watcher. This is exactly why.