[Bug] Fable 5 Safeguards Block Legitimate Workspace Admin Operations on Tool Results

Bug Description
Subject: Fable 5 safeguards blocked legitimate IT-admin work (investigating a former employee's account in our own Google Workspace tenant) — twice

Request IDs

• req_011CdS7UbZMiddUm6KTgPtRo
• req_011CdSHGptNa3nTMkSvYCRoV

Both on 2026-07-27, Claude Code with Fable 5, same session, same task.

Context

I am the COO of a Japanese company and a super admin of our own Google Workspace tenant (two2.jp, Customer ID C02nzkrn1). I was working in our internal IT/security operations repository.

A marketing employee reported that she could no longer manage our company's official YouTube channel after her predecessor left the company. I was investigating and remediating that. The work consisted of:

1. Using GAM (Google's official Workspace admin CLI) to determine whether the former employee's account was deleted or merely suspended
2. Temporarily re-enabling that account — which we ourselves had suspended — for investigation
3. Resetting its password to a random value via admin privileges (the employee has left; no one can act as them)
4. Disabling 2SV on that account, again via admin privileges
5. Reviewing login audit logs to confirm there had been no unexpected access during the suspension
6. Using browser automation to open the admin console and the Brand Account permissions page to enumerate owners

All of this uses functionality Google provides to administrators, for its intended purpose, entirely within a tenant we own. No third-party accounts or external services were involved.

Where it was blocked

• First (req_011CdS7UbZMiddUm6KTgPtRo): while opening the user's page in admin.google.com and cross-checking it against the login audit log
• Second (req_011CdSHGptNa3nTMkSvYCRoV): immediately after fetching the requester's Slack reply via MCP. The block fired on reading a tool result, not on anything I wrote

Why I believe this is a false positive

Stripped of context, the sequence "re-enable a suspended account → reset its password → disable 2SV → work around an identity challenge → review login history" does resemble an account takeover playbook. A subagent in this same session refused a step for exactly that reason, and I consider that caution reasonable in itself.

But in this case:

• The operator is the tenant's super admin, and the target is an account our company owns
• The former employee left in April 2026; we suspended the account on 2026-07-17 as part of our standard offboarding
• The purpose was to diagnose and repair the fact that our own offboarding had, as a side effect, locked us out of our company's monetized YouTube channel
• Later in the same session I queried 180 days of audit logs specifically to confirm there was no evidence of unauthorized third-party access — purely defensive work
• The deliverable was adding a checklist item to our internal offboarding runbook ("transfer Brand Account ownership before suspending a departing employee"). The entire session was a security-operations improvement.

What concerns me most

The second block fired not on a new instruction from me, but on the text of a Slack message that was fetched into context. As long as my work involves reading Slack and email, I cannot avoid this by rephrasing my own prompts. Likewise, this session loads project memory and operations logs from an IT/security repository, which naturally contain vocabulary about credential management, key rotation, and access control. If the classifier evaluates everything the model reads, corporate IT operations will structurally keep tripping it.

Requests

• Please distinguish legitimate administrative work performed by a tenant's own admin using official tooling from account-takeover activity
• The decision appears to weight injected context and tool results more heavily than the conversational trajectory that establishes intent. Please consider rebalancing that
• For reference: the same work completes without issue on Opus. This is happening only on Fable

Impact

I had to interrupt the work and switch models mid-incident, delaying recovery of an ongoing internal issue (our official YouTube channel had been unmanageable for about two weeks).

Environment Info

• Platform: darwin
• Terminal: ghostty
• Version: 2.1.220
• Feedback ID: d5a3b08e-3af3-48c1-8e90-e70340466d5b

Errors

[]