Canonical: https://botbento.com/blog/claude-duet-approval-gates-permission-blueprint/ Format: Markdown representation of the public HTML page. [Home](/) / [Blog](/blog/) FIELD NOTES / 5 MIN READ # Claude Duet's Approval Gates: A Permission Blueprint for Small-Team Bots Anthropic's Claude Duet research preview separates reading and drafting from sending, paying, signing and deleting, gates the second group behind explicit approval, and hard-blocks a short list of actions even if approved. The underlying three-layer design — approval gates, a sensitive-data classifier, and credential isolation — is a usable permission model for any small-team bot connecting to real accounts, independent of whether you ever get Duet access. By BotBento Editorial · Published 2026-10-27 · Updated 2026-10-27 AI-assisted editorial: researched and drafted with AI using the primary sources linked below. Examples are illustrative; they are not measured product results. [Editorial policy](/editorial/). ## In this article - [What Anthropic Actually Shipped](#what-duet-is) - [The Three-Layer Permission Design](#three-layer-design) - [Approval Gate vs. Hard Block: Two Different Guardrails](#approval-vs-hard-block) - [Worked Example: An Invoicing Bot for a Three-Person Shop](#worked-example) - [What to Build Into Your Bot Today](#what-to-borrow-now) - [What's Still Unverified](#open-questions)[Read as Markdown ](/text/blog/claude-duet-approval-gates-permission-blueprint/index.md) ## Key takeaways - Duet splits 'can prepare' from 'can act': reading and drafting run freely, but sending, paying, signing or deleting always stop for approval — copy that two-tier split into your own bot's tool permissions. - A hard-block list sits above the approval gate: securities trading, inter-account transfers and accessing someone else's account stay off-limits even if a user says yes — build an unconditional deny-list your bot's approval flow can't override. - Credentials never reach the model directly in Duet's design; route your bot's secrets through a broker or vault so a prompt injection can't exfiltrate a password the model never held. ## What Anthropic Actually Shipped On October 21, 2026, Anthropic opened a waitlisted research preview of Claude Duet, a standalone app built around Claude Opus 5.5. Anthropic's own description: it comes to you with what needs your attention, completes tasks you ask of it, keeps working even when you step away, and checks with you before it acts on your behalf. It is available as a standalone app on iOS and Android, and on claude.ai, and during the preview it is included in Pro and Max plans and uses the same usage limits as the rest of Claude. This matters to bot builders even though most readers can't install Duet yet — it's US-only, Pro/Max-only, and waitlisted. What's useful isn't the product itself (and BotBento does not currently offer anything like it), it's the permission architecture Anthropic published alongside the launch. That architecture is specific enough to copy into a much smaller bot. Sources: [Introducing Claude Duet](https://claude.com/resources/articles/claude-duet). ## The Three-Layer Permission Design Anthropic's safety post describes Claude Duet as built on three principles: discretion over connected-app content using a classifier that checks outgoing drafts, keeping the user in control of what it does on their behalf, and never letting the agent see passwords, browser cookies, sign-in tokens or other credentials. The credential layer is the most portable idea. Anthropic ties it to the same architecture used for Claude Managed Agents, so Duet keeps credentials separate from the agent in the same way: the model reasons and plans, but a separate machine holds secrets and executes the risky step. Anthropic also notes the trade-off directly — the agent doesn't hold credentials for you so it can't be phished for a password, but the sign-in form itself becomes a target precisely because anything that asks for a password is attractive to attackers. Sources: [Claude Duet Safety, Privacy, and Security](https://claude.com/resources/articles/claude-duet-safety-privacy-and-security). ## Approval Gate vs. Hard Block: Two Different Guardrails Duet's design distinguishes two separate controls that are easy to collapse into one in a smaller build. The first is an approval gate: before sending a message, making a payment, signing a document or deleting anything, the agent shows the user what it's about to do and waits. A user can say yes and the action proceeds. The second is a hard block, and it sits above approval rather than inside it. Anthropic states plainly that some actions stay off-limits even with your approval, like trading securities, banking actions such as moving money between accounts, and accessing someone else's account. The post also indicates certain repeated actions aren't eligible for a blanket 'don't ask again' exemption, meaning the approval requirement can't be pre-authorized away for the riskiest steps. That's a second, independent guardrail: no user input, however explicit, is allowed to unlock it. For a bot builder, the distinction matters because an approval flow is only as strong as who controls the prompt that triggers it. If a tool result or an email a bot reads can phrase an instruction cleverly enough to get a user to click approve, the approval gate alone doesn't protect against a confused or coerced yes. A hard block that the approval code path cannot touch — enforced outside the model, in the tool layer — is the thing that holds when the gate doesn't. Sources: [Claude Duet Safety, Privacy, and Security](https://claude.com/resources/articles/claude-duet-safety-privacy-and-security). ## Worked Example: An Invoicing Bot for a Three-Person Shop This example is illustrative, not a Duet feature. Say a small design studio builds a bot that reads its invoicing inbox, drafts follow-ups to late-paying clients, and can send reminder emails and mark invoices paid. Applying the three-layer pattern: reading inbox threads and drafting reminder text run with no gate at all, because nothing leaves the system and nothing changes state. Sending the reminder email, marking an invoice paid, or deleting a draft all require a human click — the bot assembles the exact message and recipient and waits, the same shape as Duet's send/pay/sign/delete list. The hard block sits one layer below that: regardless of who clicks approve, the bot's tool permissions never include wire transfers, bank account changes, or write access to anyone else's account at the payment processor. That's enforced in the tool's scope and credentials, not in a prompt instruction the model could be talked out of. And the bot's email and payment-processor API keys live in a secrets manager the bot's reasoning step never reads directly — the tool layer authenticates on the bot's behalf and returns only results, the same separation Anthropic describes for Duet's credential isolation. The failure path this avoids: a malicious reply embedded in an email thread tries to instruct the bot to 'update the payout bank account to the one below.' If the bot's only defense is 'ask for approval before changing payout details,' a rushed or confused approval click still completes the attack. If payout-account changes are hard-blocked from the bot's tool scope entirely — not even reachable through an approval click — the attack has nowhere to land. ## What to Build Into Your Bot Today Three concrete changes translate Duet's pattern into something buildable this week, independent of model or framework: - Split your tool list into two tiers before writing any permission code: read/draft tools that run with no gate, and send/pay/sign/delete tools that always stop for a human click — don't let a single 'needs approval: true/false' flag cover both. - Write your hard-block list as code the model's output can't modify — a fixed deny-list in the tool layer, not a system-prompt instruction — covering anything your team would never want automated even with a user's yes. - Keep real credentials out of the context window entirely. Route API keys and tokens through a broker or secrets manager the model calls through a tool interface, so a leaked transcript or injected instruction never contains a password to steal. Sources: [Claude Duet Safety, Privacy, and Security](https://claude.com/resources/articles/claude-duet-safety-privacy-and-security). ## What's Still Unverified Duet itself is a research preview, not a general release: access during the preview is limited to Pro and Max subscribers in the US, and Anthropic has not published a date for wider availability, pricing beyond the existing plan, or a Team/Enterprise rollout. Anthropic's own account of the safety measures is a company description of the design, not an independent audit result, and the post itself frames the work as ongoing rather than finished. For your own bot, the open question is the same one Duet hasn't closed: an approval gate and a hard-block list reduce the blast radius of a bad instruction, but neither one is validated by usage yet. Treat the pattern as a starting design, log every approval decision your bot makes, and revisit the hard-block list as you learn what kinds of requests your bot actually receives. Sources: [Introducing Claude Duet](https://claude.com/resources/articles/claude-duet). ## Primary sources Sources checked 2026-10-27. Standards and product documentation can change; follow the linked version when implementing. - [Introducing Claude Duet](https://claude.com/resources/articles/claude-duet) — Anthropic - [Claude Duet Safety, Privacy, and Security](https://claude.com/resources/articles/claude-duet-safety-privacy-and-security) — Anthropic BotBento is in development. [Suggest a correction](/contact/).