Wanneer een AI-agent zijn eigen inloggegevens bij zich draagt en rechtstreeks contact opneemt met externe services, gedraagt hij zich minder als bedrijfssoftware en meer als een contractor met een zakelijke creditcard en zonder toezichthouder. Je kunt niet zien wat hij heeft aangeraakt, wie de toegang heeft goedgekeurd, of waarom het ene gesprek tien keer zoveel kostte als het andere. De logs versnipperen over een dozijn verschillende services. De vragen vermenigvuldigen zich.

Welke tool heeft de agent daadwerkelijk aangeroepen? Wie gaf toestemming om die database te raadplegen? Waarom verbruikte de run van dinsdag veertigduizend tokens, terwijl die van maandag er slechts vijf gebruikte? Hoeveel hebben we eigenlijk uitgegeven?

Zonder een centrale bestuurslaag tussen gebruikers, modellen en services blijven deze vragen onbeantwoord. Je hebt een enkel platform nodig dat elke verbinding één keer registreert, slechts een beperkte set functies blootstelt die een agent echt nodig heeft, en elke uitvoering volledig vastlegt. In dit artikel doorlopen we een geavanceerd lab waarbij deco Studio fungeert als dat lokale controleplatform. Je gaat het opzetten, een veilige Model Context Protocol-server koppelen, precies één toegestane functie blootstellen en zien wat er gebeurt wanneer een agent probeert buiten zijn grenzen te treden.

Het probleem met versnipperde inloggegevens

Stel je een typische teamopstelling voor. De ene ontwikkelaar koppelt een agent aan een zoek-API met een persoonlijke sleutel. Een ander sluit dezelfde agent aan op een productie-database omdat de demo er onschadelijk uitzag. Een derde voegt een tool voor factuuroverzicht toe, zodat de agent kan "helpen met facturen". Elke verbinding is onzichtbaar voor de anderen. De agent heeft nu directe toegang tot zoekopdrachten, productiedata en financiële gegevens, maar het team heeft geen eenduidige lijst van wat er actief is.

Wanneer inloggegevens in de agent zelf staan, valt de governance uiteen. Je kunt de toegang niet centraal intrekken, omdat de sleutel in het geheugen van de agent of in een lokaal omgevingsbestand staat. Je kunt het gebruik niet auditen, omdat de externe service alleen een API-aanroep ziet van een anonieme, geautomatiseerde client. De kostenverrassingen verschijnen pas dagen later op een cloudfactuur, en tegen die tijd weet niemand meer welke prompt de piek heeft veroorzaakt.

Je controleplatform bouwen in deco Studio

deco Studio lost dit op door te fungeren als een lokale hub. Je draait het op je eigen machine en het wordt de centrale plek waar configuraties worden beheerd. In plaats van API-sleutels en tool-definities over verschillende agents te verspreiden, registreer je een verbinding één keer in Studio. Daarna bepaal je precies welke functies elke agent kan zien.

Zie het als het installeren van een telefooncentrale. Alle draden lopen naar één kamer. Jij kiest welke lijnen verbonden worden met welke afdelingen en je houdt een verslag bij van elk gesprek.

Begin met het lokaal draaien van deco Studio. Zodra het is opgestart, centraliseer je de configuratie. Elke agent die een tool wil gebruiken, moet nu de controlelaag raadplegen in plaats van de externe service rechtstreeks. Dit creëert onmiddellijk een knelpunt waar je kunt observeren, filteren en loggen.

Een veilige MCP-server koppelen

In dit lab koppel je een Model Context Protocol-server. MCP is een open standaard waarmee modellen kunnen communiceren met externe tools, maar standaarden garanderen geen veiligheid. De cruciale stap hier is selectiviteit. Je stelt niet blindelings elk endpoint bloot dat de server aanbiedt. Je registreert de server in deco Studio en stelt vervolgens slechts één toegestane functie bloot aan je testagent.

Stel dat je MCP-server bijvoorbeeld tien functies aanbiedt: bestand lezen, bestand schrijven, databasequery, netwerk-fetch en meer. Je kiest één onschadelijke operatie, bijvoorbeeld een gesandboxed rekenmachine of een read-only zoekopdracht in synthetische data, en je stelt alleen die bloot. De andere negen worden onzichtbaar voor de agent. Als de agent erom vraagt, geeft de controlelaag een harde weigering.

Dit is het principe van minimale rechten (least privilege) in mechanische vorm. De agent krijgt mogelijkheden niet via een beleefde instructie, maar via een softwarematige grens.

De grens testen

Maak een testagent aan en richt deze op je deco Studio-controleplatform. Geef de agent een taak die de enige toegestane functie vereist. Kijk hoe het slaagt. De logs in Studio tonen het modelverzoek, de doorsturing van de tool-aanroep via het controleplatform, de uitvoering van de functie en het resultaat dat terugvloeit naar het model. Je kunt het volledige pad lezen in één doorlopende trace.

Geef de agent nu een tweede taak die een functie vereist die je bewust hebt uitgesloten. De agent kan proberen de beperking te omzeilen via redenering, of hij kan hallucineren dat de tool bestaat. Hoe dan ook, de aanroep bereikt de control plane, de allowlist wijst deze af en de uitvoering mislukt. Die mislukking is het bewijs dat de grens softwarematig wordt afgedwongen en niet slechts theoretisch is.

Doe dit eerst met synthetische taken. Bouw een nepdatabase vol gegenereerde gebruikersprofielen. Laat de agent deze bevragen. Controleer de allowlist en de weigeringen. Pas nadat je de grens vertrouwt, moet je zelfs maar overwegen om de agent op productiesystemen te richten. Te snel naar echte data overstappen voordat je de barrière hebt geverifieerd, is hoe geheimen lekken.

Het volledige pad van een run bekijken

deco Studio stelt je in staat om elke laag van een uitvoering te inspecteren. Je ziet het ruwe modelverzoek: de prompt, het contextvenster, de formattering. Je ziet de tool-aanroep die het model heeft besloten te maken. Je ziet hoe de control plane die aanroep routeert, de functie uitvoert en de payload retourneert. Ten slotte zie je hoe het model dat resultaat gebruikt om zijn antwoord te vormen.

Dit inzicht beantwoordt de basisvragen voor audits. Je weet welke tool is geactiveerd omdat de control plane dit heeft gelogd. Je weet wie toegang heeft verleend omdat de configuratiegegevens in één lokaal register staan. Je weet waarom de run duur was omdat je de tokens kunt tellen.

Tellen wat ertoe doet

Houd voor elke run vier specifieke metrieken bij. Ten eerste: input- en outputtokens. Deze drijven het grootste deel van de modelkosten aan, en je hebt exacte aantallen nodig, geen ruwe schattingen. Ten tweede: scheid model-latency van tool-latency. De tijd tussen je prompt en de reactie van het model is anders dan de tijd die de externe service nodig heeft om een tool-aanroep te beantwoorden. Het verwarren van deze twee leidt tot verkeerd gediagnosticeerde vertragingen. Ten derde: bereken de kosten op basis van geverifieerde tarieven van de provider. Gok niet. Controleer de prijslijst van je provider en stem deze af op de gemeten tokens. Ten vierde: vergelijk succesvolle aanroepen met afgewezen, ongeautoriseerde aanroepen. Een hoog aantal afwijzingen betekent dat je agent grenzen opzoekt of dat je allowlist niet is afgestemd op legitieme behoeften.

Deze cijfers veranderen agent-operaties van een black-box-abonnement in een observeerbaar systeem. Je kunt budgetteren, optimaliseren en verantwoorden.

Het verschil tussen lokale controle en lokale uitvoering

Dit is een les waar zelfs zorgvuldige bouwers over struikelen. Het draaien van deco Studio op je eigen machine geeft je lokale controle over de configuratie, maar het garandeert geen lokale uitvoering van het model zelf. Als je de agent configureert om een externe provider aan te roepen, zoals OpenAI, Anthropic of een andere gehoste API, verlaten je prompts je machine. Studio beheert de poortwachter, maar de gegevens doorkruisen nog steeds het netwerk.

Houd deze grenzen altijd bij. Weet welke delen van de pipeline op localhost blijven en welke delen naar de server van iemand anders reizen. Als je gegevens gevoelig zijn, is lokale controle van de tool-laag niet voldoende. Je moet ook weten waar de model-inferentie plaatsvindt. Verwar het gemak van een lokaal dashboard niet met de realiteit van een extern model.

Instructies zijn geen autorisatie

Een gevaarlijke afsnijroute is het proberen te beveiligen van een agent via prompting. Het model vertellen: "Roep nooit de delete-functie aan", is geen beveiligingsmaatregel. Het is een suggestie. Modellen kunnen instructies verkeerd interpreteren, prompts 'jailbreaken' of simpelweg redeneerfouten maken. Echte beveiliging bevindt zich op de softwaregrens.

Gebruik allowlists binnen deco Studio om precies te definiëren welke functies aanroepbaar zijn. Dwing deze limieten af met server-side controles binnen de control plane. De agent zou zijn mogelijkheden moeten ontdekken op de manier waarop een gebruiker bestandstoegangsrechten ontdekt: door tegen een harde limiet aan te lopen, niet door een vriendelijke notitie te lezen. Beveiliging hoort in de architectuur thuis, niet in natuurlijke taal.

Begin klein, blijf sceptisch

Bouw je control plane stap voor stap op. Eén MCP-server. Eén blootgestelde functie. Eén synthetische taak. Verifieer dat de agent slaagt waar hij moet slagen en faalt waar hij moet falen. Lees de trace. Bevestig de token-aantallen. Voeg dan de volgende tool toe.

Controle is geen schakelaar die je omzet. Het is een gewoonte om grenzen te bewijzen voordat je ze vertrouwt. deco Studio geeft je het lokale platform om die gewoonte te oefenen. Gebruik het om een zwerm autonome agenten om te vormen tot een beheerd, observeerbaar en begrensd systeem.

Bron: Controlling AI Agents in deco Studio: Tools, Permissions, and Cost

Optionele leercommunity: GyaanSetu AI op Telegram