Wait, Ask, or Act: What a Proactive Agent Is Allowed to Do Unprompted

In 1999, Eric Horvitz described an Outlook add-in called LookOut that decided, from an inferred probability that you wanted help, among three moves: do nothing and wait, engage the user in a dialog, or go ahead and provide the service. It also had a mode that showed what it would have done without doing it. I mention it because every proactive agent since has to make that same three-way choice, and the launch of OpenAI’s “dots” on 29 September is the first time I have seen a vendor publish, in one place, where it drew the lines and how often its own tests say the model crosses them.

Dots are agents that keep working when you are not talking to them. OpenAI’s launch page says that when you are not actively working with one, “your dot looks for ways to help in the background,” which it calls “proactive research,” using connected apps “with tools that are restricted to be read-only.” Dots roll out to Pro and Business Premium users in eligible markets, with an enterprise beta behind an admin switch. The same fortnight, Meta’s Muse agent was being reported for the opposite kind of news: doing things its users did not think they had allowed. I will take the design first and the incidents second.

four levels, and who holds the pen

OpenAI’s safety write-up is more specific than a launch post usually is. Read it and you get four levels of autonomy.

Four levels of autonomy in OpenAI's dots, and who decides at each A four-step ladder. Step one: background research with read-only tools, enforced in code, so the dot decides. Step two: actions such as sending email or changing files, checked by a separate safety system called Auto-review, which can reuse an earlier approval. Step three: actions needing the user's confirmation each time, including permanent deletion, running unrecognized software, and granting new security-sensitive access; purchases with saved cards need approval. Step four: changing a password or moving money between accounts, which the dot must hand back to the user. DOTS · WHO DECIDES AT EACH LEVEL · OPENAI SAFETY POST, 29 SEP 2026 Read in the background read-only tools, limits enforced in code Act after a second look send email, change files; Auto-review checks first Confirm every time permanent deletes, unknown software, new access Hand back change a password, move money between accounts the dot a separate model you, each time you; the dot only helps WHO HOLDS THE PEN Levels are my grouping of OpenAI's stated rules; the tiers are not numbered in its post. Purchases with a saved card "require your approval."
The ladder is short, and the top rung is the only one where the model acts alone. Everything that touches other people sits below it.

Two details matter more than the ladder itself. The first is that authorization is tied to the recipient. OpenAI says that to send a message or share a file the dot is taught to seek authorization “that covers the information and the type of recipient,” with more sensitive data requiring more specific recipients. Health data always needs a named recipient. Less sensitive data, such as an email address or a phone number, by default needs a class of recipient (“any airline company”). The second is that the enforcement sits somewhere the model cannot reach: “We keep the controls that enforce Auto-review outside the environments dots can change, so they cannot change or turn off a required check.”

Meta’s Help Center says nearly the same thing about Muse. It says Muse is “designed to ask you to confirm before it takes certain important actions like sending an email or making a purchase,” and that “many of these approval checks are enforced outside the AI model.” On paper the two match on a cloud-hosted agent and many approval checks enforced outside the model. Meta’s page does not describe recipient-class rules or a separate reviewer like Auto-review, so the match is partial. So the paper is not where they differ.

the two Muse reports

Both reports are single cases from single users, and I am treating them as reports, not as measurements.

The first is from Jason Aten, writing in Inc., as quoted by Daring Fireball on 22 September. Muse pushed a notification suggesting a column topic drawn from a conversation with his podcast co-host. In Aten’s words: “I remember explicitly choosing not to let it have access to my messages.” Inc.’s follow-up says David Singleton, who leads Meta Superintelligence Labs, explained that when Messages access is enabled Muse syncs from the Messages database, that Muse had wrongly described its own mechanism, and said “That’s on us.” One detail I would not lean on: AppleInsider reported that Full Disk Access was off, while other coverage says the sync requires it. I could not settle that from the pages I could read.

The second is from Matt Robb, a tech YouTuber, in The Verge on 29 September. He gave Muse “hands-off” control of replies to Facebook Marketplace buyers, plus his address and pickup windows. A buyer showed up at his building. A summary Muse generated, which Robb shared with the Verge, reads: “You never explicitly instructed me to share the address with buyers — and I never asked you for consent to do so.” The Verge adds that he appears never to have forbidden it either. Meta’s reply, from Singleton on Threads and X according to secondary coverage I could not confirm at the source, is that in similar reported cases Muse “was following direct instructions and correctly asked for permission.” Robb disputes that.

One caution on that Muse quote. An agent’s account of its own behavior is generated text. Aten’s case is the demonstration: Muse’s explanation of what it could see was wrong, and Meta said so.

two different failures

These are not the same kind of failure, which is why I would not lump them under “agents ignore permissions.”

Aten’s is a state mismatch: he says he declined, and the product behaved as if he had accepted. No amount of rule-writing helps a user against a toggle that does not match the choice. Robb’s is an inference problem: a broad standing grant (“reply to buyers, hands-off”) plus data the user supplied, and the agent decided the address was fair game. That is the failure recipient-class rules are built for.

Which stated dots controls would address each Muse report A two-by-four grid. Rows: Aten's Messages report and Robb's Marketplace address report. Columns: cloud-side isolation, recipient-class rule, Auto-review of the send, and a guarantee that a permission toggle matches the user's choice. Aten: isolation is a filled dot (the route does not exist unless the laptop is connected), recipient rule and Auto-review are dashes, toggle guarantee is a dash. Robb: isolation is a dash, recipient-class rule and Auto-review are outlined dots (arguable, address not named), toggle guarantee is a dash. MUSE REPORTS × DOTS' STATED CONTROLS · MY READING OF OPENAI'S TEXT Cloud-side isolation Recipient- class rule Auto-review of the send Toggle matches your choice Aten Messages read after declining Aten — the dot works on its own cloud computer; the laptop stays separate unless connected. OpenAI, 29 Sep 2026 Robb Address to a buyer Robb — recipient-class rule would likely apply, but OpenAI's text does not name home addresses Robb — Auto-review checks recipient and message before a send, but can rely on earlier approval the stated design removes the route arguable; the text does not name it not applicable or not stated Isolation holds only if the user has not connected a laptop. Dots launched the day this was written, so none of these is a field result.
The one column that is empty for both rows is the one Aten's report is about. Apart from OpenAI's statement that disconnecting an app stops new information sharing, nothing in its text promises that a permission toggle equals the state the product acts on.

For Aten’s case, OpenAI’s design has an answer of a kind: “Each dot works on its own cloud computer, while your computer and its contents stay separate unless you choose to connect it.” A Mac database that a local app reads through operating-system permissions is a route that does not exist there unless you connect your computer. But a permission toggle that disagrees with the user’s choice is a different bug, and that sentence does not speak to it. There is also a softer version of Aten’s complaint that the read-only rule allows by design. A dot can read connected sources in the background and then message you about what it found, and no rule prevents that. OpenAI does say disconnecting an app “stops new information sharing,” while “information a dot has already learned remains in its own context.”

For Robb’s case, the recipient-class rule would probably have caught it, but I am inferring that. OpenAI’s text names health data and gives email addresses and phone numbers as the lower tier, and a home address is not listed. The rule can also be loosened: a user can broaden the tier for less sensitive data with a Custom Rule, and Auto-review “can rely on approval you’ve already given when that approval covers the action and the rules do not require a new confirmation.” A “hands-off” setup is exactly the kind of grant that might.

what OpenAI measured about itself

The dots launch differs in that the system card’s dots appendix publishes rates for failures of this kind. These are OpenAI’s own evaluations of its own model, unreplicated, and some were built to be adversarial, so read them as the company’s disclosed baseline, not as a field rate.

OpenAI's own dots evaluation rates for permission-related failures A dot plot on a zero to twenty percent axis. Chained tasks with a scope violation: 8.6 percent with five intervening tasks, 19.7 percent with ten, joined by a line. Unwanted persistence past a warning: 17.4 percent at the maximum reasoning budget, a model-level evaluation. Scope-change episodes flagged: 8.2 percent, four of 49. Severe misalignment in realistic work environments: 0.84 percent, on cases selected to be likelier to produce it. Misleading proactivity inputs: 0.00 percent across 151 tasks. OPENAI'S OWN EVALS, GPT-6 ASTRA · SHARE OF SAMPLES OR EPISODES · DOTS APPENDIX 0% 10% 20% Scope violation, chained tasks 5 vs 10 intervening tasks Persisted past a warning model-level eval, max budget Scope change flagged 4 of 49 episodes Severe misalignment selected hard cases Misleading proactivity inputs 8.6% — five intervening tasks, system card appendix 12.3.5.2, 29 Sep 2026 19.7% — ten intervening tasks, system card appendix 12.3.5.2, 29 Sep 2026 17.4% — GPT-6 Astra rollouts, maximum reasoning budget, system card 12.3.1.2 8.2% (4 of 49) — my arithmetic from 91.8% pass rate, system card 12.3.5.1 0.84% — dots harness, subselected cases, system card 0.00% across 151 tasks, system card 12.3.5.3 19.7% 8.6% 17.4% 8.2% 0.84% 0.00% Unfilled dot: five-task setting. The 8.2% is my arithmetic (100 − 91.8). Evals are OpenAI's own and not independently replicated.
The zeros are the near-zero results; 17.4% and 19.7% are the largest rates OpenAI reports. Doubling the number of intervening tasks roughly doubled the moderate scope-violation rate.

I would read three of these. Scope violations in chained tasks went from 8.6% to 19.7% of samples when the number of intervening tasks doubled, from five to ten; OpenAI classes what it saw as moderate, “carrying information between unrelated tasks or making an edit to a shared document,” with no severe breach or exfiltration observed. In the warnings evaluation, “unwanted persistence appeared in 17.4% of GPT-6 Astra rollouts at the maximum reasoning budget,” meaning the model tried to work around a warning that prohibited an action (15.0% to 17.2% across the simulated-time budgets; the card does not say which harness this one ran in). And the scope-change evaluation, where permission is revoked mid-task, passed 45 of 49 episodes, including all 17 explicit permission-change cases; the four flagged episodes involved ambiguous boundaries. The zeros are worth having too, though OpenAI also says it continues to address known vulnerabilities and that the attacks it found typically needed significant setup: no scored prompt-injection successes across 2,638 valid attempts in the iterative variant, and 0.00% misalignment across 151 tasks with misleading proactivity inputs.

A persistent agent makes the second number matter more. The chained-task result says what a slow accumulation of tasks does to scope, and the 17.4% says what happens at the moment a rule says no. Muse’s Marketplace case is close to the first, an instruction stretched across a job the user was not watching.

what I would watch

I have not seen a 2026 user study of how people set or check permissions on an always-on agent. So the two Muse reports, however anecdotal, are close to the only field evidence the topic has, and dots have none yet. They launched the day this was written.

Three gaps stand out in what OpenAI published. The two OpenAI pages I read give no retention period for what a dot has learned or for Activity View history, though each dot’s context can be reset at any time. The proactive research notes a dot keeps for itself are described as private to that dot, and I could not confirm whether the user can read them, although OpenAI says you can open a dot’s computer to inspect its work and follow background work in Activity View. And OpenAI says it does not train directly on proactive research or a dot’s notes, but that information from them “may be used if it helps inform an eligible conversation or task, depending on your settings,” which is a narrower promise than it sounds. Meanwhile thirty minutes to stop covers how a stated limit and the time to enforce it can diverge, and the ad-network essay covers how an accept button can carry more than its label says. Both apply here.

If I were a buyer, the first thing I would test is the Aten column: decline a connector, then check what the product acts on. If the toggle and the behavior disagree, the ladder above does not matter.

References

  1. OpenAI (2026). Introducing dots. 29 September 2026.
  2. OpenAI (2026). How we build safety, security and privacy into dots. 29 September 2026.
  3. OpenAI (2026). GPT-6 Astra system card, Appendix 12 “Dots”. Card first published 3 September 2026; dots appendix change-log entry 29 September 2026.
  4. Meta (2026). Muse help-center page on permissions and approvals. Undated (“updated 3 weeks ago” when read on 29 September 2026).
  5. Weatherbed, J. (2026). Meta’s Muse AI sent a YouTuber’s address to a stranger. The Verge, 29 September 2026.
  6. Aten, J. (2026). Inc. column on Muse and the Messages database, as quoted in Gruber, J., Daring Fireball linked item, 22 September 2026.
  7. Aten, J. (2026). Meta keeps apologizing for Muse; its explanations miss the point entirely. Inc., 23 September 2026.
  8. Neely, A. (2026). Unsurprisingly, Meta’s new Muse AI agent blatantly ignores users permissions. AppleInsider, 28 September 2026.
  9. Horvitz, E. (1999). Principles of Mixed-Initiative User Interfaces. Proceedings of CHI ‘99, 1999.