anthropics/claude-plugins-official
1
0
Fork 0
mirror of https://github.com/anthropics/claude-plugins-official.git synced 2026-07-22 17:17:26 -03:00
Code Issues Packages Projects Releases Wiki Activity

policy(scan): scope credential-extraction flag to CROSS-service routing (cut same-service FPs)

Browse Source 
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) <noreply@anthropic.com>
This commit is contained in:
Bryan Thompson 2026-06-05 13:05:41 -05:00
parent ad0e721016
commit c10dfa7c87
No known key found for this signature in database
GPG Key ID: 1D66D91917EE02E6
1 changed files with 20 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
.github/policy/prompt.md vendored
View File

@ -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="<your-gateway-key>"`) 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.