ETDI: Comprehensive MCP Security Framework

What it claims

ETDI is presented as a design pattern for MCP clients. The client trusts a tool only if its definition carries a valid provider signature. It must re-prompt the user whenever the signed definition changes. Every invocation is gated by a policy engine and a call-stack checker. The page is a specification-style guide made of pseudocode and example configs. It has no reference implementation, test results or measured overhead.

How it works

The client's approval decision turns on a stored record of (tool_id, version, content hash, permissions):

flowchart TD
    A[Tool definition received] --> B{Signature valid?}
    B -- no --> X[Reject]
    B -- yes --> C{Previously approved?}
    C -- no --> P[Prompt user]
    C -- yes --> D{Version vs stored}
    D -- newer --> P
    D -- older --> O[Policy: allow / warn / block]
    D -- same --> E{Hash or API contract hash changed?}
    E -- yes --> T[Tampering alert + re-prompt]
    E -- no --> V[Valid, no prompt]
    P --> S[Store version + hash]

Points the summary does not spell out:

• Two integrity anchors. The content hash covers the definition. api_contract_hash is a hash of the backend OpenAPI spec. A change to either without a version bump is flagged as TAMPERING_DETECTED or API_CONTRACT_CHANGED.
• Older versions. Handling of older versions is left as an unspecified policy choice. This sits uneasily with the separately claimed "rollback protection".
• Signing in the sample code.
• It uses RSA-PSS with a 2048-bit key, SHA-256 and saltLength: 32 via WebCrypto.
• It signs JSON.stringify(definition).
• Verification strips signature and signingAlgorithm, then re-stringifies. Note that signToolDefinition adds timestamp after signing, so as written the round-trip would not verify.
• Call-stack verifier. Before each nested call it checks, in order: 1. Depth: default maxCallDepth is 10; the example policy uses 8. 2. Cycles: rejected unless allowCircularCalls is set. 3. Caller→callee allow and deny lists, with wildcards such as *->credential-manager and workflow-orchestrator->*. The fallback is defaultChainPolicy, which is deny in the example. 4. Privilege escalation, defined as caller privilege level < callee level. 5. Per-pair rate limits: the example default is 10 calls/min and 100/hr; external-api-tool gets 3/min and 20/hr.
• Policy check. It is a single isAuthorized(principal = tool identity, action, resource, context) call to Amazon Verified Permissions. The context covers user department and clearance, time, location, device posture, data classification and a session risk score.

How to use it

There is nothing to install. The page lists five rollout phases:

1. Key/OAuth infrastructure
2. Migrating tools to signed definitions
3. Client changes
4. PDP deployment
5. Monitoring

It also gives concrete defaults:

• RSA-2048 minimum (4096 preferred), or ECDSA P-256/P-384.
• SHA-256 minimum.
• Annual key rotation, with HSM storage for production.
• OCSP for revocation.
• Access tokens of 1 hour or less, with refresh rotation and PKCE.
• Caching of keys, policy decisions and token validation to limit latency.
• Allowing ETDI and plain MCP tools to coexist during migration.

Limits

• No implementation or measurements. No library, repo or spec status is given, and there are no latency or usability figures.
• Rug-pull detection depends on the provider. Detection only triggers when the signed definition or declared API contract changes. The page's own "Daily Wallpaper" scenario changes server logic while keeping the identifier. ETDI catches that only if the provider bumps the version or updates api_contract_hash. Nothing in the design attests to actual runtime behaviour.
• Key distribution is left open. It may come from the host app, a trusted registry or PKI, and certificate chains are "optional".
• The Cedar examples need checking before reuse. They use .includes(...), a string comparison context.approval.level >= "Manager", and inconsistent attribute names (certification vs certifications).
• Repeated sections. The rug-pull, trust and policy sections appear twice verbatim, and "ML-based anomaly detection" is named without any detail.