MCP-identity: Per-request cryptographic attestation for MCP servers

MCP-identity addresses a critical architectural blind spot in the Model Context Protocol: the difference between session authorization and intent verification. While OAuth 2.1 confirms that a user is logged in and a service has access, it cannot prove that a specific user intentionally authorized a specific payload—such as a command to delete a database or execute a financial transaction—at a specific moment. By introducing a signature over the exact request body, MCP-identity provides the non-repudiation necessary for high-stakes autonomous agent operations. Technically, the implementation is lean. It leverages an ASGI middleware pattern for Python servers, injecting a verification status into the request scope. The security model relies on a combination of a timestamp window (default 30s) and a nonce store to mitigate replay attacks. The latter is a crucial detail; the project correctly identifies that `InMemoryNonceStore` is insufficient for distributed environments, providing a protocol for Redis integration to maintain consistency across load-balanced instances. The primary friction point is key management. In its v0 state, the library assumes the user can handle local JSON keyfiles, which is a non-starter for mainstream consumer UX but acceptable for the current target audience of developers and security auditors. The 'permissive' mode is a smart product decision, allowing teams to roll out attestation without breaking existing integrations before flipping the switch to 'strict' enforcement. This tool is essential for developers building MCP servers that perform destructive or irreversible actions. If your server is merely reading documentation, this is overkill. If your server is moving money or altering production state on behalf of an LLM, this layer of cryptographic proof is a prerequisite for any serious audit trail.