AI-agents in je eigen software: zo houden we ze in de hand
Agents die zelf werk oppakken, zijn krachtig. Zo bouwen wij ze: met rechten in de code, exacte voorstellen, een goedkeuringsbeleid, budgetten en logging zonder gespreksinhoud.
Een AI-assistent die vragen beantwoordt, is één ding. Een agent die zelf aan de slag gaat zodra er een nieuwe aanvraag binnenkomt, of elke week je openstaande projecten nakijkt, is een stap verder. Dan wil je zeker weten wat zo’n agent mag, wat hij doet en wie er uiteindelijk beslist.
In dit artikel lees je hoe wij dat aanpakken. Alles wat hier staat, zit in de AI-module van ons NewHeap Platform. Die is open source, dus je kunt het in de code nagaan.
Beleid beslist, context informeert
Het belangrijkste uitgangspunt: een prompt is nooit een beveiligingsgrens. Je kunt een model vragen geen klantgegevens te tonen of niets te wijzigen, maar een model kan zich vergissen, of misleid worden door tekst in een document. Daarom bepaalt vertrouwde code wat een model mag zien en doen: de rechten van de gebruiker, de tenant, goedkeuringen en budgetten. De context die het model krijgt, informeert alleen.
Concreet: het model krijgt precies de tools die de gebruiker mag aanroepen, en bij elke aanroep wordt opnieuw gecontroleerd of dat mag. Tekst uit documenten, pagina’s en het geheugen van een agent telt als data, nooit als instructie.
Elke tool zegt wat hij doet
Een tool is een functie van je applicatie die het model mag aanroepen, zoals ‘zoek projecten’ of ‘wijzig de status van een project’. Elke tool verklaart vooraf zijn effect: alleen lezen, wijzigen, iets buiten de applicatie doen of verwijderen. Dat bepaalt hoe streng het platform hem behandelt.
- Lezen mag binnen de rechten van de gebruiker.
- Een wijziging, een externe actie of een verwijdering vraagt om een akkoord.
- Een verwijdering wordt na uitvoering ook nog gecontroleerd.
Bestaande API’s van je applicatie kun je op dezelfde manier als tools aanbieden. Zo’n aanroep gaat door dezelfde rechten en dezelfde pijplijn als bij een gewone gebruiker. Verwijderen bieden we op die manier niet aan.
Eerst een exact voorstel
Een agent wijzigt niet zomaar iets. Hij doet een voorstel met de exacte wijziging: welk object, welke invoer, het verwachte effect en een verloopdatum. Een bevoegde medewerker ziet dat voorstel, met de huidige en de nieuwe waarde, en keurt het goed of af.
Dat akkoord geldt alleen voor precies dat voorstel, door die persoon en binnen die termijn. Vlak voor uitvoering controleert het platform opnieuw of alles nog klopt. Is het object intussen veranderd, dan wordt het voorstel standaard gesloten in plaats van uitgevoerd. En een agent kan zijn eigen voorstel nooit goedkeuren.
Namens wie werkt een agent?
Een assistent in de chat werkt met de rechten van de ingelogde gebruiker. Een agent die op de achtergrond draait, heeft geen ingelogde gebruiker. Daarom leg je per agent vast aan wie hij verantwoording aflegt: aan zichzelf, aan de verantwoordelijke van het object of aan een technisch account. Hij werkt dan met de rechten van die persoon of dat account, binnen de tools die je hem geeft.
Een agent die alleen aan zichzelf verantwoording aflegt, heeft geen rechten om uit te lenen en doet zonder akkoord niets anders dan lezen. Meer rechten dan de persoon voor wie hij werkt, krijgt een agent alleen als de tool dat toestaat én de code van de applicatie het expliciet toekent. Een agent die een beheerder in het beheerscherm aanmaakt, krijgt die extra rechten nooit.
Een goedkeuringsbeleid per agent
Wie beslist er over het voorstel van een agent? Dat leg je vast in een goedkeuringsbeleid, bijvoorbeeld: de goedkeurders van het project, een tweede paar ogen of een vaste rol. Het beleid bepaalt ook hoe lang een voorstel geldig blijft en wanneer er een herinnering komt. Standaard wacht een voorstel van een agent drie dagen, met een herinnering na een dag.
Wijst iemand een voorstel af, dan kan die aangeven waarom. Die feedback zie je per versie van de agent terug, zodat je kunt zien of een aanpassing van de instructies of de tools hielp. En hetzelfde voorstel komt niet keer op keer terug: na een afwijzing geldt een afkoelperiode.
Grenzen aan gebruik en kosten
Een agent die in een lus raakt, moet ergens stoppen. Daarom gelden er budgetten op meerdere niveaus: per modelprofiel voor tokens, aanroepen en geschatte kosten, per persoon per dag, per beurt in de chat en per agent. Per run kun je daarnaast een plafond voor het aantal tokens instellen.
Het modelprofiel legt ook vast welke soorten gegevens een model mag zien en in welke regio’s het mag draaien. Zo kies je per toepassing tussen een online en een lokaal model, zonder dat de rest van de applicatie verandert.
Klein beginnen: regels en schaduw
Niet elke agent heeft een taalmodel nodig. Veel werk is te vangen in vaste regels, zoals: ‘als alle taken van een actief project zijn afgerond, stel dan voor het project te voltooien’. Zo’n agent kost geen tokens en doet elke keer hetzelfde. Een model zet je in waar het iets toevoegt, en regels en een model kunnen samen in één vaardigheid.
Een nieuwe variant van een agent draait eerst in schaduw: hij werkt mee, maar voert niets uit en niemand krijgt een melding. Je vergelijkt zijn voorstellen met die van de live versie en zet hem pas live als hij beter is. Niets wordt automatisch gepromoveerd.
Vastgelegd, zonder gespreksinhoud
Achteraf wil je kunnen nagaan wat er gebeurde: wie stelde wat voor, wie gaf akkoord en wat werd er uitgevoerd. Dat leggen we vast in een audit. Wat daar niet in staat, is de inhoud van gesprekken. Die blijft in de database van je eigen applicatie en komt nooit in logs, telemetrie of de registratie van verbruik.
MCP: koppelen zonder blind vertrouwen
Met het Model Context Protocol (MCP) koppel je een assistent aan tools van andere systemen. Handig, maar een externe MCP-server is code van een ander. Wij behandelen hem daarom als onbetrouwbaar. Zijn tools staan uit tot een beheerder ze aanzet, en wat de server over zijn tools beweert, bijvoorbeeld dat een tool alleen leest, geeft nooit extra rechten. Verandert het schema van een tool, dan gaat die weer uit.
Andersom bied je de tools van je eigen applicatie als MCP-server aan, met per gebruiker en tenant alleen de tools die mogen.
Zo begin je
- Kies één proces waarin een agent werk kan voorbereiden, zoals nieuwe aanvragen beoordelen.
- Bepaal namens wie de agent werkt en wie zijn voorstellen goedkeurt.
- Gebruik vaste regels waar het kan, en laat een model alleen beslissen waar het iets toevoegt.
- Laat een nieuwe variant eerst in schaduw meedraaien.
- Spreek een budget af en volg de kosten.
Lees ook onze governance-checklist voor AI, bekijk de AI-module van het NewHeap Platform of lees hoe we AI-implementatie aanpakken. Wil je weten wat een agent in jouw processen kan doen? Bespreek het met een van onze engineers.
Hier helpen we bij
AI-implementatie & intelligente automatisering
AI veilig inzetten in je processen, systemen en data.
Lees hoe we het aanpakkenUit de praktijk
Diverse klanten
AI-assistenten koppelen aan systemen en workflows
Wil je dit voor jouw organisatie uitzoeken?
Vertel ons hoe het werk nu loopt. We denken mee over de aanpak die bij jouw systemen en mensen past.







