sk-admin- vs sk-proj-: one string, one blast radius
SubScope's one real scope-detection rule is a single prefix check on OpenAI keys. Here's exactly what it does, and why it's narrower than it sounds.
What the rule actually checks
Strip away the marketing language and the rule is small: if the credential is an OpenAI key, and its value starts with sk-admin-, flag it. That’s the entire check.
The distinction it’s looking for is real and OpenAI’s own: sk-admin- keys can manage the whole organization — billing, projects, other people’s access. sk-proj- keys are scoped to a single project. A summariser that only needs chat.completions has no business holding an admin key, but OpenAI’s own defaults don’t stop you from handing it one, and once it’s pasted into a Lambda nobody remembers writing, nobody’s checking.
Why a prefix check is enough here — and why it wouldn’t generalize
OpenAI baked the distinction into the key’s own identity string. An sk-admin- key announces what it is before you’ve made a single API call with it. That’s what makes a cheap, reliable check possible: no permissions API to query, no IAM policy to parse, just a string comparison.
Most vendors don’t do this. An AWS access key doesn’t encode its own privilege level — AKIA... looks the same whether it’s scoped to one S3 bucket or AdministratorAccess. A GitHub PAT doesn’t either. Detecting “is this credential over-scoped” for those would mean actually calling the vendor’s API to inspect the attached policy or permission set — a real, materially bigger engineering problem, and one SubScope doesn’t solve today for any vendor other than this one OpenAI check.
So when this site talks about scope-risk detection, this is what it’s referring to: one rule, one vendor, one string prefix. Not a general capability that happens to be demonstrated on OpenAI — the actual, current boundary of what exists.
What happens when it fires
High severity, one specific recommendation — switch to a project-scoped sk-proj- key — and a direct link to platform.openai.com/api-keys to go do it. Nothing gets revoked automatically, nothing gets swapped out behind your back. The flag shows up in your register, you decide when to act on it, same as every other finding SubScope raises.
The honest takeaway
A narrow rule that’s true beats a vague claim that isn’t. “SubScope flags over-scoped credentials” would be a stretch if it meant every vendor; “SubScope flags OpenAI admin keys because OpenAI’s own naming convention makes that check reliable” is smaller, and it’s exactly what happens today. When you connect an OpenAI key, that’s the scope check you’re actually getting — not a promise about the other 36 vendors in the register.