AI-agents in plugins toelaten, zonder ze uit de site te laten

Elke Justflows-site draait een MCP-server. Verbind Claude, ChatGPT, Cursor of VS Code ermee en je agent kan berichten schrijven, menu's repareren, de footer bijwerken of je archief taggen, met de rechten die jij geeft. Deze blog wordt op die manier geschreven en onderhouden.

Tot nu toe konden agents alleen gebruiken wat de core aanbood. Plugins zoals Shop hebben genoeg waar een agent bij kan helpen, van productprijzen tot bestellingen, maar geen veilige manier om dat open te stellen. In 0.3.6 krijgen ze die. De functie bouwen was de makkelijke helft. De moeilijke helft was bepalen wat een agent nooit mag kunnen, wat een plugin ook besluit.

Niets wat een plugin doet, wordt aan agents aangeboden tenzij de plugin daarom vraagt. Een plugin kiest daar per route voor, met de nieuwe optie mcp:

ctx.http.put("products/:id", saveProduct, {
  mcp: {
    name: "acme_products_save",
    description: "Save a product's price and stock. Read it first with acme_products_get.",
    capability: "products:update",
    inputSchema: { type: "object", properties: { price: { type: "string" }, stock: { type: "integer" } } },
  },
});

De tool voert de eigen handler van de route uit. Er is geen tweede codepad voor agents, dus de validatie, rechtencontroles en neveneffecten van de plugin blijven op één plek. Padparameters worden verplichte argumenten, en de rest is de querystring of de JSON-body, net als voor elke andere aanroeper.

De oude manier, waarbij plugins willekeurige handlers registreerden via een filter mcp.tools, staat uit. Die handlers draaiden buiten het routesysteem, zonder de controles daarvan. We hebben ze met opzet gebroken.

Agents bereiken je site met een API-sleutel of een OAuth-toegang. Twee wijzigingen maken plugins daarmee bruikbaar. Ten eerste werkt dezelfde jfk_…-sleutel nu direct op pluginroutes, met alle controles van de beheer-API: intrekking, vervaldatum, toegestane IP-adressen en Origins, en ratelimits. Ten tweede had een sleutel "Volledige admin" alleen de rechten die bestonden toen je hem aanmaakte, dus kon hij nooit een later geïnstalleerde plugin gebruiken. Nu krijgt een site:admin-sleutel pluginrechten erbij als er plugins worden toegevoegd, zolang de eigenaar die rechten nog heeft. Core-rechten worden op deze manier nooit uitgebreid.

Justflows kan veel sites in één installatie hosten, gegroepeerd in workspaces. Plugins met de permissie platform:tenancy mogen workspaces en hun limieten beheren. Vóór 0.3.6 kon zo'n plugin, actief op een gehoste site, elke workspace in de installatie beheren en zijn eigen limieten verhogen. Met agents in beeld was dat niet acceptabel.

Dus trekt de host nu zelf de grens. Als er een AI-agent, API-sleutel of gekoppelde app achter een aanroep zit, weigert de host workspace-acties (workspaces opvragen, aanmaken, opschorten of verwijderen, sites toevoegen) en limietwijzigingen. Hij markeert de aanroep voordat er plugincode draait, en die markering volgt elke hook die de aanroep triggert, dus een plugin kan het verzoek niet via een event witwassen. Deze acties draaien nu ook alleen nog op de hoofdsite van de installatie. De sleutel van een agent hoort bij één site, en daar blijft hij.

Een toolresultaat gaat direct de context van een model in, en van daaruit mogelijk naar een AI-provider. Dus voordat er iets naar een agent gaat, of door de adminassistent naar een provider wordt gestuurd, filtert Justflows het. Velden met inloggegevens, instellingen die geheimen noemen, tekst uit omgevingsbestanden, privésleutels, authorization-headers, URL's met inloggegevens en bekende installatiegeheimen worden weggelaten, ook als ze diep in JSON van een plugin zitten. Resultaten die niet kunnen worden gecontroleerd, zoals binaire data, worden geweigerd.

Agents hebben ook geen weg naar het bestandssysteem: geen shell, geen SQL, geen bestandsbrowser en geen toegang tot de broncode van thema's of plugins. MCP-resources zijn beperkt tot de ingebouwde schrijfhandleidingen en de contenttypes van de huidige site.

We hadden richtlijnen voor pluginauteurs kunnen schrijven: controleer wie er aanroept, geef geen geheimen terug, kom niet aan andere workspaces. De meesten zouden zich eraan houden. Maar een CMS draait code van anderen, en beveiliging die afhangt van de zorgvuldigheid van elke plugin is geen beveiliging. Elk van deze regels zit in de host, onder de plugin, waar één fout in één plugin ze niet ongedaan kan maken.

Schrijf je plugins, dan staan de details in de AI-documentatie. Beheer je alleen een site: update naar 0.3.6, en je agent kan de plugins gaan gebruiken die dit ondersteunen.