Add Composio API key detector

[groovyBugify]

Summary

Request to add a detector for Composio API keys. I work at Composio (composio.dev) and am the point of contact for the key formats; a PR with the detector and pattern tests follows.

Key formats

All three types are a fixed prefix followed by URL-safe nanoid characters [A-Za-z0-9_-], no checksum:

• project keys: ak_ + 20 characters
• organization keys: oak_ + 20 characters
• user keys: uak_ + 43 characters

oak_ and uak_ contain ak_, so the project pattern needs a non-alphabet character before the prefix. Keys can end in -, so \b alone misses about 1 in 64 of them; the patterns use an explicit non-alphabet boundary on both sides.

Verification

Not in the first PR. Composio is finalizing a dedicated verification endpoint and will follow up with a second PR that adds it, plus sanctioned test credentials for the integration test through whichever secure channel you prefer.

[shahzadhaider1]

Hey, thanks for submitting the issue and the PR! Really appreciate it.

A couple of things I was wondering about:

• Why didn’t we include the secret verification part in the detector?
• The detector currently detects three different types of Composio keys. Was there a reason we chose to handle all three in a single detector rather than having a separate detector for each key type?
• I’m also interested in seeing your take on the accepted process for secret verification. That might also help us decide whether a single detector makes sense for all the secret types or if we should have separate detectors.

[groovyBugify]

Thanks for the review.

1. Verification is in the PR now (01a1b2d). I left it out of the first cut because the API returns 401 for several unrelated conditions and I wanted to map them from real responses before shipping a verifier that guesses. That mapping is done; the PR description has the table.

2. One detector because the three types share everything except the endpoint and the header. Keywords() is the same for all three (ak_ is a substring of every prefix), so splitting would triple the Aho-Corasick prefilter work for no extra coverage, duplicate the boundary logic that Codex already found a bug in, and need three DetectorType values instead of the one already registered. What differs per type is four fields in a table.

3. The process: each type is sent on the cheapest read-only route it can authenticate, under its own header. 200 is verified. A 401 whose slug is key-specific (APIKey_InvalidAPIKey, APIKey_APIKeyExpired, UserApiKey_Unauthorized, or the org key's HTTP_Unauthorized "Invalid x-org-api-key") means the hash matched no live row: unverified, no error. A 401 naming the key's IP allowlist, or any 403 carrying Composio's error envelope, means the key resolved and a later check refused the request: verified, with the restriction in ExtraData. Everything else (a banned scanner address answers "Access denied", a page without the envelope, 429, 5xx) is left as a verification error rather than a verdict. Only the cloud endpoint and --verifier endpoints are called. I checked the mapping against production with a live and a revoked project key before pushing.

If you would still rather have three detectors after seeing the table, say so and I will split it; the logic would be identical in each.