SW-MCP-002: Static key authentication instead of OAuth
Last updated 7 November 2026
| Fact | Value |
|---|---|
| Severity | Medium |
| Checks | MCP server |
| Malicious indicator | No |
| OWASP Agentic Top 10 | None mapped |
| OWASP MCP Top 10 | MCP01, MCP07 |
| NIST SP 800-53 | IA-5 (provisional mapping to SP 800-53 base controls) |
| First shipped in | Scanner 0.1.0 |
What it detects
The rule fires when the unauthenticated request was answered with status 401 or 403, the probe found no authorization server metadata that would classify the server, and the server published no protected resource metadata (the document that RFC 9728 describes). The scanner calls that combination static-key authentication: the server wants a credential but gives a client no standard way to obtain one.
The evidence is HTTP 401 without protected resource metadata (or the 403 status that was seen), on the endpoint. A server that answers 401 and does publish resource metadata, but no authorization server metadata, is classified as unknown and is not matched by this rule. A server that answers 200 is SW-MCP-001.
Why it matters
A static key is a long-lived secret that people copy into configuration files, chat messages and shell histories. It does not expire on its own, it cannot be limited to one person or one agent, and revoking it means changing every place it was pasted. The scanner maps this rule to OWASP MCP01, Token Mismanagement & Secret Exposure, and MCP07, Insufficient Authentication & Authorization, and to NIST SP 800-53 control IA-5, Authenticator Management, which asks for authenticators that are issued, rotated and revoked in a managed way.
Example
This recorded probe shows a server that answers 401 with a plain Bearer realm challenge. It names no resource metadata and the probe found no authorization server:
probe.json
{
"endpoint": "https://mcp.example.invalid/mcp",
"reachable": true,
"unauthenticated_status": 401,
"www_authenticate": "Bearer realm=\"mcp\""
}A server check judges what a probe recorded, not files. The recorded probe above is read the way the scanner's README describes under Evaluating an MCP server probe.
How to fix
Move the server to OAuth. Publish protected resource metadata, name an authorization server in it, and let clients register with a Client ID Metadata Document. The migration checklist puts these steps in order. Until then, keep the key in a secret store, scope it to one client and rotate it on a schedule.
If it is a false positive
A server for machine-to-machine traffic inside one team may use a key by design. The finding stays accurate for it, because the rule reads only what the server publishes. Accept it with a note that names where the key is stored and when it is rotated.
If the finding is not a problem in your case, accept it with a note: in the dashboard a manager or owner can accept a finding and the note is kept with it; with the scanner on its own, add it to the baseline file with a reason and an expiry date.