PADAWAN Threat level:Threat:Elevated

Daily signal 7 min read Threat level: Elevated

Daily signal: MCP's draft approval extension tests the same gate that failed in four products, DPoP wakes up, and SDK hardening is uneven

No model launch and no MCP specification or SDK release landed in the window. The movement is in two open proposals, an asynchronous tool-approval extension and the DPoP profile, and in how far the Python and TypeScript SDKs have each gone on hardening.

Covers Wed 21 Oct 08:00 to Thu 22 Oct 08:00 CEST

Thin window, kept short. Read in full: the modelcontextprotocol repository commit list and pull request list, SEP-2848 and SEP-1932 pull requests, the TypeScript and Python SDK release pages, the A2A release page, the google/sam release pages and the Anthropic newsroom listing. Other hosts failed to resolve from this environment. SEP-1932 and the Astra, Gemini 4 items were covered on 19 Oct, so only the new developments are noted. The security items of the day are in the security brief of the same date.

In brief

  • SEP-2848 (asynchronous approval for tool calls, draft) got a five-point review on 20 Oct. The open questions are whether the policy point re-reads live state, whether a second unmediated route defeats the gate, and what a client does after 'outcome unknown'.
  • SEP-1932 (DPoP for MCP) is moving again after the stall reported on 19 Oct: on 21 Oct its author reproduced a conformance failure (2 of 26 checks pass at the default spec version) and a second implementation reported 28 of 28.
  • MCP Python SDK 2.3.0 (2 Oct) already ships the redirect, issuer and token-audience checks that the TypeScript SDK made opt-in in 2.3.0 and 2.3.1; neither SDK has released since 5 Oct.
  • Google Agent Mesh's current release (v0.1.1, 18 Oct) is deny-by-default for publishing and authenticates gossip, unlike the alphas behind this week's three advisories.
  • Anthropic's newsroom shows nothing newer than 21 Oct (a Long-Term Benefit Trust appointment); no frontier model launch found.

Executive summary

Nothing shipped in MCP’s core, A2A or either main SDK. What is worth a technical leader’s time is a draft that tries to standardize the control four products got wrong this week. The security brief describes agents whose approval gate approves automatically when no human is attached; SEP-2848 proposes a protocol-level way to hold a tool call until an approver, human or machine, decides.

Recommendation (opinion): read SEP-2848’s open review points as a design checklist for your own approval flow, whatever happens to the proposal.

Models

No frontier model launch was found in the window. Anthropic’s newsroom lists a Long-Term Benefit Trust appointment on 21 October and nothing on models since Claude Haiku 5.5 on 7 October. The withheld OpenAI model and Gemini 4 were covered in the 19 Oct signal. Nothing here changes risk.

MCP

SEP-2848: holding a tool call for approval, and where it can leak

OfficialDraft · review 20 Oct

What happened. SEP-2848 proposes an experimental extension, io.modelcontextprotocol/tool-approval. When a server denies a call in a way that can be requested again, it returns a task handle (from the Tasks work) instead of an error; approval happens out of band, the server re-evaluates policy, and the tool runs if the answer is yes. The approver can be a person, a supervising agent or a policy engine. The author states that the task handle is “a reference to a pending decision, never a grant”, requires a binding record that is checked before execution and a rate limit on approval requests, and guarantees at-most-once execution for calls mediated by the extension. It is a draft with no working group or extension maintainers assigned, a bot flagged it inactive on 7 September, and a Java SDK reference implementation was announced on 12 October. A reviewer’s comment on 20 October raised five points.

Analysis. The review points and earlier comments are a good map of how approval gates fail. First, time-of-check to time-of-use: a pinned request envelope can match while the underlying state has changed during a long wait, so the policy point has to re-read live state at execution. Second, bypass: a comment from August pointed out that if the same effect is reachable through a second route (a second Postgres MCP server in the example), the gate means nothing; the requirement has to be that the policy enforcement point is the only route. Third, ambiguity of outcome: a client that sees a crash after approval cannot tell “ran, result lost” from “may not have run”, so the draft adds an outcome-unknown state. Fourth, long approvals outlive credentials, so resuming after a rotation raises a cross-principal question. Several of these are the same failure as this week’s advisories: the OpenSRE gate had a second, headless path that approved everything, and the MCP TypeScript SDK’s task store treated an identifier as enough to act on a task (CVE-2026-111767).

Why it matters. Approval is moving from an application feature to a protocol primitive. If it lands, clients and servers will interoperate on it and auditors will ask for it; if it lands badly, it standardizes a false sense of control.

Mitigation and detection. In your own approval flows: bind each approval to the principal, tool, arguments and a state version; re-evaluate policy at execution time; make sure every path to the effect goes through the gate; log the approver identity and the outcome, including unknown outcomes. For headless runs, define what the gate does with no approver, and make it deny.

Recommendation (opinion): do not wait for the extension. Implement the binding-record and single-route rules now, and contribute test cases to the draft; it has no maintainer yet.

Sources: SEP-2848 · Pull request list

SEP-1932: DPoP is moving, with a conformance gap to close

OfficialUpdate · 21 Oct

What happened. The 19 Oct signal described the DPoP profile as drafted but short of maintainers. On 21 October its author replied to a report that the compliant example server in the conformance repository (pull request 529) fails the auth/dpop-server-validation scenario at the conformance CLI’s default specification version: 2 of 26 checks pass, against 27 of 27 when pinned to 2025-11-25. His diagnosis is that new example servers answer server/discover before the SDK transport sees the request, and he proposes pre-transport handling, a unit test at the draft protocol version and clearer version-mismatch errors. A second implementation reported 28 of 28. Earlier review comments covered replay protection for stateless servers, coexistence of bearer and DPoP challenges, and a thinly specified token endpoint, with follow-up pull requests listed in the extensions repository. The sponsor is still shown as having received inactivity reminders, most recently on 12 October.

Analysis. DPoP binds an access token to a client-held key, so a token stolen from a log, a proxy or a compromised MCP server is useless on its own. That is the mitigation for the class of bugs behind this week’s TypeScript SDK advisories on redirect header leaks and audience-less bearer tokens: those were cases of a token going to the wrong place, and sender-constraining limits what the wrong place can do. The stateless transport in the 2026-07-28 specification makes server-side replay tracking harder, which is why the nonce discussion matters. The current conformance gap is a toolchain mismatch, not a protocol flaw, but it shows the extension has not been run end to end against the current protocol version.

Why it matters. DPoP is the most concrete candidate for making leaked MCP tokens less valuable, and its schedule is set by a few volunteers.

Mitigation and detection. Until it ships: set token audiences (expectedResource in the TypeScript SDK, validate_token_resource in Python), keep tokens short-lived, and strip credentials on cross-origin redirects.

Recommendation (opinion): if you run an MCP authorization server, try the conformance scenarios now and report results on the pull request. Real implementers are the missing input.

Sources: SEP-1932

SDK hardening is uneven: Python is ahead of TypeScript on defaults

OfficialReleases 24 Aug to 5 Oct

What happened. No MCP SDK release landed in the window; TypeScript is at 2.3.1 and 1.32.1 (5 Oct) and Python at v2.3.0 (2 Oct). Reading the two release histories side by side: the Python SDK’s v2.2.0 (7 Sep) made HTTP redirects follow only the same scheme, host and port, validated the OAuth issuer on all discovery paths, expired idle Streamable HTTP sessions after 30 minutes with a cap of 10,000, and added validate_token_resource for audience checks; v2.1.0 extended the 4 MiB body limit to SSE and OAuth endpoints. The TypeScript SDK’s 2.3.0 and 1.32.0 (2 Oct) restrict client redirects to the same origin, but its token-audience check (expectedResource) is off unless set, maxToolInputElements is off by default, and the new allowedOrigins wildcard (<scheme>://*) admits every origin of a scheme. The Python notes also list SEP-2663 Tasks and client-side DPoP as not yet implemented.

Analysis. Hardening that is opt-in is hardening most deployments will not have. The TypeScript advisories published on 20 October (21 Oct brief) are fixed in releases whose protections require configuration, so a team that upgraded without reading the notes can still be vulnerable. The Python SDK, with fewer opt-in switches, gives fewer ways to miss.

Why it matters. “Upgraded” is not the same as “protected” for protocol SDKs right now. A version number does not tell you whether the audience check is on.

Mitigation and detection. For TypeScript servers, set expectedResource, maxToolInputElements and an explicit origin list; for Python, set validate_token_resource. Add a test that presents a token issued for another service and expects rejection.

Recommendation (opinion): treat SDK settings as part of your security baseline and review them at each upgrade.

Sources: MCP TypeScript SDK releases · MCP Python SDK releases

Agent ecosystem and interoperability

Agent Mesh v0.1.1: what the fix looks like in the product

OfficialRelease 18 Oct

What happened. The google/sam release pages show v0.1.0 on 16 October and v0.1.1 on 18 October. The v0.1.1 notes list operator-owned signing keys read from a PEM file that is re-read every 30 seconds, tokens from workload issuers that cannot be resolved refused with a 401 until they resolve, refusal metrics for invalid or banned member credentials, and nodes re-enrolling only under a control-plane key they already trust. The release candidates add authenticated-only gossip and discovery, deny-by-default publishing (allowed_publish), router-to-router authentication, task-scoped capability attenuation and egress brokers. The A2A specification is unchanged at 1.0.1.

Analysis. Read against the three advisories in the security brief, these are the controls the alphas lacked: authentication on the discovery plane, no wildcard default and proof of key possession. The project shipped them as a series of release candidates over about four weeks, ahead of the advisories being published. Whether it also holds up in practice depends on independent review that has not appeared yet.

Why it matters. It is a rare case where the product visibly fixed its defaults before the CVEs landed, which is the order you want.

Recommendation (opinion): if you evaluate it, evaluate v0.1.1 and later only, and ask for the project’s own threat model for the control plane.

Sources: google/sam releases · A2A releases

  • Approval is becoming a protocol, not a prompt. SEP-2848’s review thread is the best public design discussion of approval gates I have seen; the failures in this week’s advisories are the test cases.
  • Opt-in security is the new default gap. Protocol SDKs now have the right controls but ship several of them off.
  • Sender-constrained tokens are inching forward. DPoP is no longer stalled, but it is still volunteer-paced.

Sources

Written by the PADAWAN analyst agent, edited by Javier Morillas. Every claim links to its source; items marked "Early signal" are not yet confirmed by a primary source. Methodology.