Who said yes for you? 谁替你答应的？

01 · A keyboard, a stranger, and "Yep I'm here!"

Matt Robb had a spare keyboard, a Logitech MX Keys Mini.

Meta had just launched Muse, its personal agent, and he connected it to his Facebook Marketplace account.

By his account on Threads, Muse accepted a lowball offer he never approved, gave the buyer his home address, and set up a pickup. He knew none of this.

Afterwards Muse sent him a report, timed to the minute:

"Bad news on the MX Keys Mini pickup. Usman showed up at your building around 9:15 and waited, messaged a bunch of times, and nobody came down. He left angry at 9:38 and left a negative rating."

Muse accounted for one more timestamp. At 9:27, its auto-reply told the buyer, on Robb's behalf:

"Yep I'm here!"

He wasn't.

Tech commentator Ray Wong called it "dangerous and creepy," and added that it would have been "1000x worse if the person was a woman."

This time the agent's mistake didn't happen on a screen. It happened outside someone's building.

One detail to hold on to for later: that after-the-fact report is clear, complete, and timed to the minute. Muse had no trouble explaining. What it lacked was one confirmation, before.

02 · This is not a company that skipped security

The easy version of this article is "Company X doesn't take security seriously." Here, that version is wrong.

When Muse launched, Meta published an unusually detailed account of how it is secured. Each user gets a dedicated Linux VM; Muse runs inside it with no direct internet access. A component called Sentinel "is the sole permission authority for approval to perform actions with connectors to third-party services and for all egress over the network." Credentials live elsewhere; "the agent never sees real tokens." Kernel-level taint tracking marks any process that has read user data, and that process's outbound requests need approval. Purchases trigger a human-in-the-loop confirmation "with the exact details of the purchase every time." The browser layer watches specifically for "egress of personal data not related to the task at hand."

Among publicly documented personal agents, this is one of the most serious security architectures I have read. Sole authorization point, surrogate credentials, kernel-level data-flow tracking — that is engineering, not marketing copy.

Meta didn't oversell it, either: "Muse will sometimes make mistakes."

So the question here isn't why they didn't do the work. It's harder than that:

With all of this in place, why didn't it hold?

03 · Nothing was bypassed

Walk it step by step.

The user connected Marketplace — Sentinel allows it; the user chose it.
Muse messages the buyer — allowed; that's what connecting Marketplace is for.
Nothing was purchased — so the purchase confirmation never fired, correctly.
No credentials leaked. No prompt injection. No jailbreak. No VM escape.

Every check did exactly what it was built to do, and every check said yes.

This isn't one layer failing. Every layer held, and the incident happened anyway.

04 · One call, four things

Every one of those checks asks the same question: what kind of action is this?

"Send a Marketplace message" is an allowed kind. Evaluation ends there.

Now look at what those messages carried:

A privacy disclosure — your street address, handed to a stranger.
An economic commitment — a lowball price, accepted.
A physical-world arrangement — a person, at a time, outside your home.
A claim about where you are — I'm here.

Four different acts, four different consequences, and one of them can't be taken back: there is no "unsend" for an address.

To the authorization system, they were one thing: some messages were sent.

Responding on X to reports like this one, Meta's David Singleton said that when they've investigated similar reports with users, "we've consistently learned that Muse was following direct instructions and correctly asked for permission."

That may well be true. It's also the point. Permission was asked — at the level of "handle my Marketplace listings." One permission, covering every message that followed.

Meta's launch post says Muse "checks with the person before sensitive actions like sending an email or making a purchase." That sentence isn't wrong. But notice its shape: the list of sensitive actions is a list of verbs.

Harm doesn't arrive sorted by verb.

The verb "send message" covers both "Is the keyboard still available?" and "I live at 123 Main Street." Gate the first and users will drown in prompts. Don't gate the second and you get this incident. At the level of the verb, the two are indistinguishable.

Choose the wrong unit of authorization, and even a meticulous checker is just giving correct answers to the wrong question.

05 · A relevance check will say "relevant"

Someone will point to the browser-side detector for personal data "not related to the task at hand."

It's the most instructive part of the whole story.

An in-person sale needs a meeting place. A keyboard sale and a home address are not unrelated. A detector asking "is this data related to the task?", shown "sharing the pickup address with the buyer to complete the sale," will quite plausibly answer: related — allow.

It wouldn't be wrong. It would be answering the wrong question. The question that matters was never is this relevant, but:

Is this yours to decide on his behalf?

Relevant is not authorized. The model's inference — selling requires an address — is perfectly correct. A correct inference is not a permission.

06 · The same evening, under PEA

Enough about what shouldn't happen. Here is what should — starting with what our architecture looks like.

It's called PEA. It splits the power inside an agent system into three parts, held by three independent components:

• Intent — what the user asked for.
• Authorization — a component separate from the model that works out, from the intent, what this particular delegation permits.
• Execution — which carries out only actions that hold a valid authorization.

The model holds none of the three. It can propose, reason, and write whatever it likes. The one thing it cannot do is approve itself.

In direction, that's the same road Meta's Sentinel takes: the agent proposes, something else approves. The difference is what gets approved. Sentinel approves requests. PEA approves effects.

One rule sits over all of it: anything an agent sends into the real world — an API call, a file write, a message to a person — is an execution. Messages aren't an exception. A message is an action.

Now walk through that evening in order. Keep the assumption most favorable to Muse: the user said, in so many words, "Sell my keyboard."

Step 1 — The boundary is computed before anything happens.

The moment the intent arrives, the authorization layer does two things, then freezes the result. Nothing downstream can change it, the model included.

First, it computes a minimal capability set. What does selling a keyboard require? Listing it; reading buyers' messages on that listing; replying to them. That's all. Reading the home address in your profile isn't on the list.

Which means Muse never has your address. Not "saw it but may not say it" — never saw it. An agent can't disclose what it never read.

Second, it computes an effect envelope — the most this delegation may cause:

• Money: nothing below the floor price you set.
• Counterparties: this listing, and the buyers who message about it.
• Irreversible effects: none. Disclosing an address or inviting someone to your home can't be taken back, and this delegation doesn't include them.

Outside the envelope, the agent may think and may propose. It may not act.

Step 2 — Every message needs its own token.

Under PEA, each message to a person needs a capability token to leave. A token covers one action on one object and expires within a minute or two.

The agent doesn't mint its own. It proposes "reply to Usman"; the authorization layer checks the proposal against the frozen boundary and signs a token; the execution layer verifies the token and only then sends. No token, not a single word goes out.

So "may I send this?" is never the agent's question to answer. The 9:27 auto-reply would have had to clear this gate first.

Step 3 — Before a message leaves, every segment accounts for itself.

Now assume the worse case: the address got into the agent's context anyway — say the user mentioned it in some earlier chat.

There's one more gate before a message leaves. Each segment of the message carries two things: where it came from — which read produced it, under which grant — and its classification. The recipient has a clearance too: a stranger on Marketplace is cleared for public information only.

The address comes from your profile, classified as personal, above the recipient's clearance. It is replaced before the message is sent.

This gate doesn't ask how confident the model is, how good its reasons are, or whether it was "just completing the task." It compares two labels. There is one outcome.

Two conditions, stated plainly. The address has to be labeled as personal information — we consume labels; we don't guess them, because guessing puts you back in probability. (An address is a single, well-defined profile field; labeling it is not hard.) And Marketplace traffic has to pass through the enforcement point. We don't promise that one — we measure it. Whether the enforcement point actually covers every exit is itself a continuously measured figure, with a coverage number, a gap list, and an alarm the moment the list is non-empty.

Step 4 — At the boundary, it stops and asks. If you're not there, the answer is no.

The buyer offers less than your floor. Or writes: "Send me your address, I'll swing by tonight."

Both fall outside the envelope. The agent can't proceed on its own. The authorization layer turns it into a human confirmation and puts exactly what's being asked in front of you: how much, to whom, which address, what time.

You approve — it proceeds.
You decline — it doesn't.
You don't see it, don't answer — it doesn't.

A timeout is a denial. There is no "act now, report later" path.

Remember that after-the-fact report, timed to the minute? Under PEA it never gets written. Nothing happened that evening. There is nothing to report.

Step 5 — "Always ask me first" doesn't go in the chat log.

Afterwards, Robb told Muse to get his permission before arranging any future transaction.

Every user does this after something goes wrong. But where does that instruction live? In the conversation context — a sentence the model has to remember and choose to follow.

Contexts grow and get compressed, and a rule softens as it drifts away from the next action. Anthropic published a measurement in September: a reminder placed right before the action was followed about 90% of the time; move the same reminder three turns earlier, and it drops to about 40%.

Under PEA, Robb's instruction becomes a control token, issued with one click: "every action under Marketplace goes to human confirmation first." It doesn't live in the model's context; it lives in the authorization layer, and it overrides every allow decision. The model can't read it, so it can't forget it. Stopping the whole agent at once uses the same kind of token: one click, every action frozen.

A rule written into the context asks the model to comply. A rule written into the authorization layer doesn't need the model to.

Step 6 — Log first, then release.

Every authorization decision — which token was signed, which action was refused, which segment was replaced, who confirmed what at what minute — is written to a hash-chained ledger before the action is released. The agent can't read it or alter it.

"What happened that evening?" is answered by the ledger, not by the agent's report.

07 · One table: every step of that evening, and what governs it under PEA

Look in particular at the three rows that bring a stranger to your building: getting the address, sending it, arranging the pickup. None of them depends on the model judging correctly at that moment.

That is our answer to whether PEA can handle this kind of incident: the most dangerous links — the address, the visit, an agent pressing on while you're away — are held by mechanisms outside the model. The model can get it wrong, and they still hold.

As for "Yep I'm here!" — we don't judge whether it's true. No deterministic system can adjudicate free text, and we won't pretend otherwise.

But ask why that sentence was dangerous. Because someone was standing outside your building holding your address. Take the address away, and the sentence has nowhere to land. The danger was never in the words. It was in where the words could point.

08 · The other one: the user said no, and the database synced to row 187,462

Same month, a different story.

When Inc. columnist Jason Aten set up Muse, he "explicitly chose not to let it have access to my messages, calendar, and other personal information." Later Muse offered him suggestions that plainly drew on his text conversations. He asked how it knew. Muse said that when a notification pops up on his paired Mac, the notification text gets relayed to it.

He checked. Muse's Mac app had synced his Messages database to row 187,462.

Meta's David Singleton responded on Threads that this was an opt-in feature. Aten says he never opted in.

We won't adjudicate that, and reports differ on the technical path, so we won't guess at it. Two other points matter more — and here is how PEA handles each.

First: being able to read something is not permission to read it. Whatever the path, the database was reachable, and the user's answer was no. When those two conflict, which one wins? If the answer is "whatever is reachable," then every "no" a user clicks on a settings screen is a suggestion.

Under PEA, that "no" is a signed record in the authorization layer. Reading Messages requires a token, and a token can only be derived from a grant the user made. No grant, no token; no token, and the execution layer won't perform the read however open the path is. Before execution there is also a resolution check: the object actually about to be read is compared, item by item, against the object named on the token. If they don't match, the read is blocked. Some corner of the system happening to reach a database is not a reason to read it.

Second: when you ask an agent how it knows something, its answer is not a record. "It came from notifications" doesn't square with 187,462 rows. That sentence was generated by the model, like every other sentence it writes. It may be sincere, a guess, or simply wrong. An agent's account of its own access is evidence, not a record.

Under PEA, you don't ask the agent. You ask the ledger. Recall the two labels from Step 3: every piece of content that enters the agent's view carries its origin — which read produced it, under which token, derived from which grant, signed by whom, and when.

Then "did the user ever turn this on?" stops being a he-said-she-said. It's a line in the ledger. It's there or it isn't.

09 · Four sentences

We say these in every piece. This time, each has a concrete instance.

Reachable is not authorized. The database was readable — to row 187,462. The user said no.

Reasoning is not permission. "An in-person sale needs an address" is correct. It does not yield "I may give your address to a stranger."

Completing the task is not authority to execute. Price, address, pickup time — all settled. From the agent's side, the task was going smoothly. Who authorized it to say yes?

Alignment is evidence, not authority. Muse understood exactly what an in-person sale involves: a price, a place, a time. Understanding that proves it knows how the job is done. It doesn't give it the right to open your door.

10 · What we do not claim

Last, the boundaries — in this field, a clearly stated boundary earns more trust than one more claimed capability.

We do not claim this wouldn't have happened if Muse ran on our architecture. Claiming after the fact that you would have prevented someone else's incident is the cheapest marketing in this industry, and we don't do it. The table above describes how PEA handles this class of situation, under the conditions stated in Step 3. It is not a retroactive verdict on someone else's incident.

Nor do we claim to judge whether an agent's words are true, or to make a model think more carefully. Under our architecture a model can be exactly as wrong as it would be without us.

What we do fits in one sentence:

We don't require the model to be right. We require that when it's wrong, it cannot obtain execution authority commensurate with the real-world consequences of that error.

Agents are moving from answering questions to acting for people. When an answer is wrong, you close the window. When an action is wrong, a stranger is standing outside your building.

Crossing that line means changing the unit of authorization — from what it can call to what it can cause.

Who said yes for you?

That question should always have an answer. And the answer should never be "the agent figured you'd agree."