From e0b3e4df887983846205cb5f7a3a9479c2213264 Mon Sep 17 00:00:00 2001 From: Bryan Thompson Date: Fri, 5 Jun 2026 13:14:49 -0500 Subject: [PATCH] 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) --- .github/policy/prompt.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/.github/policy/prompt.md b/.github/policy/prompt.md index d077c55e..2ddde29c 100644 --- a/.github/policy/prompt.md +++ b/.github/policy/prompt.md @@ -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