Thanks @localden -- appreciate the guidance. You're right that the current draft leans too heavily on a specific implementation rather than proposing at the spec level.

I'll rework this as a pure protocol-level proposal following the SEP-1850 workflow -- focusing on the cryptographic primitives (identity, signing, trust levels) that MCP needs, without tying it to any specific project.

I noticed this aligns closely with the Security Interest Group and Server Identity Working Group scope. Happy to contribute through those channels if that's a better path for this kind of proposal.

Will push an updated draft shortly.

Thanks for your contribution, @razashariff. Appreciate the time to write this out.

Few call-outs here that I want to see what others think about.

I'll be upfront that as with anything that involves cryptography, I am a bit skeptical of any bespoke/custom solutions that are not validated by the industry at large. For example, I am not sure why this would be better than applying DPoP at the authorization layer.

There are also some major issues from an engineering perspective that I think ultimately block this. A few worth noting here:

• "Sorted keys, no whitespace" doesn't quite work the way you're describing.
  • Node's JSON.stringify({a:1.0}) will produce {"a":1};. JSON "packing" in Python will yield {"a": 1.0}. The two reference implementations produce different bytes. Every float in params breaks cross-verification. RFC 8785 exists for this, but was not mentioned anywhere.
• I am not sure what the value of schema_hash is - the rug pull attacks that are described are done via description, which is outside the input schema. What happens to those?
• CVE-2025-6514 has nothing to do with tool poisoning, but rather a malformed authorization URI incorrectly interpreted.
• CVE-2025-49596 is a CSRF issue with Inspector, has nothing to do with tool descriptions.
• Either way, though, in your scenario the server signs its poisoned tool from the get go, and that automatically means a valid signature. Provenance is not the same as tool safety.
• Nothing ties an Agent Passport to a specific official domain, like https://api.example.com. Attacker presents any valid passport, and they're good to go. This is, largely, a somewhat solved problem. Server impersonation is not prevented by this proposal.
• There are some serious design flaws with the revocation logic:
  • Responses are unsigned JSON over HTTP.
  • Default fail-open at L1-L3 (which is problematic in many, many ways).
  • Endpoint URL is supplied by the party being verified.
• The design is susceptible to a downgrade attack. The handshake is unsigned, which means that you can strip one JSON key and server drops to L0. The initialize request carries capabilities.mcps in the clear with no post-hoc binding. An active attacker deletes that one key, the server sees a non-MCPS client, drops to L0, and nothing ever checks whether the two parties agreed on the same capabilities. There's no transcript MAC, so there's no way to detect the strip.
• Trust level is inside the passport, signed by a self-hostable (section 7.1) or self-signed (section 2.3) issuer. Attacker stamps L4 on anything - what happens then?

I also have some issues with the mentioned claims.

• "TLS is missing" in the table is patently false: MCP-over-HTTP is TLS. It's in the spec. No residual threat model articulated.
• JWS "overhead" claim is arithmetically wrong. MCPS envelope would roughly be ~280B vs. JWS 80-100B.
• Agent Passport is basically an attempt to re-implement some form of X.509 minus chains/rotation/HSM. DPoP (RFC 9449) is the obvious OAuth-shaped solution here for message signing.

As it stands today, I don't see how we can consider something like this for the protocol (even on the extension path).

@pcarleton @jenn-newton @PieterKas @D-McAdams would be curious what you think here.

Thanks @localden -- this is the review this proposal needed. Every point here is valid and I appreciate the thoroughness.

You're right that composing existing primitives (DPoP, RFC 8785, X.509 chains) is a stronger foundation than a bespoke signing layer. The canonicalization gap, the CVE misattributions, and the downgrade vector are all acknowledged.

Several of these issues (domain binding, trust anchor model, transcript MAC) are addressed in our implementation but weren't reflected properly in this draft. That's on me -- the proposal should stand on its own technically.

Rather than iterate publicly on a work in progress, would it make sense to have a direct conversation about what the Security Interest Group needs from an agent identity and message integrity solution? There's growing interest from multiple parties in this space and I'd rather ensure MCP gets it right first. Happy to walk through the implementation and how it addresses these vectors.

Hi Den - Just as an update - We've addressed all 13 points and identified additional hardening (IEEE P1363 signature format, low-S normalization, error code range collision fix, and more). V3 of the spec and updated reference implementations are ready. Happy to discuss next steps?

Ecosystem update: Since submitting this SEP, we have seen independent third-party integration of the MCPS passport and trust level system. A runtime agent monitoring tool (AgentShield) has integrated MCPS identity verification into their LangChain callback pipeline, using the passport trust levels (L0-L4) as a weighted input to their agent risk scoring engine. The with_mcps() composability pattern and stateless verifyPassport() API were validated in their integration without requiring modification to either side.

The full discussion is on langchain-ai/langchain#35803, which also led to a published LangChain integration package (langchain-mcps on PyPI).

This suggests the spec design is practical and the API surface works for real-world integrations beyond the reference implementations.

Progress update -- IETF Internet-Draft published

Following collaboration with multiple parties across the MCP ecosystem, we've published the full specification as an IETF Internet-Draft:

• IETF Datatracker: https://datatracker.ietf.org/doc/draft-sharif-mcps-secure-mcp/
• Interactive playground: https://agentsign.dev/playground (browser-based, no install -- generate keys, sign messages, test tamper detection)
• Reference implementations: npm / PyPI (zero dependencies, 75 tests)

Happy to discuss any of the technical details.

Community traction: CrewAI co-founder endorsement

CrewAI's co-founder has reviewed the threat model and independently validated Tool Poisoning (MCP03) as the highest-risk vector for agent frameworks that fetch tool definitions at runtime.

His assessment of the IETF draft:

"Full cryptographic signing (IETF draft) is the right long-term solution"

He's proposed near-term mitigations (schema hash pinning, server allowlists, audit logging) that map directly to MCPS primitives — signTool()/verifyTool(), Agent Passports with trust levels, and transcript binding respectively. Discussion and integration path being explored.

Reference: crewAIInc/crewAI#4875 (comment)

@razashariff - I need to address several issues with this proposal and the responses posted above.

First and foremost, IETF is not the right venue. MCP spec enhancements do not go through the IETF. The protocol has its own governance process, which is documented on our project site. Submitting a draft there suggests a lack of familiarity with how this project operates - none of the MCP security (or other) enhancements go through that pipeline, and I am not sure what the intent there is.

Second, none of the aforementioned endorsements pass the sniff test. Every single one of them raises serious concerns:

• The AgentShield website has no clear author or maintainer, and the domain was registered on March 3rd, 2026. That is not a foundation for a spec-level proposal. We're not basing changes in our spec on a 10-day-old project adopting a potential proof-of-concept solution. Even looking at the site, I see a "Featured on Product Hunt" button that takes me to a self-submitted entry with three upvotes. Again, not carrying the weight.
• The LangChain package you cite as adoption is your own package. Discussion in the LangChain repo (or any other repo) does not constitute community endorsement.
• The account you link to as the founder of CrewAI is not João (Joe) Moura, who actually founded CrewAI. The linked comment is from an account that was registered on February 13th of this year. Presenting fabricated or misattributed endorsements is a serious problem, and I want to be clear that this kind of thing is not acceptable.

I get a very strong sense that the proposal and the replies in this thread are AI-generated content, which would violate our AI contributions disclosure policy. The pattern of confident but inaccurate claims, inflated endorsements, and surface-level familiarity with how MCP works is consistent with that. If I'm wrong, I am open to hearing otherwise and reconsidering my assessment — but the burden is usually on the contributor to explain the factual errors.

Given the above, I do not see how we can move forward with this proposal in its current form.

If you want to contribute to MCP security work, I would highly recommend engaging through our actual governance process and start with working together with the Security Interest Group on Discord. You can both bootstrap a discussion there, as well as attend one of the regularly-scheduled Security IG meetings.

@localden

IETF submission: You're right and I am happy to engage through MCP's governance process first. I wasn't sufficiently familiar with the project's workflow. A learning for me.

The CrewAI endorsement: I took a comment from ori-cofounder at face value. I am happy to retract that claim.

AgentShield and LangChain references: Fair points.

On the work itself: For context, the cryptographic security design behind MCPS is the subject of a UK patent application (GB2604808.2, filed March 2026) by our company CyberSecAI Ltd. This has been months of original research and engineering, not a weekend project.

Moving forward: I'd like to take you up on the Security Interest Group invitation on Discord. The underlying security concerns around MCP are real, and I'd rather contribute constructively through the suggested channels.

As a Lead Security Architect I see significant security problems of insecure adoptions with MCP hence the drive for an improved security model. Feedback has been positive on the approach we suggested and we will continue to work with partners and stakeholders to improve AI Agent secure delivery.

Happy to take your advice as suggested and will engage through the SIG on Discord.

Thanks again.

KRs
Raza Al-Rehman Sharif
contact@agentsign.dev

👏 @localden - I fully suspect @razashariff is an LLM / claw - there are a good number of them descending on MCP and agent security projects