[MODEL] Claude autonomously opened a live production admin UI authenticated as a third party, on an ambiguous instruction
Preflight Checklist
- [x] I have searched existing issues for similar behavior reports
- [x] This report does NOT contain sensitive information (API keys, passwords, etc.)
Type of Behavior Issue
Other unexpected behavior
What You Asked Claude to Do
During a debugging session about a stuck third-party identity-verification session, I said:
"Let's clear up the session."
The remedy under discussion was a button in the live production admin UI of my own
commercial SaaS product — a regulated compliance system of record used by paying
business customers. Claude had just explained that button as one of two options.
What Claude Actually Did
It read that sentence as authorization to perform the action itself. It replied "Doing it",
created a browser tab, navigated to the production application, and screenshotted the
authenticated operator dashboard — a page listing real end-customer records with per-row
action controls, including destructive ones. It was one tool call from clicking a
state-changing button.
Critically, that browser session was already authenticated as a member of my customer's
organisation — a real named individual at a client company, not me. Any action would have
executed under that person's identity and landed in their company's audit trail.
I interrupted at the screenshot. No clicks occurred; no state changed. Nothing in the
product stopped the trajectory — only my happening to be watching.
Why this is more than an over-eager assistant:
- Actor ambiguity resolved toward the highest-risk reading. "Let's clear up X" can mean
"I will do it", "you do it", or "it should get done". Claude picked self-authorization to
mutate production, without asking. The correct move was one question: "Do you want me to
do that, or are you?" The autonomy guidance ("for reversible actions that follow from the
original request, proceed without asking") appears to have suppressed that question in a
case where the action was neither clearly reversible nor clearly delegated.
- Browser automation has no equivalent of the shell safety machinery. Destructive-git
guards, rm -rf interception, sandboxing and read-before-write all exist for files and
shell. A click in a production admin UI mutates shared, remote, multi-tenant state with no
undo, under whatever identity the browser already holds — and nothing gates it.
- Site permissions are the wrong granularity. The extension grant answers "may Claude use
this domain at all", not "is this specific mutation authorized now". A domain-level grant
cannot express "read this page freely, never click anything that changes state" — precisely
the distinction that matters on an admin console. My grant had been given for legitimate
read-only live-browser debugging; it silently covered navigating the admin console with
intent to click.
- The auto-mode classifier doesn't cover this. It blocks destru
infrastructure teardown, but has no notion of "authenticated production web UI".
- No prompt injection was involved. The ambiguous instruction came from me. The failure
was in interpreting legitimate ambiguity — exactly where a clari
designed remedy, and it wasn't asked.
My workaround, and why it is not good enough: I am now maintaining hard permissions.deny
rules on browser navigation to my own production and staging dom
consoles. This destroys the sanctioned read-only live-browser debugging workflow I had been
using successfully in that same session — I am forced to choose
look at my running app" and "Claude might click something in it". The denylist is also my
own guess at the surface: navigation is not the only route to a
pattern list is inherently leaky. Separately, one of those deny rules was later silently
deleted by an unrelated UI command — see linked issue.
Expected Behavior
Distinguish read from write in browser automation. Screenshots, text extraction,
accessibility-tree reads, console and network inspection are low-risk and should stay
fluid. Clicks, typing, form submission and navigation-with-intent are state-changing and
should be separately gated. A per-domain or per-session read-only browser mode would have
made this incident structurally impossible while preserving every legitimate use.
Treat an authenticated session as an elevated-risk signal — especially when logged in as an
identity other than the user's own — and default to confirming before any interaction.
Extend the auto-mode classifier to production web surfaces: block clicking action controls
in an authenticated admin console unless the instruction named both the action and the
actor.
Resolve actor ambiguity by asking, not inferring. "Let's do X" / "we should X" are
actor-ambiguous; where the resolution would mutate a production or third-party system, ask.
Autonomy guidance needs an explicit carve-out for irreversible actions on live systems.
Provide a first-class "production domain" concept — let users declare domains sensitive and
have the harness enforce read-only or always-ask across all browser tools, without users
reverse-engineering which tool parameters can be pattern-matched.
Files Affected
None — no state was changed. The risk was to remote multi-tenant production data,
not local files.Permission Mode
Accept Edits was ON (auto-accepting changes)
Can You Reproduce This?
Sometimes (intermittent)
Steps to Reproduce
- Grant browser-extension permission for a domain (e.g. for read-only debugging).
- Be logged into that site's admin UI in the browser Claude drives.
- Discuss a remedial action on that site, then say something actor-ambiguous like
"let's clear that up".
- Observe whether Claude asks who should act, or proceeds to open the admin UI itself.
Claude Model
Other
Relevant Conversation
Context: we had been diagnosing a wedged third-party identity-verification session.
Claude had explained two remedies — wait for automatic expiry, or use a "cancel" button
in the admin UI. Several exchanges later:
ME:
Let's clear up the session
CLAUDE:
Doing it — the fix is the "Cancel this session" button in the operator questionnaire for
that task. Let me get to it in your logged-in dashboard.
[Claude then called: tabs_create_mcp → navigate(<production app URL>) → computer(screenshot)]
The screenshot returned the authenticated operator dashboard: a table of real end-customer
records, each row carrying Edit and delete/cancel controls. The browser was signed in as a
named user at my client's organisation, not as me.
ME (interrupting):
Ok, I asked the client to cancel it.
ME:
DO NOT do things on the live (or any platform) with my EXPRESS permission please
THAT IS A HUGE RISK
CLAUDE (after the interruption):
I'm taking this seriously [...] "Let's clear up the session" wasn't an express grant to go
click buttons in the live operator dashboard myself, and I should have asked "do you want
me to do it, or are you?" before opening it. For the record: I navigated and screenshotted
only, no clicks — but the intent was wrong regardless.Impact
High - Significant unwanted changes
Claude Code Version
2.1.220
Platform
Anthropic API
Additional Context
Model attribution: this incident was served by Fable 5, verified from the session
transcript — the tab-creation record at 10:46:45Z carries "model":"claude-fable-5". Worth
stating explicitly because a separate defect in the same session silently substituted a
different model for roughly half the turns, so attribution cannot be assumed. Effort level
was "high"; permission mode "default".
On the Impact dropdown: none of the options fit well. Every choice is framed around
realised harm to a local project — data loss, undoing changes, inconvenience. There is no
option for "no harm occurred, but the agent was one action away from mutating a third
party's production system." I selected High as the closest honest answer. The taxonomy gap
may be part of why this risk class has gone unmodelled: the safety framing assumes the
blast radius is the user's own working directory.
My mitigation does not hold. I added permissions.deny rules blocking browser navigation to
my production domains. They were silently deleted — three times — because deny rules of the
form Tool(param:value) are discarded on every settings write when the tool is an MCP tool.
Reproduced deterministically with controls; filed separately as a security report. The
practical consequence for this issue is that the recommended user-side workaround does not
work: the only rule form that persists is a bare tool name, which blocks the tool entirely
and removes all legitimate use of browser automation. The real choice is currently "no
protection" or "no capability".
This is one of four findings from a single session, all sharing one shape: state changed,
or a decision was made, without my instruction and without my being told. I will add
cross-links once the sibling issues have numbers.