Epic made custom quest and progression systems publishable in Fortnite, lifting the gate that kept islands built on them in development. Glean added MCP's Tasks and Skills to its assistant, and the W3C Agentic Web group added a threat model for web pages that try to manipulate or track a visitor's agent. Standard Webhooks added a handshake that proves a webhook endpoint agreed to receive events before delivery starts, and Shopify gave app developers a way to test their network-access rules before they ship.
Game modding: Epic makes custom progression systems publishable in Fortnite
Epic made the Progression API generally available, so Fortnite islands built on custom quest and progression systems can now be published to other players. The 43.00 release on November 1 takes the interface creators use to build quests, levels, and unlock tracks out of its experimental stage. Until this release, an island that used it could not be shipped to other players. The same release added scripting features to Verse, Epic's creator language, including events that other code can subscribe to, an experimental timer, and a clock any script can read, and it gave creators a dashboard that reports how their published islands perform.
Why it matters: Epic's creator platform is the layer players use to extend Fortnite into experiences Epic itself never built, and the Progression API is how a creator adds quests and leveling to an island. Now a creator can ship an island that depends on it, widening what reaches Fortnite's audience.
Agents and the web: Glean adds MCP Tasks and Skills, and the W3C Agentic Web group adds a threat model
Glean added support for MCP's Tasks and Skills features to its enterprise assistant. Per the project's client-support matrix (November 3), Glean now supports Tasks, which lets an agent hand a connected service a long-running job and come back later for the result, and Skills, which let a connected service offer reusable capability bundles an agent can load. The matrix lists Tasks support in Claude, Claude Code, the third-party MCPJam inspector, and now Glean; it is community-maintained and does not claim to be complete.
The W3C Agentic Web group added a threat model to its draft charter. This follows the proposal at the W3C's Dublin gathering last week to move WebMCP, the draft that lets a web page offer tools a visitor's agent can call, into a new working group. This week the draft charter gained a section cataloging what a web page can do to an agent that visits it: feed it bad instructions through content other users wrote, block it outright, and waste its time with traps built to stall it. The section also raises how far a site's declared capabilities should be trusted. A W3C staff contributor approved the latest additions on November 5. Separately, WebMCP's editors, whose draft still runs only in Chromium browsers behind an origin trial, added a way for a page to declare the shape of a tool's output to the agent (November 2). The charter has not yet gone to the member vote that would create the group.
Why it matters: Glean now supports the MCP features that turn a one-time request into a standing job an agent can run and return to, which is agent automation reaching a product people use at work. On the browser side, the cross-vendor group that would standardize how a page exposes tools to an agent is still being chartered, and its threat model now names defending the agent from a hostile page as in scope.
Webhooks: Standard Webhooks adds an endpoint-verification handshake
Standard Webhooks added a handshake that lets a sender confirm an endpoint agreed to receive events, and holds the shared secret, before it starts delivering. On October 30 the cross-vendor convention merged the extension: the sender posts a random challenge value to the endpoint, signed like a normal event, and the endpoint proves itself by echoing back a value derived from the signing key. Challenge requests are explicitly not events, so a receiver will not mistake the check for real traffic.
Why it matters: confirming that an address actually wants a sender's events, and can prove it holds the key used to sign them, has been left to each vendor to solve its own way. OpenAI, Anthropic, Twilio, and others already use Standard Webhooks for the format and signing of webhook payloads. A shared way to verify the endpoint itself extends that common ground to the step before the first event is sent.
Marketplace security: Shopify lets developers test an app's network-access rules before shipping
Shopify shipped a preview that lets app developers check, on a test store, which outside servers their app is allowed to contact. The November 4 change reads the list of outside servers and sites an app has declared and warns in the browser console when a storefront page reaches something not on the list. It warns; it does not block. This is the working half of the security package Shopify set out on October 27, which asks apps to declare where they send data as part of tightening the App Store.
Why it matters: a Shopify app runs on the developer's own servers, where Shopify never sees the code, so the platform relies on what an app declares about itself. Giving developers a way to catch an undeclared connection before they ship helps them meet that requirement ahead of the 2027 deadlines, when apps that fall short start losing their listings.
Also worth knowing
- Google landed an on-device decision engine as a flag-gated developer trial in Chrome 157. The Decisions API runs fast, deterministic classification on the device, sorting an input against a fixed set of options in a single pass, the kind of check a page or extension can use to route or validate input without a server round trip. It is turned on only behind a flag, on desktop, and is neither an origin trial nor on by default.
- The W3C WebExtensions group drafted the section of its cross-browser extension standard covering background service workers. The in-progress specification is being filled in piece by piece; this section defines the background process an extension uses to keep working when none of its windows are open.
- QuickJS-ng hardened how it isolates guest code. Version 0.18.0 (November 1) of the small JavaScript engine many products embed to run user-supplied scripts made out-of-memory and internal errors impossible for a guest script to catch, so a misbehaving script can no longer swallow them and keep running.
- CopilotKit locked its in-app assistant interface to a single versioned format. Release 1.84.0 (November 3) requires the generated assistant UI to use one agreed message format and drops the older pre-release shapes, a breaking change aimed at keeping the agent and the interface in sync.
On the radar
- November 9: The WebAssembly Component Model subgroup holds its second meeting.
- November 10: JetBrains holds its Plugin Developer Conference.
- November 12: The W3C WebExtensions Working Group holds its next call.
- November 17: Cloudflare changes a default in how its Workers handle a cancelled request.
- Mid-to-late November: The W3C posts minutes from its Dublin meeting, including the sessions on WebMCP and the browser-extension platform.
- December 1: New Microsoft 365 Copilot Business licenses switch to usage-based billing by default, and Copilot becomes purchasable without a qualifying base subscription.
- December 18: Atlassian stops forwarding Forge's old full-page addresses; apps must move to the unified building block.
- December 31: Cloudflare ends bug and security fixes for the 0.x line of its Sandbox SDK.
- January 1, 2027: Shopify delists public apps still using access credentials that never expire.
This Week in Extensibility is curated by Todd Schiller. Research, drafting, and fact checking are AI-assisted.