Daily signal: Claude Code 2.1.316 makes the gateway enforce model policy and stops restricted sessions uploading outside the workspace, and MCP's enterprise-auth table merges with vendor claims it did not verify

Executive summary

The level stays elevated, carried by the security brief. The ecosystem news is a day of enforcement moving to the place where it can be audited. Claude Code’s gateway now checks the model a request names, instead of trusting the client to have asked for an allowed one, and a restricted session stops sending files it should not have been able to read. In the protocol process, the enterprise-authorization table is merged with an honest caveat that none of it was tested, and the Events extension, which would let agents act on external triggers while no one is watching, has a review that is producing real security findings before any reference implementation exists.

Claude Code 2.1.316: enforcement at the gateway and in restricted sessions

Official31 OctUpdate · 30 Oct

What happened. The 2.1.316 release notes say the Claude apps gateway now checks every model a request names against availableModels, deniedModels and models, and returns 400 for a blocked model. Team and Enterprise server-managed settings apply without an approval prompt and a stored copy that fails verification is refused. --restricted sessions no longer upload files from outside the working directories when a Read allow rule covered them. Managed autoMode.allow lists without "$defaults" no longer regain built-in exceptions from --settings, /permissions or /auto-mode-setup, cloud sessions and scheduled tasks are marked failed when auto mode stops a turn because the server returned no safety verdict, and plugin MCP headersHelper scripts get a correct CLAUDE_PLUGIN_ROOT and server URL.

Analysis. Three of these are the same lesson as the 2.1.314 fixes covered yesterday: a control was configured and a path sat outside it. The gateway check is a move from client-side to server-side enforcement. Before, a client that named a model outside policy could be stopped only if the client honoured the policy; now the gateway rejects the request, which is the property an auditor can test from the network. The restricted-session fix is a data-boundary case: a Read allow rule meant “the model may read this path”, and the session’s upload step treated it as “this may leave the working directory”. The “no verdict” fixes address fail-open behaviour: an unavailable classifier must read as a stop, not a pass, and now it is recorded as a failure. Dropping the approval prompt for server-managed settings removes a user-facing step but, with the refuse-unverified rule, moves trust to the signature on the stored copy. Preconditions for each are specific (managed deployment, gateway in use, restricted mode); I cannot say from the notes how many sessions were affected, and the notes give no advisory identifiers.

Why it matters. For an organisation that governs coding agents through managed settings, the question is where the policy is enforced. The gateway is the place you can log and test. Client flags and local settings are the place that keeps producing gaps.

Mitigation and detection. Update to 2.1.316. If you use the gateway, send a request naming a denied model and confirm a 400 in the gateway log. For restricted sessions, test that a Read allow rule outside the workspace does not produce an upload. Confirm your managed autoMode.allow list includes "$defaults" on purpose, not by omission. Keep blockWritesOutsideWorkingDirectories from 2.1.314 in your baseline.

Recommendation (opinion): update this week and move policy enforcement to the gateway where you can. Treat each client-side switch as a convenience layer, and write the gateway rejection as a test in your endpoint checklist.

Sources: Claude Code releases · 30 Oct signal

MCP: enterprise-managed authorization gets a table, and Events a security review

Official30 to 31 OctUpdate

What happened. Pull request 3306 (“Document identity provider support for enterprise managed auth”) was merged by a maintainer on 30 Oct. It adds about 46 lines to docs/extensions/auth/enterprise-managed-authorization.mdx: identity providers that can issue ID-JAGs, authorization servers that accept them, a status vocabulary, and a pointer to the community Cross-App Access list. Final commits removed negative and in-progress claims, and an unsourced Entra row was replaced by a statement that major identity providers have no public documentation yet. The 30 Oct signal reported a maintainer asking whether to continue or close it. Separately, SEP-3415 (Events extension, open since 5 Oct) has been updated through 31 Oct with review findings, and the Filesystems working group charter and the Ruby SDK’s Tier 1 post merged without security content; the Ruby post says Tier 1 was granted on a commitment to support the next revision, listed as 2026-12-15, by its release date.

Analysis. On 3306: the table is informational and, by the pull request’s own account, relies on vendor documentation that the project did not verify; the content was drafted by an AI agent and approved by one maintainer. Entries marked as supported are claims, and negative cells were removed, so a reader sees fewer caveats than the earlier draft carried. Enterprise-managed authorization matters because it is how an organisation’s identity provider, not each user’s click, decides which agents may reach which MCP servers (a central control, which is also why a wrong “supported” cell costs a deployment). On SEP-3415: the proposal lets a server push or webhook events to a client so an agent can act when something happens. The review shows the attack surface. Webhook subscription requires an authenticated principal, verification posts use the same SSRF-hardened path as deliveries with no redirects, and an optional ed25519 signature lets a receiver check which server sent an event, with keys that must come from an origin the client already authenticates. A reviewer raised that event IDs placed in an HTTP header can break it if they contain line breaks or are long, plus a secret-encoding mismatch and a plain-hash subscription ID. On 31 Oct a contributor proposed an optional _meta field naming whether an event’s cause was authenticated, asserted or unknown, stating that it grants no authorization and noting that a DMARC-passing message from a compromised mailbox would still show authenticated. That caveat is the main point: provenance labels describe where a signal came from, not whether it is safe to act on, and an agent that treats “authenticated” as “trusted” turns any compromised upstream account into an instruction channel. Open questions remain (eight in the proposal, error codes provisional), and the reference SDK implementation is outstanding. SEP-3149 is open; its review asks whether the client authentication method must stay fixed across the code and refresh grants so a client cannot later drop to a weaker one, and a downgrade-risk note was added.

Why it matters. Events are the mechanism by which prompt injection stops needing a user to be present: a message, issue or alert arrives and an agent acts. Whatever the specification says about provenance and signing will be the floor for every implementation. And a documentation table of “who supports what” will be used as procurement evidence, whatever its caveats.

Mitigation and detection. For enterprise-managed authorization, test your own identity provider and server pairing and do not rely on the table. For event-driven agents (today’s proprietary equivalents included), require that anything an event triggers passes the same approval policy as a typed prompt, treat event content as untrusted data, and log the event source with each action. Watch SEP-3415 for the final text on signing and replay.

Recommendation (opinion): do not plan event-triggered agents with write access until the Events extension settles its provenance and signing text. If you build them now, give them read-only tools by default.

Sources: PR 3306 · SEP-3415 · SEP-3149 · Ruby SDK Tier 1 post