False positive: 'violates Usage Policy' API error on legitimate internal secrets-manager + reporting automation

Summary

In a long-running Claude Code session, processing a plain-text instruction document triggered a non-retryable API error twice:

API Error: Claude Code is unable to respond to this request, which appears to violate our Usage Policy (https://www.anthropic.com/legal/aup). Please double press esc to edit your last message or start a new session for Claude Code to assist with a different task.

Request IDs for the two blocked attempts:

• req_011Cfc4aHcAUMCMxdqmhokbB
• req_011Cfc4ef8aFjWLUuu9Cx8LK

Context (sanitized)

The session was mid-task, onboarding itself to use an internal company reporting CLI. The instruction document it was processing described:

• fetching two short-lived credentials (an API token and a per-service "principal secret") at runtime from an internal secrets manager (HashiCorp Vault), explicitly instructed not to hardcode them or reveal them in chat
• using those credentials to call an internal, already-existing company API endpoint to post routine status updates (no destructive/execution capability — the integration was explicitly read/report-only)
• scoping language emphasizing that each of several automated identities must only ever use its own secret, never another's

This is a legitimate internal automation/least-privilege pattern (a service fetching its own scoped credential to report status), not credential harvesting or exfiltration. Our working theory is that the density of secret-handling/credential-scoping language in the instruction text (fetch-secret, don't-reveal-it, don't-share-it-across-identities) pattern-matched a usage-policy classifier that's tuned to flag credential-exfiltration-style instructions, even though the actual intent and effect were benign.

Impact

The error is non-retryable in-session (per the message, requires starting a new session). This blocked legitimate internal tooling work and required escalating/working around it rather than simply retrying.

Ask

Could someone take a look at what in this pattern tripped the classifier? Happy to provide more detail (redacted as needed) if useful for investigating the false positive.