In early May 2026, two architecture briefs began circulating among infrastructure engineers. One describes xAI's GrokBot as an account-level Firecracker microVM — a persistent cloud computer that every bot on that account shares. The other describes Meta's Muse as one isolated Linux VM per user, guarded by a host-side agent called Sentinel that sits on every outbound connection. Neither brief carries a public commit, a pricing page, or a third-party audit. The ledger remembers what the mind forgets — and nothing has been posted to it yet. What exists is a blueprint, not a shipped product. But the blueprint reopens a question the blockchain industry spent a decade grinding through: when a machine holds credentials, who owns the boundary, and at what granularity is trust revoked?
For most of the last three years, an AI agent was a stateless function. You called an API, it returned tokens, the session ended. Credentials lived in your own environment. The attack surface was wide but shallow, because a single prompt-injected response could not persist.
The persistent agent VM changes that arithmetic. Give an agent a browser, a filesystem, and a terminal that survives across sessions, and you have built something structurally closer to a bank account than a chat window. State accumulates. Tokens cache. Session cookies outlive the task that spawned them. The moment an agent can act on the open web and retain memory of what it did, the security model shifts from output filtering to runtime governance. Both briefs converge on the persistent VM and diverge on where they draw the trust boundary. GrokBot draws it at the account. Muse draws it at the individual action. That is not a feature difference. It is a different theory of who is liable when something goes wrong.
The account-level design is the more interesting failure case. If every bot on an account shares one microVM, Firecracker isolates you from other users — it does nothing to isolate your own agents from each other. The brief's own warning, that a bot's screen is not a security boundary, is a liability transfer dressed as documentation. Place a credential on that VM and every agent on the account can reach it. This is the architectural equivalent of a single hot wallet holding every position: convenient, fast, and catastrophic the first time one process is compromised.
Muse's action-level governance is the more defensible pattern, but it is not free. Routing every connector call and network egress through Sentinel turns that agent into a single point of trust and a single point of failure. Credentials injected just-in-time at the network boundary — the agent never sees the raw token — is a sound idea. It is also precisely the session-key model that account abstraction advocates have argued for since 2021: the signer keeps the vault, the executor receives a scoped, expiring capability. The difference is that crypto shipped this pattern on-chain, with revocable keys and public audit trails. Muse's version, on current evidence, is a closed box.
Two things follow. First, the competitive axis is no longer the model — it is the precision of the policy engine. Second, and this is what the briefs bury, the cost model breaks. A long-running VM per user carries virtual-desktop economics, not SaaS economics. CPU, memory, and storage accrue whether the agent is thinking or idle. That is a margin structure no inference API has ever had to carry, and the briefs omit hibernation, snapshotting, and density planning entirely. When I modelled MakerDAO's liquidation cascades in 2020, the lesson was that an economic model which survives calm conditions on paper can still fail on the first volatility spike. A per-user VM with unstated utilization assumptions belongs in the same category.
There is a cross-border dimension the briefs ignore. If an agent can hold currency, settle invoices, or move value across jurisdictions, the governance layer silently becomes the compliance layer. Sentinel does not just control egress — it becomes the KYC chokepoint, the sanctions filter, the audit log. That is a bank's function, and banks are regulated as banks. A host-side agent with unilateral authority over every outbound action is money transmission wearing a security label. Most KYC today is theater, as I have argued before — buying a handful of wallet holdings walks around it — but a runtime that touches settlement rails cannot hide behind onboarding screens. The briefs act as though regulators will not notice. They will.
The comfortable reading is that persistent VMs are the new standard and governance precision is the next moat. I am less sure. The pattern assumes prompt injection stays a bounded problem — that classifiers and human-in-the-loop approval catch the cases that matter. Every audit I have run on browser-based agents says otherwise. The classifier is bypassable, the human approves too fast, and the persistent filesystem retains whatever the agent pulled down before anyone noticed. A long-lived VM does not reduce that risk; it extends the window in which it compounds. Persistence converts a single incident into a stateful liability.
There is a second blind spot. Both designs assume the platform can be trusted with the credential boundary. GrokBot pushes that trust back onto the user with a disclaimer. Muse centralizes it inside Sentinel. Neither lets the user hold their own keys. For a chat product that is fine. For an agent that moves money across borders, it is the custodial-versus-self-custody argument replayed one layer up — and the crypto industry already knows how that ends when the custodian fails.
The persistent agent VM is not a new idea so much as an old one arriving late to a new venue. Stateful accounts, scoped capabilities, revocable keys, audit trails — blockchain custody solved this problem in production, under adversarial conditions, years before these briefs were written. The question for 2026 is whether the AI labs borrow the architecture or rebuild the trust model from scratch and rediscover the failure modes the hard way. The ledger remembers what the mind forgets. Someone should ask the vendors what, exactly, they intend to write into it.
