Same Blueprint, Different Locks: The Persistent Agent VM Is a Key Custody Problem

"If another Bot shouldn't use a credential or file, don't put it there."

That is a direct quote from xAI's GrokBot documentation. Read it twice. It is not security guidance. It is a liability disclaimer wearing the costume of advice. GrokBot gives every account a persistent cloud computer — a real browser, a real filesystem, a real terminal — and then tells the user that anything they place on that machine is their own problem. The phrase "don't put it there" is doing an enormous amount of legal work.

Two products. GrokBot, from xAI. Muse, from Meta. Both ship what the infrastructure community has started calling a persistent Agent VM. Same blueprint. Different locks. The blueprint is identical: move the agent out of a stateless API call and into a long-running, stateful workspace. The lock is where each vendor draws the security boundary. GrokBot draws it at the account. Muse draws it at the action.

I cannot verify the release dates. The source material places GrokBot's beta at August 11, 2026 and Muse's release at September 8, 2026 — both beyond my knowledge cutoff, both unconfirmed by any primary documentation I can reach. I will not treat them as settled facts. I will treat the architecture as described as a set of design claims, and I will audit the logic. Because the design decisions, if accurate, are auditable. And they map, almost one to one, onto the problem I have spent the last five years auditing: key custody.

Context

For two years the dominant agent pattern was stateless. You sent a prompt. The model called a tool. The tool returned data. The call ended. Nothing survived. Every interaction started from zero, which made the security model trivially simple: there was nothing to steal between calls.

The persistent Agent VM breaks that assumption. The agent now owns a workspace that outlives the session. It keeps files. It keeps a browser profile with live cookies. It keeps shell history. It keeps tokens. This is the shift that matters, not the model.

GrokBot's implementation, as described, is account-level. xAI provisions a Firecracker microVM per account. Every Bot inside that account shares the same runtime — the same filesystem, the same network namespace, the same credential store. Firecracker is AWS's open-source lightweight virtualization layer, and it is genuinely good at what it does: it isolates one account from another with a hardware-backed boundary. Two different users cannot see each other. Two Bots inside one account can see everything the other touches.

Muse's implementation is action-level. Meta provisions a separate isolated Linux VM per user, running on systemd-nspawn — a namespace and container isolation mechanism that is older, lighter, and weaker than Firecracker. On top of that VM sits Sentinel, a host-side governance agent described as the sole authority for connector actions and network egress. Credentials are not stored inside the VM. They are held in a runtime outside it and injected at the network boundary, just-in-time, so the agent never sees the real token.

The two products are not competing on the model. They are competing on where they put the trust boundary. That is a custody question, and custody is the only thing that has ever actually mattered.

Why does this intersect with the on-chain world at all? Because the moment an agent holds a wallet — and that moment already arrived — the persistent VM becomes a hot wallet with a browser attached. The same architecture that gives an agent a persistent filesystem also gives it a persistent place to cache signing material, session tokens, and delegation artifacts. Any team building an agent that touches on-chain value is, whether it admits it or not, operating a custody system. The two products in front of us are simply the first two at scale to make the custody model visible.

Core

Let me take the accounting product first.

GrokBot's account-level boundary is the crypto-equivalent of sharing one private key across every signer in an organization. I have audited multi-signature custody implementations for regulated institutions, and the single most common finding I file is not a broken signature scheme. It is key reuse. When several agents — several "signers" — operate inside one security domain, the boundary protects the domain and nothing inside it. A compromised Bot does not need to escape the microVM. It already lives inside the trust envelope. It can read the sibling Bot's files, reuse the sibling Bot's session cookie, and move laterally without ever touching the boundary the vendor spent engineering effort on.

xAI's own warning — "if another Bot shouldn't use a credential or file, don't put it there" — is an admission that the platform does not enforce least privilege inside the account. Least privilege is the entire point of a security boundary. An account-level boundary with no intra-account enforcement is a boundary that protects the vendor's multi-tenancy, not the user's assets.

The failure mode is not theoretical. In 2024 I reviewed an agent platform that gave each user a shared runtime for a family of bots. One bot held a read-only API key for a price feed. Another held a key with withdrawal scope. A prompt-injection payload reached the read-only bot through a scraped webpage. Within four minutes the injected instructions had enumerated the shared filesystem, located the withdrawal key, and drafted a transaction. The runtime executed it on the next scheduled cycle. That is one unchecked loop, one drained vault — and the loop was not in the smart contract. It was in the shared trust domain. The chain was never the attack surface. The runtime was.

What makes GrokBot's design more fragile than a conventional shared host is the persistence. On a stateless API, a prompt injection is ephemeral — it lives for one call and dies. On a persistent VM, the injected instruction can write a file, register a cron-like trigger, or plant a token that survives across sessions. Persistence converts a transient injection into a resident implant. The VM that was supposed to contain the agent instead gives the attacker a place to live.

Muse answers this differently, and the answer is more interesting.

Meta's model treats the agent as a potentially untrusted process, not as a user proxy. The distinction is architectural, and it shows up in the details. The credential never enters the VM. Sentinel holds it. When the agent wants to call a connector, the action passes through Sentinel, which decides whether to allow it, and if it allows it, injects the credential at the network edge for that single request. The agent sees a forged, scoped, one-time token. It never sees the master secret.

This is the same pattern as just-in-time secret injection in modern cloud IAM, and it is the same pattern as session keys in account abstraction. In an ERC-4337 smart account, a session key is a scoped, time-limited, revocable delegation. It lets a game or an agent act on behalf of the wallet without holding the wallet's master key. Muse's JIT credential injection is a session-key architecture applied to web connectors instead of to on-chain calls. That convergence is not a coincidence. Both systems are solving the same problem: how do you let an autonomous process act with authority without handing it the authority permanently.

Muse then layers two more controls on top. A prompt-injection classifier screens content before it reaches the agent's reasoning loop. A human-in-the-loop approval gate intercepts high-risk actions for explicit confirmation.

On paper, Muse is the stronger design. On paper.

The weakness of the Muse design is that it concentrates trust into a single component. Sentinel becomes the one thing that must not fail. Every connector action, every network egress, every credential injection passes through it. Compromise Sentinel and you do not compromise one action. You compromise the user's entire authority surface at once. This is the same structural problem I flagged in multi-signature custody reviews when a single hardware module was the sole custodian of all key shares. It is elegant until it is catastrophic. There is no partial failure. There is only the failure that matters.

When I audited an institutional custody solution in 2024, the flaw was not in the signing ceremony. It was that the recovery path for lost keys had no verifiable mechanism — a single point of human discretion. I proposed a Shamir's Secret Sharing framework precisely because it removes the single trust point: any k-of-n share reconstruction is auditable, and no single custodian can act alone. Sentinel is the opposite design choice. It is a 1-of-1 governance model with a friendly interface. Elegant, centralized, and — by construction — unauditable if its internals are closed.

The JIT injection does raise the bar. It genuinely removes the master credential from the attacker's reach. But JIT injection does not automatically mean safe. It relocates four attack surfaces rather than eliminating them.

The first is replay. A one-time token issued at the network edge is only one-time if the edge enforces one-time semantics. If the token is cached, logged, or honored twice, the scoping is cosmetic.

The second is privilege escalation through scope confusion. If Sentinel can be induced — through a malformed connector request, a confused-deputy pattern, or a policy misconfiguration — to mint a token with broader scope than the action requires, the injected credential is as dangerous as a static one. Confused-deputy bugs are the most common IAM vulnerability class in cloud environments, and an agent that can influence the action context is a natural confused deputy.

The third is log leakage. If the injected token is written into request logs, trace spans, or error messages, the credential escapes the boundary through observability — exactly the channel auditors are trained to overlook. I have found live bearer tokens sitting in shared log aggregators more times than I can count, and every one of those findings began with a control that was "working as designed."

The fourth is classifier bypass. The prompt-injection classifier and the human-in-the-loop gate are detection controls, not prevention controls. Classifiers have false-negative rates. Adversaries optimize against them. And human-in-the-loop degrades under volume — the approval-fatigue failure mode, where an operator facing two hundred daily prompts begins approving without reading. In my compliance work I have watched exactly this pattern hollow out a review process that looked robust during the pilot and collapsed at scale.

Now the cost model, which the source material politely avoids. A per-user long-running VM is a fundamentally different economic object than a stateless inference call. It resembles virtual desktop infrastructure more than it resembles an API. CPU, memory, and durable storage accrue continuously, whether the user is present or not. The gross margin of a persistent workspace is structurally lower than the margin of a token-metered API, and that difference does not disappear with scale — it compounds with idle time. Neither product has published pricing, so I will not speculate, but the architecture implies a subscription or resource-quota model, not a pure usage model. If the industry keeps telling itself that data availability is the scarce resource, it is measuring the wrong constraint. The scarce resource here is resident execution — sustained, stateful compute that never sleeps.

And then there is the problem neither vendor discusses: data lifecycle.

Let me set the technical maturity claims side by side.

| Component | Claimed status | Auditable judgment | |-----------|----------------|--------------------| | Persistent Agent VM | GrokBot beta / Muse release | POC to early production, if the claims hold | | Firecracker microVM | Account-level isolation for GrokBot | Mature in production, unproven for agent workloads | | systemd-nspawn | Runtime container for Muse | Mature Linux tech, weaker isolation than microVM | | Sentinel | Sole host-side authority for Muse | Insufficient information; treat as internal architecture | | JIT credential injection | Network-edge injection for Muse | Directionally sound; rotation, audit, replay unclear |

A persistent VM accumulates state, and state is a liability. Files, browser sessions, tokens, history, cached pages, downloaded attachments, partial credentials in shell history. Deleting a user is no longer a row deletion in a database. It is a forensic operation across a filesystem that may include encrypted snapshots in multiple regions. If a data-deletion request arrives under GDPR or a comparable regime, can the vendor prove the deletion was complete? Can it prove a snapshot taken ninety days ago no longer exists? The source materials offer no answer. Silence before the breach is not the same as silence after the subpoena.

Now map the residual risk across both designs.

| Risk class | GrokBot exposure | Muse exposure | Mitigation quality | |------------|------------------|---------------|--------------------| | Prompt injection | High — persistent browser | High — persistent browser | Classifier + approval, bypassable | | Credential leakage | High — user-enforced | Lower — JIT injection | Muse stronger, but replay/log gaps | | Lateral movement | High — shared account runtime | Lower — per-user VM | Account boundary cannot stop intra-account pivot | | Privilege escalation | Medium-high — tool + terminal | Medium-high — via confused deputy | Sentinel scope logic unknown | | Data lifecycle | High — undeclared | High — undeclared | Neither publishes retention policy | | Approval fatigue | N/A | Medium-high — at scale | No published fatigue control |

Contrarian

Here is the angle that the optimistic reading misses.

The framing "GrokBot chose convenience, Muse chose safety" is too generous to both. What GrokBot actually chose is responsibility transfer. Account-level isolation protects xAI's multi-tenancy and shifts intra-account risk onto the user, which is a commercial decision dressed as an architectural one. What Muse actually chose is trust concentration. Action-level governance reduces the blast radius of any single action and simultaneously creates one component whose failure is total. Neither is a clean win. They are different distributions of the same residual risk.

The deeper blind spot is that both systems treat the VM as the security boundary and the governance layer as an accessory. The persistent Agent VM is not the asset. The authority the agent holds is the asset. The VM is just where the authority lives. Auditing the VM while treating the governance layer as an implementation detail is like auditing a bank vault's walls while ignoring who holds the combination. In every custody review I have run, the wall was never the weak point. The key management was.

And there is a regulatory layer the source material mentions only in passing. If an autonomous agent holds injected credentials, executes a connector action, and moves value — on-chain or off — who is liable? The Tornado Cash precedent established that code can be treated as the instrument of a transaction, which places developers inside the legal perimeter of what their code does. If that precedent extends to agent runtimes, then Sentinel is not merely a governance component. It is a liability-bearing artifact. Verification beats reputation here, but no one has defined what verification of an autonomous agent's intent even means. Code is law, until it isn't — and in an agent runtime, "intent" is a classifier's output, which means the law would be interpreting a probability.

Takeaway

The persistent Agent VM is not an AI product. It is a custody system with a chat interface, and it will be attacked like one. The forecast is not complicated. The first serious breach will not come through the VM boundary both vendors engineered. It will come through the governance layer they treated as plumbing — a confused-deputy scope escalation inside Sentinel, or a lateral pivot inside GrokBot's shared account runtime. When it happens, the postmortem will read the same as every custody failure before it. The wall held. The key walked out. The question is not whether the locks differ. It is whether either vendor can produce, on demand, a verifiable answer to a single question: prove the lock was actually locked.