Sfoglia il codice sorgente

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>
Bryan Thompson 3 mesi fa
parent
commit
e0b3e4df88
1 ha cambiato i file con 10 aggiunte e 0 eliminazioni
  1. 10 0
      .github/policy/prompt.md

+ 10 - 0
.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