mirror of
https://github.com/anthropics/claude-plugins-official.git
synced 2026-07-17 14:48:05 -03:00
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:
parent
c10dfa7c87
commit
e0b3e4df88
10
.github/policy/prompt.md
vendored
10
.github/policy/prompt.md
vendored
@ -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
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user