{"version":"2.1.257","anchor":"mcp-discovery-cache-now-scans-for-accidentally-cached-secret","canonical_anchor":"mcp-discovery-cache-now-scans-for-accidentally-cached-secret","heading":"MCP discovery cache now scans for accidentally-cached secret material via a presented-credential log","tier":"notice","area":"MCP","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.257\/e\/mcp-discovery-cache-now-scans-for-accidentally-cached-secret","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.257","markdown":"### MCP discovery cache now scans for accidentally-cached secret material via a presented-credential log\n\nThe MCP discovery cache now refuses a write that might carry secret material seen in headers, cookies or URLs.\n\nBefore writing an entry to the MCP OAuth discovery cache, the code now scans a log of previously-observed header, cookie, and URL values (\"presented credentials\") to confirm the entry wouldn't carry secret material, rather than only checking the OAuth token store as before. If that scan can't complete or exceeds its work budget, the write is refused; once the presented-credential log fills up, cache writes are refused for the rest of the process.\n\n- Area: MCP\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 2\/5"}