Poppy: Meta en Sierra laten AI-agents voortaan aanbellen. Waar past WebMCP?

Door Enrico Clein · Gepubliceerd 14 oktober 2026 · 10 min lezen

Een AI-agent die namens een klant bij je webwinkel komt, heeft nu twee smaken. Hij logt in met het wachtwoord van de klant en klikt door je site alsof hij die klant is. Of je houdt hem buiten de deur. Amazon koos in september voor het tweede. Ruim twee weken later kwamen Meta en Sierra met een derde smaak: de agent belt aan, zegt wie hij is, en de klant bepaalt hoe ver hij binnen mag. Die afspraak heet Poppy.

Eerst de aanleiding: Amazon zet Muse buiten de deur

Meta lanceerde op 8 september 2026 Muse, een persoonlijke agent die zelf het web op gaat, formulieren invult en onderhandelt. In de nacht van 20 op 21 september blokkeerde Amazon de agent. Volgens Amazon maakte Muse zich niet bekend als AI en kon hij bij accountpagina's en de bestelgeschiedenis.

Op 6 oktober presenteerden Meta en Sierra, het bedrijf van Bret Taylor en Clay Bavor dat klantenservice-agents bouwt, het Personal Agent Protocol. Kortweg Poppy. De officiële site heeft zelfs een knopje dat de uitspraak voordoet.

De specificatie beschrijft het probleem zonder omwegen. Nu is het alles of niets: de agent doet zich voor als de klant, of het bedrijf blokkeert hem. Bedrijven steken steeds meer moeite in agents herkennen, en agents steeds meer in onherkenbaar blijven. Poppy wil daar tussenstappen in brengen.

Wat Poppy is

Poppy is een open protocol voor hoe een persoonlijke agent, die voor één persoon werkt, met een bedrijf samenwerkt. Draft 0.1 staat sinds 9 oktober online, onder de Apache 2.0-licentie en met de bron op GitHub. Het bouwt op standaarden die bedrijven al gebruiken: OAuth voor inloggen, JWT voor ondertekende tokens, en OpenAPI en MCP voor API's. Nieuw is alleen wat nog nergens geregeld was.

Het voorbeeld uit de specificatie maakt het idee concreet. Een luchtvaartmaatschappij laat elke agent vluchten zoeken. Een ingelogde agent mag de reizen van de klant zien. Voor het kopen van een ticket is goedkeuring van de klant nodig. En de klant kan zelf besluiten dat de agent zijn reizen mag bekijken, maar niet wijzigen.

Hoe het werkt: één bestand en drie niveaus

Een bedrijf zet een bestand op een vaste plek: /.well-known/poppy.json. Daarin staat hoe een agent een sessie start, hoe de klant kan inloggen en wat het bedrijf aanbiedt. Dat zijn drie routes, en een bedrijf kiest er één of meer: de website, API's (OpenAPI of een MCP-server), of een eigen agent van het bedrijf waarmee de persoonlijke agent een gesprek voert.

De agent maakt zich altijd bekend. Zijn naam is een webadres met een document erachter: naam, logo en de sleutels waarmee hij ondertekent. Zolang de klant niet is ingelogd, kent het bedrijf die klant alleen als een nummer zonder persoonsgegevens. Dat nummer blijft bij jouw bedrijf hetzelfde, zodat je een terugkerende klant herkent, maar is bij elk bedrijf anders. Bedrijven kunnen klanten zo niet onderling koppelen.

Lezen en wijzigen staan los van elkaar: wie alleen poppy:write heeft, mag niet automatisch meekijken. Een bedrijf kan ook eigen, smallere rechten maken, zoals alleen bezorgadressen beheren.

Inloggen kan op drie manieren. De klant logt zelf in op de inlogpagina van het bedrijf, in de eigen browser of met een link en code op een ander apparaat. Of de agent stuurt de inloggegevens namens de klant door, als het bedrijf dat toestaat. Daarna houdt de agent een sleutel die lang geldig is, zodat de klant niet bij elke taak opnieuw hoeft in te loggen. De klant kan die toegang weer intrekken. Een wachtwoord intypen op je website hoort er niet meer bij: de richtlijnen voor agents zeggen dat letterlijk.

Zo ziet poppy.json eruit

Een webwinkel die agents alleen via de website toelaat, met inloggen op de eigen inlogpagina, kan het zo klein houden:

{
  "protocol_version": "0.1",
  "organization": {
    "name": "Voorbeeldwinkel",
    "domain": "winkel.example"
  },
  "auth": {
    "issuer": "https://auth.winkel.example",
    "direct": {
      "scopes": [
        "poppy:read",
        "poppy:write"
      ]
    }
  },
  "web": {
    "browser_session_endpoint": "https://winkel.example/poppy/browser-session"
  }
}

Met alleen dit bestand ben je er niet. Het inlogsysteem achter issuer moet de standaard OAuth-gegevens publiceren, met een lijst van de domeinen die bij het bedrijf horen. Op het adres van browser_session_endpoint controleert je server een ondertekend bewijs van de agent en zet hij een cookie voor die sessie. Vanaf dan behandelt je website elk verzoek uit die browser als die sessie, met precies de rechten die de klant gaf. Voor een bedrijf met een eigen inlogsysteem is dat werk voor een ontwikkelaar. Voor een winkel op een platform ligt het bij het platform.

Waar WebMCP past

Poppy regelt dus wie er binnenkomt, voor wie hij werkt en wat hij mag. Wat de agent daarna op je pagina doet, regelt het niet. Bij de websiteroute zet Poppy de browser van de agent in de juiste sessie, en daar houdt het op. De agent ziet je site zoals een mens die ziet, en moet zelf uitzoeken welke knop wat doet.

Dat is precies het deel dat WebMCP invult. Met WebMCP registreert een pagina functies voor agents, met een naam, een beschrijving, de invoer en wat er terugkomt. De twee bijten elkaar niet. Een WebMCP-functie draait in de pagina zelf. Vraagt hij iets op bij je server, dan gaat de sessiecookie van die browser mee en controleert je server de rechten, zoals bij elk ander verzoek.

Eén kanttekening hoort erbij. De richtlijnen van Poppy raden agents aan om API's en de eigen agent van een bedrijf te verkiezen boven de website, omdat die sneller zijn en minder vaak veranderen. Voor grote bedrijven met een eigen API is dat logisch. De meeste Nederlandse bedrijven hebben geen publieke API en gaan die ook niet bouwen; waarom niet, lees je in waarom niet gewoon een API. Voor hen blijft de website de route, en maakt WebMCP die website bijna zo voorspelbaar als een API.

Voorbeeld: bestellingen bekijken met de rechten van de klant

Zo werken de twee samen. Deze WebMCP-functie toont de bestellingen van de ingelogde klant. De functie beslist zelf niets over rechten: hij vraagt de bestellingen op bij je eigen server, en die kijkt naar de sessie. Is de klant niet ingelogd, of mag de agent niet meekijken, dan krijgt de agent een duidelijke reden terug in plaats van een foutpagina.

// Recente bestellingen van de ingelogde klant. Alleen opzoeken.
// /api/bestellingen is een voorbeeldnaam. Je server controleert de sessie:
// 401 betekent niet ingelogd, 403 betekent geen recht om mee te kijken.
async function registerRecentOrdersTool() {
  const context = document.modelContext;
  if (typeof context?.registerTool !== "function") {
    return () => {};
  }

  const controller = new AbortController();
  await context.registerTool({
    name: "get_recent_orders",
    description: "Get the status of the signed-in customer's recent orders, or of one order by its order number. Does not change or cancel anything.",
    inputSchema: {
      type: "object",
      properties: {
        orderNumber: { type: "string", description: "Optional order number, for example 2026-10482" },
      },
    },
    annotations: { readOnlyHint: true },
    execute: async ({ orderNumber } = {}) => {
      const url = orderNumber
        ? `/api/bestellingen?${new URLSearchParams({ nummer: orderNumber })}`
        : "/api/bestellingen";
      const response = await fetch(url, {
        headers: { "X-Aanroep": "webmcp" },
      }).catch(() => null);
      if (response?.status === 401) {
        return JSON.stringify({
          status: "sign_in_required",
          reason: "The customer is not signed in. Orders are only shown after they sign in.",
        });
      }
      if (response?.status === 403) {
        return JSON.stringify({
          status: "not_allowed",
          reason: "The customer has not allowed this agent to view their orders.",
        });
      }
      if (!response?.ok) {
        return JSON.stringify({
          status: "unavailable",
          reason: "Orders cannot be loaded right now. The account page shows them too.",
        });
      }
      const { bestellingen } = await response.json();
      return JSON.stringify({
        status: "ok",
        orders: bestellingen.map((b) => ({
          orderNumber: b.nummer,
          status: b.status,
          expectedDelivery: b.leverdatum,
        })),
      });
    },
  }, { signal: controller.signal });

  return () => controller.abort();
}

try {
  // Roep stopOrdersTool() aan als de pagina deze functie niet meer aanbiedt.
  const stopOrdersTool = await registerRecentOrdersTool();
} catch (error) {
  console.error("Registratie van de bestellingentool mislukt", error);
}

Het echte werk zit op je server: die kijkt of de sessie is ingelogd en of de klant poppy:read heeft gegeven. Dat is zonder Poppy niet anders. Een WebMCP-functie is geen toegangscontrole, en een agent die je functies negeert, komt via dezelfde server binnen. Poppy zegt hetzelfde over de eigen agent van een bedrijf: laat elke tool de rechten bij elke aanroep controleren en laat dat niet aan het model over. Meer daarover in WebMCP beveiligen.

Wie er meedoen, en wie niet

Op 14 oktober stonden er 43 namen op de partnerlijst, Meta en Sierra meegerekend. Drie bouwen persoonlijke agents: Instinct, Meta en OpenAI. 21 bedrijven willen agents ontvangen, zoals Walmart, Target, United Airlines, Bank of America en de Spaanse bank BBVA. En 19 technologiepartijen doen mee, waaronder Shopify, Stripe, Visa, Mastercard, Cloudflare, Okta en Zendesk.

Eén Nederlandse naam staat erbij: betaalbedrijf Adyen, dat ook in de technische raad voor betalingen van Google's UCP zit. Opvallend afwezig zijn Google, Microsoft, Apple, Amazon en Anthropic. Google en Microsoft stelden juist WebMCP voor. Shopify zit in beide kampen: het bouwde WebMCP in elke Liquid-winkel en is partner van Poppy.

Wat nog niet vaststaat

Poppy is een draft. Tot versie 1.0 kan elk onderdeel veranderen, ook op manieren die bestaande implementaties breken. Sierra belooft een referentie-implementatie, maar die is er nog niet. Betalingen, pushmeldingen en bijlagen zoals bonnen of retourlabels staan bewust op de lijst met open onderwerpen. Wel is er een eerste uitbreiding, operations, waarmee de klant een actie met gevolgen eerst goedkeurt, zoals een ruil of het opzeggen van een abonnement.

Welke agents Poppy al gebruiken, is niet bekend. Muse, dots en de andere persoonlijke agents werken voorlopig vooral in de Verenigde Staten; zie het signaal persoonlijke agents met eigen browser op de Agentic Web Radar. In de specificatie komt WebMCP niet voor, en in WebMCP komt Poppy niet voor. Hoe agents de twee combineren, moet de praktijk uitwijzen.

Wat je nu doet

Voor de meeste Nederlandse bedrijven valt er vandaag niets te bouwen voor Poppy: er is nog geen agent bekend die het gebruikt, en de specificatie verandert nog. Een paar dingen kun je wel nu al doen. Ze helpen ook zonder Poppy.

Bepaal wat een agent zonder inlog mag. Het advies van Poppy aan bedrijven is helder: laat een uitgelogde agent doen wat een uitgelogde bezoeker ook mag, zoals producten zoeken en het retourbeleid lezen, en beperk misbruik met limieten in plaats van agents te weren. Weert je beveiliging nu alles wat op een agent lijkt, dan sluit je ook klanten buiten; zie je eigen beveiliging weert echte klanten.

Leg de rechten op je server vast, op één plek. Of een verzoek nu van je website, een API of een WebMCP-functie komt: dezelfde controle beslist wat mag. Dan is Poppy later een extra manier van inloggen, geen verbouwing.

Bied één functie aan die alleen iets opzoekt, zoals voorraad, levertijd of de status van een bestelling. Hulp bij de keuze vind je in het praktische besliskader. Werk je op Shopify, let dan vooral op wat Shopify met Poppy gaat doen. Heb je een eigen inlogsysteem en API, lees dan de draft en geef via GitHub feedback, zolang dat nog kan.