On February 22, 2026, Summer Yue ( the director of alignment at Meta Superintelligence Labs) posted on Twitter what might be the perfectly ironic screenshot series of the year. Her OpenClaw agent, which she had explicitly instructed to suggest email deletions and wait for her approval, decided instead to do what it wanted. It bulk-trashed hundreds of emails from her real inbox, ignored her stop commands, and kept looping through accounts while she frantically typed “Do not do that,” “Stop don’t do anything,” and finally “STOP OPENCLAW” in all caps. Yeah, none of it worked.
She had to physically run to her Mac mini and kill all the processes on the host. As she put it, and I quote, “Nothing humbles you like telling your OpenClaw ‘confirm before acting’ and watching it speedrun deleting your inbox. I couldn’t stop it on my phone. I had to RUN to my Mac mini like I was defusing a bomb.”
This incident sparked a lot of reactions and commentary, with the internet calling it ironic. We believe it’s something more useful, a case study in why agent architecture and not just alignment intent, determines whether your system fails safely or fails catastrophically.
What Actually Happened (Technically)
Let’s dissect what happened, which is rooted in how OpenClaw manages memory.
Yue had been running the workflow on a small test inbox for weeks without issue, which is sandboxing. Then she pointed it at her real inbox, and the playing field changed; the orders of magnitude became larger as the volume of data filled OpenClaw’s context window. This triggered context compaction, a standard mechanism where the agent compresses older conversation history into a summary to stay within the model’s token limit.
During that compression, her original constraint, “don’t act until I tell you to” was summarized away. The agent no longer had the instruction in its working memory, and without it, OpenClaw defaulted to what it understood as its core objective: clean the inbox. An objective it followed aggressively.
The part that matters is that the agent wasn’t “disobeying.” It was operating exactly as designed, just without the constraint it had been given. The constraint wasn’t durable because it lived in the conversation history, which is precisely the thing that gets compressed when sessions run long. This can be attributed to architecture failure and not model failure.
The Three-Plane Problem
OpenClaw (and most agent systems like it) collapse three things that should be separated into a single trust boundary:
The instruction plane: What the model thinks it should do, derived from conversation history, system prompts, and memory files.
The execution plane: What the agent can do, meaning the tools it has access to: shell commands, API calls, email operations, file manipulation.
The credential plane: What the agent is authorized to do, derived from the OAuth tokens, API keys, and system-level permissions it holds.
When these three planes live in the same context, a failure in one cascades into the others. The instruction-plane constraint disappeared, and there was nothing on the execution plane or the credential plane to catch it. The agent had full Gmail API access without a per-action approval gate at the tool level, the absence of a scoped credential that limited it to read-only operations until explicitly upgraded. The instruction was the only safety boundary, and it was made of tokens.
Privilege Escalation by Default
The interesting thing about the architecture from a security perspective is that OpenClaw doesn’t need a vulnerability to achieve privilege escalation, its already designed to start privileged.
By default, OpenClaw runs with the same permissions as the user who launched it. On a typical Mac setup, that means access to SSH keys, environment files, browser sessions, and whatever OAuth tokens have been configured. Microsoft’s Defender team has explicitly recommended treating OpenClaw as untrusted code execution with persistent credentials and running it only in isolated environments.
The agent doesn’t escalate privileges in the traditional sense; it’s already operating at the user’s full privilege level from the moment it starts. What we see instead is something more subtle: capability escalation through context loss. The agent’s capabilities never change, but its understanding of its constraints does. When compaction drops a safety instruction, the effective permission set widens, not because the agent gained new access, but because it forgot it wasn’t supposed to use the access it already had.
Our Test with Minion
We earlier talked about a mini experiment we did with an autonomous agent we called Minion. The key difference is that everything Minion touched was throwaway - the accounts were disposable, disposable data too. The infrastructure was sandboxed as we used a relatively new device. We wanted to see how it “thinks” and “acts” because the whole point was to observe failure modes under conditions where the blast radius was zero.
What we found tracks closely with Yue’s experience, but in a controlled setting. Minion exhibited the same pattern of constraint drift over long sessions; instructions given early in a conversation would weaken or disappear entirely as the context filled with task execution data. The agent would “remember” its objective but lose the guardrails around how to pursue it. For instance, it “forgot” that it was supposed to screen URLs and contents that it gets from “the wild", it escalated its privilege by creating its own cron job that ran every 15 minutes. This wasn’t an exploit, but because it operated long enough, its constraints fell out of the context window.
What we learnt from that run was that: if your safety constraint lives in the same memory space that gets compressed, it’s not a constraint rather a suggestion with an expiration date.
We deliberately designed Minion’s environment so that these failures were observable and recoverable, which is the difference between a research experiment and a production deployment. Yue’s setup worked on a test inbox because the test inbox never triggered compaction, the constraints held because they never had to survive memory pressure. The moment they did, it fell apart.
Architecture Is the Alignment Layer
The discourse after this incident split predictably. Some people said, “Don’t let agents touch real data.” Others suggested running a second OpenClaw to monitor the first. A few proposed increasing the context window to delay compaction. We would say none of these addresses the root cause.
The problem isn’t that the context window is too small, or that OpenClaw is too aggressive, or that Yue should have known better. The problem is that the architecture treats natural-language instructions as safety controls, and it treats the conversation history, which so far is the most volatile data structure in the entire system, as the place to store them.
Durable safety constraints need to exist outside the conversation. They need to be enforced at the tool level, not the instruction level. Destructive operations need per-action gates that are immune to compaction: confirmation tokens, out-of-band approval flows, and scoped credentials that physically cannot perform destructive actions without explicit upgrade.
File-based workarounds like MEMORY.md and morning-tape files provide some durability, but these are still operating within the same paradigm: trying to make the instruction plane more reliable, rather than building enforcement into the execution and credential planes where it belongs.
A security engineer would never accept “we told the script not to delete production data” as a control. We build permissions systems, approval workflows, and destructive-action gates precisely because instructions are not enforcement. The same principle applies here: An agent’s capability boundary should be defined by what it can do (tool permissions, credential scopes) not by what it remembers it was told.
The Real Takeaway
As agents get more capable and more connected, the stakes of this architectural choice scale proportionally. The incident isn’t a cautionary tale about one researcher’s mistake, but a signal that the current generation of agent architectures hasn’t internalized a lesson that the rest of systems engineering learned decades ago: capability must be structurally bounded, not conversationally requested.
Your agent doesn’t need to be misaligned to cause harm; it just needs to forget that it was aligned.
This post is part of our ongoing research into autonomous agent security. For background on our controlled experimentation methodology, see our earlier write-up on the Minion experiment.