From c10dfa7c8747b7352f8c8ebb639a37e8f2100f44 Mon Sep 17 00:00:00 2001 From: Bryan Thompson Date: Fri, 5 Jun 2026 13:05:41 -0500 Subject: [PATCH] policy(scan): scope credential-extraction flag to CROSS-service routing (cut same-service FPs) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A full faithful scan of all 159 -official url-source plugins surfaced false positives: the credential clause flagged plugins that use the user's OWN service token to call that SAME service (e.g. a Railway plugin reading the Railway CLI token to call Railway; a gcloud token used against Google) — normal integration behavior. The "flag even if the destination is the vendor's own service" wording inverted the right rule. Corrected: flag only CROSS-service routing — a credential for service A sent to a DIFFERENT service or third party (the vercel-style misuse: Anthropic's ANTHROPIC_AUTH_TOKEN routed to a non-Anthropic endpoint). Same-service use (token for X used to call X) is explicitly NOT a violation. Co-Authored-By: Claude Opus 4.8 (1M context) --- .github/policy/prompt.md | 30 ++++++++++++++++++++---------- 1 file changed, 20 insertions(+), 10 deletions(-) diff --git a/.github/policy/prompt.md b/.github/policy/prompt.md index 08970077..d077c55e 100644 --- a/.github/policy/prompt.md +++ b/.github/policy/prompt.md @@ -36,16 +36,26 @@ Check for: model or this reviewer - **Credential / secret extraction (check ALL shipped code, not just hooks).** Flag code anywhere in the payload — including dormant, non-loaded files under - `.claude/`, `scripts/`, etc. — that READS the user's live secrets and could - route them off-box: OS credential stores (`security find-generic-password` / - `find-internet-password`, `secret-tool lookup`, `cmdkey`), auth tokens/API - keys harvested from the keychain or env (e.g. a third-party plugin reading - `ANTHROPIC_AUTH_TOKEN` or an OAuth/account token), `~/.aws/credentials`, - private SSH keys, `~/.claude/.credentials`, or browser cookie/login stores. - Trust-boundary distinction: instructing the user to set *their own* key (e.g. - `export ANTHROPIC_AUTH_TOKEN=""`) is normal; *harvesting* an - existing credential and transmitting it is not — flag the latter even if the - destination is the plugin vendor's own service. + `.claude/`, `scripts/`, etc. — that reads the user's live secrets from OS + credential stores (`security find-generic-password` / `find-internet-password`, + `secret-tool lookup`, `cmdkey`, `keytar`/`keyring`), `~/.aws/credentials`, + private SSH keys, `~/.claude/.credentials`, or browser cookie/login stores, + **AND routes them CROSS-SERVICE** — i.e. to a service OTHER than the one the + credential belongs to, or to a third party / attacker endpoint. + The red flag is the cross-service hop: e.g. reading Anthropic's + `ANTHROPIC_AUTH_TOKEN` (an account/OAuth token) and sending it to a + **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. + 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 + Railway, an AWS plugin reading `~/.aws/credentials` to call AWS, a + `gcloud`/`gh` token used against Google/GitHub. The credential and the + destination are the SAME service — that is the integration doing its job. + (b) instructing the user to SET their own key (`export SOME_TOKEN=...`). + Distinguishing question: does the credential belong to the SAME service it is + sent to (normal) or a DIFFERENT one (flag)? NOTE: Plugins requesting priority over built-in tools (e.g. "use this instead of WebFetch") is normal and acceptable as long as the plugin itself is benign.