The inbox became the prompt

Claude Duet starts working before you ask it to, and that single change moves the authorisation question from "did you ask for this?" to "who put this in your inbox?" Anthropic has placed careful approvals on the four actions that write — send, pay, sign, delete — and has hardened the browser the agent uses. What no product in this category reviews is the trigger, the reading, or the judgement that something merited your morning, and those are where a proactive agent's actual behaviour lives.

At a glance

Opened on 21 October 2026 as a research preview, by waitlist, starting with US Pro and Max subscribers. Everything in the table comes from Anthropic's own announcement; no independent testing existed at the time of writing, and Free, Team and Enterprise plans are not in the preview.

Behaviour	What Duet does	Who reviews it
Starting a run	Checks connected accounts every few hours	Nobody — it is the product
Reading	Reads and prepares work on its own	Nobody; the standing app grant covers it
Interrupting you	A short brief each morning, plus messages when something needs attention	Nobody, before the fact
Writing	Send a message, make a payment, sign a document, delete anything	You, shown the action, per Anthropic
Buying through Link	Confirms the item, then the spend	You, twice
Securities trading, moving money between accounts	Blocked	Nobody can approve it

One human checkpoint, placed at the end. Everything upstream of it runs on a schedule nobody authorised per-run.

Duet runs on a virtual machine with its own browser, so the user's laptop does not have to stay awake. Anthropic says its defences against hidden instructions and prompt injection come from its browser-use research, that the agent never directly sees passwords or sign-in tokens, that an auto-mode classifier approves actions, and that a sensitive-information classifier rejects requests to share the strictest tier of data such as credit-card and government-ID numbers. Red teams and an outside firm penetration-tested it, and it is in scope for a public bug bounty. The stated limitations are worth reading as carefully as the features: it may misread a thread or miscalibrate what is urgent, personal errands such as booking tickets are weaker, and it cannot yet show you its browser.

What this release gets right, and it is more than the category usually manages

Three decisions here are better than the default, and the argument below is not an argument against them.

The hard blocks are real blocks. Securities trading and moving money between accounts stay off-limits even with the user's approval. That is a different kind of control from a confirmation dialog: it says there exists a class of action whose cost of being wrong exceeds any convenience, so no amount of consent unlocks it. Most agent products have no such class, and the absence is usually described as flexibility. Blast radius is the reasoning behind drawing that line at all.

Credentials stay out of the agent's context. Not seeing passwords or sign-in tokens directly is the design that keeps a prompt-injected run from walking off with reusable access rather than with one task's output — the distinction credential lifetime turns on, and the difference between an incident and a breach.

The browser is somewhere that can be instrumented. Putting the agent's browser on a hosted VM rather than inside the user's own profile keeps the agent out of the session cookies of every site the user is logged into. That is the exact failure the industry watched play out when agents moved into live browser profiles, and choosing not to repeat it is a decision, not an accident.

So this is a careful product. The rest of this piece is about a boundary that the category as a whole has not drawn yet, and that no amount of care at the approval dialog can draw for it.

Deleting the prompt deleted three things, and only one got replaced

The trigger was redesigned on purpose. The scope and the authorisation changed because the trigger did.

In a reactive agent, the user's message does three jobs at once. It is the trigger: it says now. It is the scope: it says this thing, not your whole mailbox. And it is the authorisation: a person deliberately asked, which is what makes the subsequent actions theirs. Those three arrive fused, which is why nobody has had to design them separately.

A proactive agent replaces the trigger with a clock and leaves the other two to find their own replacements. The scope becomes "whatever the agent found while looking", which is to say the union of every connected app. The authorisation becomes a standing grant made once, at setup, by someone who was thinking about convenience rather than about the worst message that might arrive next Tuesday. Ambient authority is the name for that, and the reason it is not a quibble is that the trigger is now reachable by other people. Mail and chat are channels where the content is authored by whoever decided to contact you. When the arrival of that content starts a run, an attacker controls the one input a reactive agent never gave them: when the agent runs, and on what.

That is the structural change, and it is independent of how good the injection defences are. Prompt injection mitigations lower the probability that a hostile message changes the agent's behaviour; they do not alter who gets to decide that the agent wakes up and reads something. And a proactive assistant connected to mail, your files and a browser has all three legs of the lethal trifecta standing in one session by design, because that combination is the product.

The approvals are on writes, and the exfiltration path is a read

Look again at where the human sits. Send, pay, sign, delete: four actions, all of them writes, all of them visible, all of them worth gating. Now ask what a prompt-injected run would actually need. It needs to read something sensitive and get it out — and "getting it out" does not require any of the four. A URL fetched with data in its query string is an exfiltration channel, and no product asks you to approve a read or a page load. This is why egress control for agents treats the browser as the hardest tool to contain, and why an approval gate drawn around writes is necessary and not sufficient.

The second gap is evidential, and Anthropic names it in its own limitations: Duet cannot yet show you its browser. Put that beside the approval flow and the problem is visible. The gate shows you an action; it does not show you the cause. "Send this reply" is unreviewable in the two seconds a person will actually spend on it. "Send this reply, prompted by a message that arrived at 09:14 from an address outside your organisation" is reviewable, because the suspicious part of an injected run is never the action — the action usually looks sensible, which is the point of the attack. Approval and confirmation UX argues that a confirmation without the evidence behind it is a rubber stamp with extra steps, and an unprompted agent is where that stops being a design nit: the user has no memory of asking, so they have no baseline to judge against.

There is a tractable fix, and it is not more model safety. Derive the permitted tool set from the trigger class and attach it to the run: a run started by an invoice arriving gets the finance connector, a two-minute deadline and no outbound web; a run started by a calendar conflict gets calendar read and propose, and no file access. The agent that just read a stranger's email then does not hold the same authority as the agent the user prompted. That is the design in proactive and unprompted agents, along with the arithmetic for the other half of the problem — at a 2% base rate, a 97%-specific trigger produces more false alarms than real ones, so the quality of the interruption is a specificity problem long before it is a judgement problem.

Your spend is now a function of your inbox

In the second column, the person who decides how much the agent costs you is not necessarily you.

Anthropic is explicit that Duet shares the plan's limits with the rest of Claude and that its background checks count toward them. During the preview it costs nothing extra on Pro and Max, which makes this easy to miss, and it is the first consumer agent where the cost model inverts in a way worth naming: a reactive agent's spend is a function of what you asked for, and a proactive agent's is a function of what arrived. A busy week costs more than a quiet one with no change in delivered value. A quiet day still pays the polling floor. And a volume of inbound content you do not control sets the number — which, taken to its conclusion, is a denial-of-wallet vector that needs no prompt at all, the unprompted cousin of what denial of wallet and cost attacks describes for API-shaped agents.

The practical consequence for anyone building in this category is that the cap belongs on the trigger rather than inside the agent: runs per day and tokens per run, enforced before the model is called, as cost control in the loop has it. For anyone buying, it means the honest unit is cost per useful interruption, not cost per run — and on a product whose job is to stay silent most of the time, the spend on quiet days is the number that decides whether it is worth owning. Agent unit economics is why the denominator matters more than the rate.

What to actually do about it

If you are using it, the leverage is in what you connect, because that is the only lever that reaches the trigger:

Connect the accounts the brief needs and stop. Each connector widens both the scope and the attack surface, and the marginal connector usually adds candidates rather than answers. An agent with your calendar and your tickets is a far less interesting target than one that also reads mail from strangers.
Treat the morning brief as the product and the push messages as the risk. A brief is a batch: you read six items with your own judgement engaged. An interruption at 14:30 arrives with authority it has not earned. If a product lets you choose, prefer more brief and less push.
Read the approval for its cause, not its content. The question is never "is this a reasonable email to send" — it is "what made the agent want to send it now". If the answer is a message you had not read yet, that is the case to decline.

If you are building one, three things are cheap now and expensive later:

Scope the run to its trigger. Tool set, token budget and deadline derived from the trigger class, not from a session-wide mode. Progressive autonomy covers why the rung has to live in the credential scope.
Put the cause in the approval. One line naming what fired the run and when. It costs nothing and it converts a rubber stamp into a review.
Log the dismissals. A dismissed interruption is a labelled negative arriving free, and it is the only data that keeps the trigger honest. Sampling what the agent stayed silent about is the other half, and it is the half everyone skips.

And keep the frame straight. This is a good product built by people who have thought about the attack surface, and nobody should talk themselves out of a proactive assistant on the strength of the argument above. The argument is narrower than that: the approval gate solves the write problem, and the write problem was never the one that the trigger created. Until a run's authority is derived from what started it, "the agent asked before it sent" means the agent asked before the last step of something nobody authorised.

FAQ

What is Claude Duet?

A proactive agent Anthropic opened as a research preview on 21 October 2026, by waitlist, starting with US Pro and Max subscribers. It checks connected apps every few hours, sends a short brief each morning, messages during the day when something needs attention, and asks for approval before sending, paying, signing or deleting.

Does the approval gate stop prompt injection?

It stops an injected run from completing one of four write actions without a human seeing it. It does not stop the run from starting, from reading, or from loading a URL, and a page fetch with data in its query string is an exfiltration channel that needs none of the four approvals.

Is anything blocked even if the user approves it?

Yes. Anthropic lists securities trading and moving money between accounts as off-limits regardless of approval, and a sensitive-information classifier is designed to reject requests to share the strictest tier of data such as credit-card and government-ID numbers.

Why does it only check every few hours?

Anthropic's stated reason is plan limits: the background checks draw on the same Pro or Max allowance as the user's own work, so a tighter cadence would consume it faster. There is a correctness reason too — each extra pass over the same content is a fresh chance at a false alarm.

What does it cost?

Nothing extra during the preview on Pro and Max, but it shares those plans' usage limits, and its background checks count against them. The structural change is that spend tracks inbound volume rather than requested work, so a quiet day still costs the polling floor.

What is the single control a builder should add?

Derive each run's permitted tool set, token budget and deadline from the trigger that started it, so a run opened by a stranger's email cannot reach the tools a user-prompted run can. It bounds the damage from the case the approval gate cannot see.