Security gap: production agents need cryptographic identity, not just auth tokens

[razashariff]

The current auth providers (JWT, API key, OAuth) handle authentication but none of them solve agent identity verification. The SATP provider (#171) was a step in the right direction but the API it calls is unresponsive.

As mcp-framework moves into production -- home devices, financial tools, multi-agent systems -- this becomes a real liability. An agent controlling someone's home or making payments with only a bearer token and no verifiable identity is a security incident waiting to happen.

What's missing:

• Cryptographic agent identity -- ECDSA key pairs per agent, not shared secrets
• Trust levels (L0-L4) -- graduated access based on verified behaviour, not just "authenticated or not"
• Signed tool responses -- every MCP response signed so the caller can verify integrity and origin
• Sanctions/AML screening -- mandatory for any agent touching financial transactions
• Hash-chained audit trail -- signed, tamper-evident execution history

This isn't theoretical. The OWASP MCP Security Cheat Sheet Section 7 recommends message integrity for MCP communications. Two IETF Internet-Drafts define the protocols:

• draft-sharif-mcps-secure-mcp (per-message signing)
• draft-sharif-agent-payment-trust (agent trust verification)

We've built the implementation -- AgentPass provider, follows the existing AuthProvider pattern, zero deps, live API. Ready to PR when you are.

Raza Sharif
CyberSecAI Ltd | https://cybersecai.co.uk | contact@agentsign.dev

[jagmarques]

Auth tokens answer "are you allowed in" but say nothing about what happened after. A bearer token proving an agent is authorized to call a tool doesn't prove it actually called that tool with those arguments at that time - you just have logs you hope nobody edited. For production agents controlling homes or making payments, you need signed receipts where the signing happens outside the agent's trust boundary so the agent can't forge its own history. Server-side ML-DSA-65 signatures hash-chained to previous actions give you that - verifiable, quantum-resistant, and the agent never touches the signing key. This is the approach asqav takes if you want a reference implementation.