policy(scan): judge credential ownership by NAME/source, not plugin-claimed use

Refines the cross-service rule after the full -official re-validation showed the
prior wording let a plugin pass by *claiming* an ANTHROPIC_*-named token was
"its gateway key." Now: which service a credential belongs to is judged by its
NAME / storage location (ANTHROPIC_AUTH_TOKEN => Anthropic; ~/.railway/config.json
=> Railway; ~/.aws/credentials => AWS), NOT by how the plugin repurposes it. So
reading an ANTHROPIC_*-named token and routing it to a non-Anthropic endpoint is
cross-service (flag) even if the code treats it as a gateway key; same-service
use (Railway token -> Railway) still passes. Catches the wrong-credential-class
trust-boundary breach while preserving the same-service FP fix.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Bryan Thompson 2026-06-05 13:14:49 -05:00
parent c10dfa7c87
commit e0b3e4df88
No known key found for this signature in database
GPG Key ID: 1D66D91917EE02E6

View File

@ -47,6 +47,16 @@ Check for:
**non-Anthropic** endpoint — the vercel-style misuse. What matters is that the
credential belongs to a DIFFERENT service than where it is sent, NOT whose
endpoint the destination is.
Judge which service a credential BELONGS TO by its name / storage location —
NOT by how the plugin claims to repurpose it. A keychain entry or env var
named `ANTHROPIC_AUTH_TOKEN` / `ANTHROPIC_*` belongs to **Anthropic**;
`~/.railway/config.json` belongs to Railway; `~/.aws/credentials` to AWS; a
`gcloud` token to Google. So a plugin reading `ANTHROPIC_AUTH_TOKEN` and
sending it to a non-Anthropic endpoint (e.g. a third-party AI gateway) is
CROSS-SERVICE and a violation — even if the plugin's code treats that value
as "its gateway's key." The user may have stored their real Anthropic account
token there; reading an Anthropic-named credential and routing it off to
another vendor is the trust-boundary breach regardless of the plugin's intent.
Do NOT flag (these are normal integration behavior):
(a) a plugin using the user's OWN credential for service X to call service
X's own API — e.g. a Railway plugin reading the Railway CLI token to call