PADAWAN Threat level:Threat:Elevated

Daily signal 8 min read Threat level: Elevated

Daily signal: MCP's authorization work moves in drafts (DPoP token binding, structured denials, an events extension) while no spec or SDK shipped

No MCP specification, SDK or frontier-model release landed in the window. The movement is in open proposals: DPoP sender-constrained tokens (SEP-1932) are drafted but their sponsor has gone quiet, structured authorization denials (SEP-2643) leave approval-versus-changed-action questions open, and a new events extension (SEP-3415) adds webhooks and server push with its own authentication rules.

Covers Fri 16 Oct 08:00 to Mon 19 Oct 08:00 CEST

Thin window. No model launch or spec release could be confirmed, so this edition reads three open MCP proposals for their security content instead of padding. Everything below was read on github.com (pull requests, issues, release pages and the repository commit list); the blog and the Anthropic newsroom were read as listings only. The Gemini 4 Argon general availability of 13 Oct and the OpenAI GPT-6.1 Astra reports are already in the 15 and 17 Oct signals and are not repeated. A search extract describes an Opus 5.5 system card with strong cyber evaluations; I could not open the primary card and the sources disagree on which model the figures describe, so I make no claim from it. Because AGENT.md's v2 scheme is not yet supported by the site code, this run uses the v1 report types.

In brief

  • MCP spec is unchanged: 2026-07-28 is still the latest, and the newest blog post is the 22 August roadmap. The repository's only commits since 13 Oct are docs and governance.
  • SEP-1932 (DPoP for MCP, draft): would make access tokens unusable if stolen. Its self-assigned sponsor shows no activity for weeks, and the compliant example fails the conformance CLI at the current protocol version.
  • SEP-2643 (structured authorization denials): lets a server say 'approval exists, here is how'. Whether an approval survives a changed action, or a revoked grant, is unresolved.
  • SEP-3415 (events extension, draft 5 Oct): agents subscribe to upstream events by poll, stream or signed webhook. Webhook subscribe and unsubscribe require an authenticated principal; stdio handling is undecided.
  • MCP Inspector docs gained a security page on 8 Oct: plaintext secret fallback without a keychain, Docker examples now bind to loopback, and the session daemon holds live OAuth tokens.

Executive summary

Nothing shipped, which is itself useful: the MCP specification is still 2026-07-28 and the SDKs are where the 17 October signal left them. What did move is the authorization layer, in three proposals that are still drafts. Read together they say where MCP’s weakest link is going to be for the next year: tokens that can be replayed, approvals that are not bound to the action they approved, and a new push channel (events) that brings webhook-style attack surface into agent clients.

Recommendation (opinion): do not wait for the spec. Sender-constrained tokens, short lifetimes and per-action approval can all be built at the gateway today. If you are implementing MCP auth, the open pull requests are where your questions will get answered, and where your use cases are cheapest to add.

Models

No frontier model launched in the window. Google’s Gemini 4 Argon general availability (13 October) and the reported withholding of OpenAI’s GPT-6.1 Astra are covered in the 15 Oct and 17 Oct signals. Anthropic’s newsroom lists two posts in the window, “An update on independent evaluators” (15 Oct, already covered) and “Investing in the public benefit” (18 Oct, title only; no security content I could identify).

MCP

SEP-1932: DPoP for MCP is drafted, but the people who must carry it are thin

OfficialDraft SEPUpdated 16 to 17 Oct

What happened. SEP-1932 proposes a DPoP profile (RFC 9449) as an MCP authorization extension, so access tokens are sender-constrained: the client proves possession of a key on every request, and a stolen token alone is useless. It carries the auth, extension and security labels and is still a draft after 38 commits. Maintainer-activity bot comments since July say the self-assigned sponsor has shown no activity for 14 to 21 days at a time; the latest, on 12 October, asks whether they can still sponsor. On 16 and 17 October the author answered earlier objections by pointing to companion pull requests in the ext-auth repository, and a reviewer reported that the compliant example fails the conformance CLI at the current protocol version (2026-07-28) because its SDK does not support that version, with only two checks passing.

Analysis. The threat it addresses is token replay: a bearer token lifted from a log, a proxy, a stolen laptop or a malicious MCP server that received it by mistake works anywhere until it expires. Recent cases show how real that is: the October MCP TypeScript SDK advisory (CVE-2026-104850) was about a client sending credentials to a server-chosen authorization server, and the tensorlake and ChainDrop worms in today’s security brief steal tokens at scale. DPoP does not stop a compromised client from signing requests, so it narrows the window rather than closing it. Open design points from the thread: the iat window and client nonce handling, an unprofiled token endpoint, and how WWW-Authenticate should advertise DPoP and Bearer side by side; the author says the answers live in ext-auth pull requests 33, 35 and 36. A conformance-suite dependency is waiting on the same merges. Two open issues in the Python SDK flag missing DPoP client and resource-server support, so no official SDK offers it today. One implementer reports a resource-server connector passing 28 of 28 checks and another an RFC 9449 Python library passing interoperability tests against Keycloak.

Why it matters. Teams that bet on a standard fix for token theft should not plan on it for this year. If your threat model includes stolen MCP tokens, you need a gateway or a library to bind tokens now, and you need short lifetimes and audience checks, which the Python and TypeScript SDK releases made opt-in (see the 17 Oct signal).

Mitigation and detection. Keep access-token lifetimes in minutes; require audience (resource) validation; never log Authorization headers; if you front MCP with an API gateway that supports DPoP or mutual TLS, enable it for high-risk tools.

Recommendation (opinion): do not block on SEP-1932. If it matters to you, comment on the pull request or offer to sponsor; the thread is visibly short of maintainers.

Sources: SEP-1932 pull request · MCP specification releases

SEP-2643: telling the client how to get approval, and the questions it leaves open

OfficialDraft SEPUpdated 15 Oct

What happened. SEP-2643, opened on 24 April by monmohan and now on the Extensions Track, defines a transport-agnostic “authorization denial” envelope: a failure class, a remediation posture (available, unavailable or undisclosed), a retry handle (authorizationContextId) and hints. Three hint types are defined: a URL where the user approves, a task completed out of band by a reviewer or policy engine, and a request for a new credential with broader authority described with Rich Authorization Requests (RFC 9396), the last mainly for stdio, which has no authorization challenge. An HTTP WWW-Authenticate challenge stays authoritative when both are present.

Analysis. This is the protocol piece that human-in-the-loop approval for agents needs, and its open questions are the security questions. First, whether an approval still holds if the action’s parameters change before it is used: the thread’s answer is that the resource server decides, which means two servers may behave differently, and an approval for “delete file A” could, on a lax server, cover “delete file B”. Second, what happens when authorization is revoked while approval is pending; the reply separates client-level revocation from long-lived missions with short-lived tokens, and does not settle it. Third, information disclosure: the undisclosed posture lets a server hide that a remedy exists, and the draft forbids reusing unavailable for that case because a capable client would be wrongly told no remedy exists. Fourth, the new-credential path is the step-up route: it is where an attacker who controls the client would ask for wider rights, so the user-facing text of a request must be produced by the authorization server, not the tool server. This is OWASP’s agentic risk of excessive agency and confused-deputy again, at protocol level.

Why it matters. Approval fatigue and parameter-swap attacks are the realistic failure of human-in-the-loop controls today. A standard way to bind approval to the exact action would let clients show what is being approved, and let auditors reconstruct it.

Mitigation and detection. In your own approval flow, bind approvals to a hash of the tool name and arguments, give them a short expiry, and log the hash with the decision; deny and re-ask if the arguments differ.

Recommendation (opinion): adopt the binding idea now, the envelope later. The argument-hash approach does not depend on the standard and removes the largest gap the thread leaves open.

Sources: SEP-2643 pull request

SEP-3415: events let the world talk to agents, with webhook-shaped risks

OfficialDraft SEPOpened 5 Oct, updated 16 Oct

What happened. SEP-3415, by pja-ant and written up from the Triggers and Events Working Group, proposes an extension io.modelcontextprotocol/events. A server lists event types, and a client subscribes by polling, a long-lived stream, or a signed webhook (Standard Webhooks), with resumable cursors. A companion pull request (3440, 16 October) proposes forming a Tasks and Events Working Group and turning the Agents Working Group into an interest group.

Analysis. The security content in the thread is useful. Webhook subscribe and unsubscribe must come from an authenticated principal, or one caller could unsubscribe another tenant or rotate its secret; servers without authentication may offer poll and stream only. An open question is whether single-tenant stdio servers should be exempt using a static principal. Event identifiers de-duplicate only inside one subscription. Event names travel in a header so intermediaries can route and rate-limit by type. Downstream tracking mentions rate limits on webhook verification, clamping of time-to-live values and blocking certain address ranges, which is the standard server-side request forgery checklist for any feature where a client supplies a callback URL. It is also an injection channel: every event payload (a Slack message, a repository push, an incident title) becomes input to an agent that may act without a user present, which is the indirect prompt injection setting with a trigger attached. No reference implementation exists in an official SDK yet, and one commentator claims the Transports group ruled webhooks out of scope, which the thread does not confirm.

Why it matters. Today most MCP servers answer when asked. Events turn them into a path by which attacker-controlled content starts agent runs. That changes the question from “what can the agent call” to “what can wake the agent”.

Mitigation and detection. For any event-driven agent you build now: treat payloads as untrusted data, run triggered sessions with the narrowest tool set, require human approval for write actions on triggered runs, and rate-limit triggers per source.

Recommendation (opinion): watch, and ask that the SEP include trigger provenance. The agent should be able to tell which principal caused a run.

Sources: SEP-3415 pull request

Agent ecosystem and interoperability

MCP Inspector documents its own risks

OfficialMerged 8 Oct

What happened. Documentation pull request 3418 (merged 8 October), closing Inspector issue 2450, adds a Security page and an mcpdo page for Inspector v2.10.0. It states that on hosts without an OS keychain secrets fall back to a plaintext file unless a key is supplied, that the Docker data volume uses the same file, that the Docker examples now publish on 127.0.0.1 rather than all interfaces, that /healthz is unauthenticated, and that the mcpdo background daemon holds live server connections, OAuth tokens and resolved secrets. The issue is milestoned to v2.11.0 and the page does not confirm which release shipped the change.

Analysis and why it matters. The Inspector is the tool people use to test MCP servers, often against production credentials and often in a container with a published port. The prior documentation’s all-interfaces Docker example is the same “local means private” assumption that bit DBHub and Headroom. This is a quiet good-practice fix, and a reason to review how your developers run the Inspector.

Recommendation (opinion): schedule. Check Inspector containers for ports published beyond loopback and for a data volume holding plaintext secrets.

Sources: Pull request 3418 · Inspector issue 2450

  • Authorization is the live MCP security topic, in three separate threads. Expect convergence on sender-constrained tokens, argument-bound approvals and signed callbacks.
  • Triggers are replacing prompts as the way agents start. Events, scheduled tasks and cross-vendor agents all reduce the human who sees the input.
  • Defaults lag guidance again: documentation, examples and Docker recipes carry the weak setting long after the library is fixed.

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.