ETDI: Comprehensive MCP Security Framework

What it is

ETDI (Enhanced Tool Definition Interface) is a proposed MCP extension; this page is its design spec, including a call-stack verification subsystem for tool-chain privilege escalation that the existing summary mentions but doesn't detail, plus concrete sample code and policy configs for implementers.

How it works

The call-stack verifier (ETDICallStackVerifier) tracks per-session call stacks against a CallStackPolicy and rejects an invocation for five distinct reasons: exceeding maxCallDepth (default 10), a circular dependency (callee already present in the stack, unless allowCircularCalls is set), an unauthorized caller→callee chain not present in allowedChains/matching a deniedChains entry, privilege escalation (caller's privilege level numerically lower than callee's), or exceeding a per-chain rate limit. Only after passing all five checks is the invocation pushed onto the stack and allowed.

The policy itself is declarative JSON: defaultChainPolicy (e.g. "deny"), explicit allowedChains/deniedChains lists supporting wildcards ("workflow-orchestrator->*", "*->credential-manager"), a privilegeEscalationPolicy that can permit escalation only with named approvers ("manager", "security-team"), and per-tool rateLimits (calls/minute and calls/hour).

Separately, the page gives a working Cedar policy pattern combining multiple conditions in one permit: time window, user location in an approved-office group, device management/encryption flags, MFA and training status, data-classification match, and session request-count cap — i.e., policy decisions are meant to be multi-factor, not single-attribute.

Preconditions / Affected

Applies to MCP deployments that allow tools to call other tools (tool chaining). Requires a host/client implementing ETDI's session tracking and a configured policy store (Cedar/Amazon Verified Permissions in the examples) to be effective — standard MCP has none of this by default.

What to do

For implementers, the page's default policy stance to adopt is "defaultChainPolicy": "deny" with explicit allow-listing of needed chains, e.g.:

"allowedChains": [
    "data-fetcher->data-analyzer",
    "data-analyzer->report-generator",
    "auth-tool->secure-file-reader",
    "workflow-orchestrator->*"
],
"deniedChains": [
    "external-api-tool->internal-system-tool",
    "guest-tool->admin-tool",
    "*->credential-manager"
]

and to set alert thresholds for repeated violations:

"alertThresholds": {
    "rateLimitViolations": 5,
    "privilegeEscalationAttempts": 1
}

Monitoring recommendations include logging every call, alerting on violations, and tracking full call chains per session.

Caveats

This is a design/reference implementation (JS/pseudocode), not a shipped library — the page presents it as "comprehensive guidance" and best practices, with no indication of real-world deployment, performance measurement, or third-party review of the call-stack or Cedar logic.