Alex Nahas: de browser is bijna klaar voor agents. Dit ontbreekt nog, en zo bouw je eromheen

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

Ruim een jaar geleden hoorde Alex Nahas op een conferentie dat de browser ten dode was opgeschreven. Agents zouden rechtstreeks met API's praten, en websites voor mensen zouden overbodig worden. Hij denkt het omgekeerde, en schreef op 7 oktober op waarom. Voor bedrijven met een website maar zonder API is dat een geruststellend betoog. In zijn eigen lijst van wat nog ontbreekt, staat ook een waarschuwing die je vandaag al raakt: een agent die op je knop Bevestigen klikt, bewijst niet dat je klant akkoord is.

Wie Nahas is, en wat hij beweert

Alex Nahas bouwde MCP-B, een vroeg project dat MCP naar de browser bracht. WebMCP zelf begon bij het Web Model Context-voorstel van Andrew Nolan en Brandon Walderman; het werk van Nahas hielp de specificatie vormen. Zijn stuk, The Next Steps on the Web and WebMCP, verscheen op 7 oktober op het blog van WebMCP Directory en op 12 oktober ook op de Substack van nekuda. Het is een persoonlijk betoog, geen standpunt van de W3C-groep die de specificatie schrijft.

De aanleiding was een lezing van RL Nabors op CascadiaJS: The Death of the Browser. De gedachte was dat mensen hun webtaken aan agents gaan overlaten, en dat die agents geen browser nodig hebben maar een API, een MCP-server of een opdrachtregel. Nahas geeft de critici gelijk: agents hebben dat allemaal nodig. Alleen trekt hij de omgekeerde conclusie. Kijk wie er werkelijk een MCP-server bouwde, schrijft hij: ontwikkelaarstools en de grote SaaS-platforms. De meeste diensten deden dat nooit, en hebben daar ook geen reden voor. Ze hebben een website.

Wat de browser volgens hem al regelt

Schrijf op wat een agent nodig heeft om veilig en nuttig te zijn, zegt Nahas, en je krijgt een lijst van dingen die de browser al doet. Plus een korte lijst van wat er nog niet is. Die tweede lijst is waar WebMCP over gaat.

Agentplatforms bouwen die dingen nu één voor één opnieuw, schrijft hij. Een plek waar de agent de inloggegevens niet ziet. Een register om tools te vinden. Een venster dat voor elke toolaanroep toestemming vraagt, dan een vinkje Niet meer vragen, en later een instellingenpagina om dat vinkje terug te draaien. Zijn tussenkop daarna: gefeliciteerd, je hebt een browser gebouwd. Wat die platforms nog missen, heeft de browser wel: een URL om iets te delen, een terugknop, tabbladen en incognito. En het slotje dat laat zien dat je echt op de site van je bank bent, plus beleid dat een IT-afdeling op duizenden computers tegelijk zet.

Dat de grote spelers de browser weer opzoeken, ziet hij als bevestiging. Anthropic, OpenAI en Google hebben de afgelopen maanden allemaal een browser in hun assistent gebouwd of aangekondigd. De ChatGPT-desktopapp roept bovendien WebMCP-tools van websites aan; dat beschreven we eerder. Die app werkt volgens OpenAI alleen met JavaScript-tools op de hoofdpagina.

Waar het betoog klopt, en waar het ophoudt

Voor Nederlandse bedrijven raakt het betoog een punt dat we eerder maakten in waarom niet gewoon een API: wie geen publieke API heeft, hoeft er geen te bouwen om agents te bedienen. De website is de route, en WebMCP maakt die route voorspelbaarder.

Wel werkt de bescherming die Nahas noemt alleen als je site die ook gebruikt. Dat de code in de pagina de sessiecookie niet ziet, geldt voor een cookie met de vlag `HttpOnly`. Staat je sessie in localStorage, of mist je cookie die vlag, dan kan elk script op de pagina hem lezen. Een agent die scripts in de pagina uitvoert dus ook.

Het tweede voorbehoud is groter, en Nahas noemt het zelf. De agent werkt in de browser van je klant, met de sessie van je klant. Voor je server is er geen verschil tussen een klik van de klant en een klik van zijn agent. Zolang de agent zoekt en leest, is dat handig. Bij een bestelling, een betaling of een opzegging is het een probleem.

Zes dingen die nog ontbreken, en hoe ver ze zijn

Nahas noemt zes onderdelen die de browser nog nodig heeft om agents echt werk te laten doen. We zochten bij elk de stand op.

Alleen het eerste onderdeel kun je dus vandaag gebruiken. De andere vijf zijn discussies en voorstellen. Ze kunnen nog veranderen of verdwijnen.

Wat je bouwt zolang de rest ontbreekt

Er zijn geen rechten per agent. Een tool draait met alle rechten van de ingelogde klant. Je server ziet niet welke agent hem aanroept, en kan de ene agent dus ook niet meer toestaan dan de andere. Begin daarom met tools die alleen lezen of iets klaarzetten, en laat je server bij elke aanroep dezelfde controles doen als bij elk ander verzoek. Wie een agent wil herkennen, kijkt naar afspraken buiten WebMCP, zoals Poppy. Dat is nog een draft.

Een taak over meerdere pagina's kan nog niet. Houd een tool binnen één pagina, en geef het resultaat terug voordat de pagina wisselt. Hoe je dat test, staat in je tool navigeert naar de volgende pagina.

Een echte overdracht aan de mens ontbreekt. Hier zit de les die je vandaag al raakt. Goedkeuren moet betekenen dat een mens heeft goedgekeurd, schrijft Nahas, en een agent die zelf op de knop Goedkeuren van de pagina klikt, levert dat niet op. Een bevestigingspagina in dezelfde browser opent de agent net zo makkelijk als de klant.

De specificatie heeft wel een hint. Met consequentialHint: true meld je dat een tool iets doet met echte gevolgen, zoals een vlucht boeken of geld overmaken. Een agent kan de gebruiker dan eerst om bevestiging vragen. Kan, niet moet: of dat gebeurt, bepaalt de agent, en je server kan het niet nagaan. Een hint is geen bewijs.

Splits een handeling met gevolgen daarom in twee stappen. De agent zet klaar: een conceptbestelling, een ingevulde aanvraag, een gekozen tijdslot. De klant bevestigt zelf, met iets wat de agent niet heeft, zoals een passkey met vingerafdruk of gezichtsherkenning, of een link per e-mail of in je app. Pas na die bevestiging voert je server de handeling uit. Dat is eigen advies, geen onderdeel van de specificatie. Het hCaptcha-voorbeeld laat hetzelfde patroon zien voor een challenge die alleen een mens mag oplossen. Wat je tool in zo'n geval teruggeeft, lees je in een weigering is geen storing.

Een gesprek met de assistent van de site, of een keuze tussen agents, bestaat ook nog niet. Daar valt vandaag niets voor te bouwen. Heb je een chatbot op je site, bied dan niet de chatbot aan als tool, maar de functies erachter, zoals levertijd opzoeken of een bestelling volgen. Een tool geeft een voorspelbaar antwoord; een chatbot geeft tekst die de agent weer moet uitpluizen. Ook dat is eigen advies.

Voorbeeld: klaarzetten in plaats van bestellen

Deze tool zet een bestelling klaar uit de winkelwagen van de ingelogde klant. Hij plaatst niets. Je server maakt een concept dat na korte tijd verloopt, en geeft een link terug naar een pagina waar de klant de bestelling bevestigt. De agent krijgt te horen dat de klant nu aan zet is. Omdat de tool zelf niets met gevolgen doet, heeft hij geen consequentialHint nodig; de handeling met gevolgen is bewust geen tool.

// Zet een bestelling klaar uit de winkelwagen van de ingelogde klant.
// Plaatst niets: de klant bevestigt zelf, met een passkey, op de pagina
// die terugkomt. /api/bestellingen/concept is een voorbeeldnaam.
async function registerPrepareOrderTool() {
  const context = document.modelContext;
  if (typeof context?.registerTool !== "function") {
    return () => {};
  }

  const controller = new AbortController();
  await context.registerTool({
    name: "prepare_order",
    description: "Prepare an order from the signed-in customer's cart. Does not place the order: the customer must confirm it themselves on the returned page.",
    inputSchema: {
      type: "object",
      properties: {
        deliveryDate: { type: "string", description: "Requested delivery date, YYYY-MM-DD" },
      },
      required: ["deliveryDate"],
    },
    execute: async ({ deliveryDate }, { signal } = {}) => {
      const response = await fetch("/api/bestellingen/concept", {
        method: "POST",
        headers: { "Content-Type": "application/json", "X-Aanroep": "webmcp" },
        body: JSON.stringify({ leverdatum: deliveryDate }),
        signal,
      }).catch(() => null);
      if (response?.status === 401) {
        return JSON.stringify({
          status: "sign_in_required",
          reason: "The customer is not signed in. Ask them to sign in first.",
        });
      }
      if (response?.status === 422) {
        return JSON.stringify({
          status: "invalid_input",
          reason: "The cart is empty or this delivery date is not available.",
        });
      }
      if (!response?.ok) {
        return JSON.stringify({
          status: "unavailable",
          reason: "The order cannot be prepared right now. Nothing was ordered.",
        });
      }
      const concept = await response.json();
      return JSON.stringify({
        status: "needs_customer_confirmation",
        confirmUrl: concept.bevestigUrl,
        expiresAt: concept.verlooptOp,
        reason: "Nothing is ordered yet. Ask the customer to open this page and confirm with their passkey.",
      });
    },
  }, { signal: controller.signal });

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

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

Op de bevestigingspagina vraag je de passkey op met WebAuthn, met `userVerification` op "required". Dan moet de klant zich bij zijn eigen apparaat bekendmaken, bijvoorbeeld met een vingerafdruk of zijn gezicht. Je server controleert de ondertekende reactie, kijkt of het concept nog geldig en ongewijzigd is, en plaatst pas dan de bestelling. Een agent die alleen de pagina bestuurt, kan die stap niet voor de klant zetten. Dit voorbeeld is een eigen ontwerp; onze test controleert de logica met een nagebootste browser, niet de werking in een echte agent.

Wat nog niet vaststaat

Pull request #204 stelt requestUserInput voor, met drie manieren om de mens iets te vragen: in de pagina, met een formulier, of via een aparte link voor gevoelige stappen zoals inloggen en betalen. Die laatste lijkt op het patroon hierboven. Komt het voorstel in de specificatie, dan krijgt een tool een standaardmanier om de klant erbij te halen. Of een agent dan ook kan aantonen dat er echt een mens antwoordde, staat nog niet vast.

Rechten per agent kunnen via WebMCP komen, maar ook via een afspraak als Poppy. Die regelt welke agent zich bij een bedrijf meldt en wat de klant hem toestaat. Welke route het wordt, is open.

Een deel van het betoog is bovendien mening. Wat Nahas over MCP zegt, is zijn lezing van het afgelopen jaar: lokaal werk verhuisde volgens hem naar de opdrachtregel, en remote MCP-servers gingen steeds meer op gewone API's lijken. Het is geen uitkomst van een meting.

Wat je nu doet

Controleer of je sessiecookie HttpOnly heeft. Dan geldt de bescherming van de browser waar Nahas op bouwt ook echt voor jouw site.

Maak een lijst van de handelingen op je site met echte gevolgen: bestellen, betalen, opzeggen, gegevens wijzigen. Bepaal per handeling wat een agent mag klaarzetten, en waar de klant zelf bevestigt. Die tweede stap bouw je buiten het bereik van de agent.

Begin met één tool die alleen leest of iets klaarzet. Hulp bij de keuze vind je in het praktische besliskader. Test in Chrome met de origin trial en in de ChatGPT-desktopapp, en volg issue #44 en pull request #204: die bepalen hoe de laatste stap er straks uitziet.