Agentbeveiliging is een systeemprobleem: van prompt-injection tot runtime-bediening

Een grootschalig onderzoek uit 2026 naar de beveiliging van LLM-agents komt tot een conclusie die enterprise-teams serieus moeten nemen: zodra een model tools kan gebruiken, de staat kan behouden en namens iemand anders kan handelen, is beveiliging niet langer voornamelijk een probleem van prompt-filtering. Het wordt een systeemprobleem dat zich uitstrekt over informatiedoorstroming, gedelegeerde autoriteit en permanente staat.

1. Waarom agentbeveiliging verschilt van LLM-veiligheid

Het onderzoek vertrekt vanuit een eenvoudig architecturaal feit: een LLM-agent doet meer dan alleen tekst genereren. Hij kan plannen, tools aanroepen, browsen, code uitvoeren, de staat bijwerken en coördineren met andere agents. Die mogelijkheden veranderen model-outputs in inputs voor de besturingsstroom van software.

Dat verandert het type storing. Een kwaadaardige instructie die verborgen zit in een webpagina kan een latere tool call beïnvloeden. Een vergiftigd resultaat van een tool kan de context worden voor een volgende beslissing. Een aangetast geheugenelement kan de oorspronkelijke sessie overleven. Een gedelegeerde credential kan een slecht plan veranderen in een werkelijk neveneffect. In een multi-agent systeem kan dezelfde gecontamineerde informatie zich verder verspreiden dan de agent die er als eerste mee in aanraking kwam.

Het onderzoek formuleert agentbeveiliging daarom rond drie interagerende eigenschappen:

De nuttige implicatie is dat een veilige agent-architectuur niet alleen moet vragen: "Hebben we de kwaadaardige prompt geblokkeerd?" Het moet ook vragen: wat zou die inhoud kunnen beïnvloeden, welke autoriteit zou het resulterende traject kunnen uitoefenen, en welke staat zou het traject achter kunnen laten?

2. Het aanvalsoppervlak loopt door de gehele levenscyclus van de agent

Ling en co-auteurs gebruiken een op de levenscyclus gebaseerd, systeemgeoriënteerd kader in plaats van een platte lijst met aanvalsnamen. Operationeel is het nuttig om het kernactiepad—input, planning, beslissing, tool-uitvoering en output—te scheiden van dwarsverbanden zoals geheugen, monitoring en multi-agent coördinatie, omdat die oppervlakken meerdere fasen van de uitvoering kunnen beïnvloeden of observeren.

Dit perspectief op de levenscyclus verklaart ook waarom verdedigingen "zwak samenstelbaar" kunnen zijn, zoals het onderzoek het noemt. Een inhoudsfilter kan één klasse van kwaadaardige tekst blokkeren, maar doet niets tegen credentials met te veel rechten. Een sandbox kan code-uitvoering isoleren, maar voorkomt geen geautoriseerde API-call. Een goedkeuringspoort kan één neveneffect stoppen, maar geen vergiftigde geheugenschrijfactie. Een trace kan een incident observeerbaar maken zonder het te voorkomen.

Beveiliging ontstaat daarom uit de samenstelling van grenzen, privileges, staatsbeheersing en bewijslast.

3. Het onderzoek koppelen aan TrueForge en TrueFoundry

De meest heldere productkoppeling is niet "TrueFoundry lost agentbeveiliging op." Het is vragen welk deel van het systeemmodel uit het onderzoek realistisch gezien door elke laag kan worden beheerd.

4. Informatiedoorstroming: behandel externe context als niet-vertrouwde gegevens—en behoud de herkomst

Eén van de belangrijkste herformuleringen uit het onderzoek is dat prompt-injection een probleem van informatiedoorstroming is. De gevaarlijke instructie kan van een gebruiker komen, maar kan net zo makkelijk afkomstig zijn uit een opgehaald document, een webpagina, een tool-respons, een andere agent of een opgeslagen geheugenelement.

Dat betekent dat de architectuur onderscheid moet maken tussen waar de informatie vandaan kwam en wat het model afleidt dat het betekent, en de herkomst moet bewaren waar dat onderscheid verderop in het proces van belang is.

TrueForge: maak de runtime-grens expliciet

TrueForge is een open-source agent-harness die zorgt voor de model/tool-lus, contextbeheer, sandboxing, goedkeuringen, sessies en gebeurtenissen. Het sandbox-as-tool ontwerp is met name relevant voor het argument van het onderzoek over vertrouwensgrenzen: de agent-lus en model/MCP-credentials blijven in de harness, terwijl code, bestanden en shell-uitvoering plaatsvinden in een geïsoleerde omgeving die wordt klaargezet wanneer dat nodig is.

Dit is een nuttige scheiding van verantwoordelijkheden. De sandbox kan worden behandeld als een uitvoeringsoppervlak met minder vertrouwen, zonder dat het tevens de opslagplaats wordt van agent-credentials of gesprekscapaciteiten.

MCP Gateway: inspecteer en beheer de tool-grens

TrueFoundry MCP Gateway voegt een gedeelde grens toe tussen agents en enterprise-tools. De huidige documentatie beschrijft gecentraliseerde registratie en discovery, OAuth/token-beheer, server/tool-toegangscontrole, guardrails vóór en na de tool, goedkeuringsworkflows en controleerbaarheid van requests/responses voor verkeer dat via de Gateway wordt geleid.

Dat is van belang omdat een resultaat van een tool niet louter data is. Het kan nieuwe context worden die de latere planning beïnvloedt. Inspectie ná het gebruik van de tool heeft daarom een andere rol dan autorisatie vóór de tool: de ene controleert of de tool mag draaien; de andere kan inspecteren welke informatie terugkeert in de agent-lus.

5. Gedelegeerde autoriteit: minste privileges: houd agent-autoriteit niet ruimer dan de taak vereist

De tweede as van het onderzoek is gedelegeerde autoriteit. Agentsystemen zijn niet alleen riskant omdat modellen gemanipuleerd kunnen worden, maar omdat een gemanipuleerd model daadwerkelijke autoriteit kan bezitten namens een gebruiker, team, applicatie of service.

Dit is waar het principe van de minste privileges een architecturale eigenschap moet worden in plaats van een prompt-instructie.

Het belangrijkste ontwerpprincipe is dat deze beheersingsmaatregelen verschillende vragen beantwoorden. Autorisatie geeft aan of een actor een functionaliteit mag gebruiken. Guardrails beperken requests of resultaten. Human-in-the-loop (HITL) voegt menselijke beoordeling toe op een geselecteerd moment. Budget en rate limits beperken de economische en operationele autoriteit. Geen van deze is een vervanging voor de andere.

6. Permanente staat: een beveiligingsoppervlak dat de prompt overleeft

Het onderzoek belicht de corruptie van permanente staat als een opkomend probleem. Dat is belangrijk omdat agents steeds vaker een enkele prompt of HTTP-request overleven. Ze bewaren gesprekken, bestanden, geheugen, samenvattingen, tool-resultaten, plannen en soms aangeleerde voorkeuren over lange workflows heen.

De SDK van TrueForge maakt deze runtime-staat inzichtelijk via een expliciete hiërarchie van Agent → Sessie → Turn → Event → Delta. Sessies kunnen heraansluitingen en herstarts overleven, turns worden gekoppeld binnen een sessie, en gebeurtenissen tonen wat de runtime aan het doen is—inclusief MCP-initialisatie, modelberichten, tool-antwoorden, goedkeuringsvereisten en het voltooien van een turn.

Dat is waardevol voor beveiliging omdat het beheerders een inspecteerbare historie geeft. Maar observeerbaarheid moet niet worden verward met herkomstgaranties.

Dit is vooral belangrijk wanneer een systeem context samenvat. Een samenvatting kan operationeel nuttig zijn zonder dat elk voor vertrouwen relevant detail bewaard blijft. Teams moeten bewust beslissen welke herkomstvelden het samenvatten, het verhogen van geheugenniveaus en de overdracht tussen agents moeten overleven.

7. Multi-agent systemen veranderen een lokale aantasting in een propagatierisico

Het onderzoek merkt multi-agent propagatie aan als een groeiend aandachtspunt binnen de wetenschap. Zodra agents berichten uitwisselen, werk delegeren of elkaar aanroepen, kan een aangetaste output de vertrouwde input van een andere agent worden.

Op dat punt is de relevante beveiligingsvraag niet meer alleen "is Agent A veilig?" Het is:

• Welke agents mogen Agent A aanroepen?
• Welke agents mag Agent A aanroepen?
• Welke identiteit reist mee bij een delegatie?
• Welke gebruiker of service wordt uiteindelijk vertegenwoordigd?
• Welke tools en gegevens blijven bereikbaar na delegatie?
• Hoe blijft trace-context behouden door de gehele keten?

De Agent Registry van TrueFoundry documenteert momenteel verifieerbare agent-identiteit, eigenaarschap, op samenwerking gebaseerde toegangscontrole en routing voor geregistreerde agents. Bredere Agent Gateway- en observeerbaarheidsoppervlakken kunnen quota's, budgetten en gecentraliseerde tracing toevoegen voor ge-routeerd agent-verkeer. De Registry-documentatie toont ook op identity-providers gebaseerde koppelingen, maar de specifieke On-Behalf-Of delegatieworkflow staat nog expliciet gemarkeerd als Binnenkort beschikbaar; dit artikel beschouwt volledige OBO-uitwisselingssemantiek vandaag de dag daarom niet als algemeen beschikbaar.

Maar dezelfde grens blijft belangrijk: een agent-register bepaalt niet de workflowtopologie van de applicatie, en agent-tot-agent verbindingen zijn niet automatisch veilig enkel omdat de peers geregistreerd zijn. Autorisatie- en delegatiebeleid moeten de graaf nog steeds beperken.

8. Waarom "defense in depth" niet genoeg is tenzij de verdedigingen samenwerken

Beveiligingsteams roepen vaak "defense in depth", maar de bevinding van het onderzoek over zwakke samenstelbaarheid wijst op een hardere eis: de verdedigingsmechanismen moeten het eens zijn over hetzelfde vertrouwens- en autoriteitsmodel.

Bijvoorbeeld:

• Een sandbox kan code isoleren, terwijl een MCP-credential met te veel rechten nog steeds een destructieve API-call op afstand toestaat.
• Een gateway kan een niet-geautoriseerde tool blokkeren, terwijl een vergiftigde sessiestatus nog steeds veranderd welke geautoriseerde tool de agent kiest.
• Een menselijke goedkeuring kan een actie valideren, terwijl de onderliggende argumenten vóór de uitvoering veranderen, tenzij de goedkeuring gebonden is aan het werkelijke request.
• Een trace kan elke call vastleggen, terwijl auditlogs van downstream-systemen nog steeds nodig zijn om te bewijzen wat het system of record daadwerkelijk heeft gewijzigd.

Een beter operationeel model is om elke cruciale verbinding in het agentsysteem te benaderen met vier vragen:

Dit is waar TrueForge en de TrueFoundry Gateways elkaar aanvullen. De harness beheert de uitvoering binnen de agent-lus. Gateways centraliseren het beleid voor model-, tool- en agentverkeer dat bewust via hen wordt geleid. Systems of record behouden de autoriteit over het uiteindelijke zakelijke neveneffect.

9. Beveiligingsevaluatie moet lijken op de productieomgeving

De laatste waarschuwing uit het onderzoek is methodologisch: bestaande benchmarks ondervertegenwoordigen nog steeds langdurige, staatafhankelijke en implementatiegevoelige risico's. Dat betekent dat een jailbreak-test van één turn onvoldoende bewijs is dat een agent veilig urenlang kan draaien, de staat kan behouden, tools kan gebruiken of kan coördineren met peers.

Een op productie gerichte beveiligingsevaluatie moet meer variëren dan alleen de prompt. Het moet het volgende testen:

• indirecte instructies die binnenkomen via tools en opgehaalde inhoud;
• vergiftiging van de staat die pas enkele turns later relevant wordt;
• credential- en permissiegrenzen onder realistische identiteiten;
• het verlopen van goedkeuringen, herpogingen en hervatgedrag;
• aannames over sandbox-escapes en tool-autoriteit buiten de sandbox;
• multi-agent propagatie en delegatiediepte;
• model/provider-wijzigingen en uitwijkroutes;
• volledigheid van traces over de harness, gateway en downstream-systemen heen.

Voor beveiligingsevaluaties van agents maken de runtime-configuratie, tooltopologie, permanente staat, identiteit en het bemiddelingsbeleid deel uit van het geëvalueerde systeem—het zijn geen bijkomstige implementatiedetails.

10. Wat TrueForge en TrueFoundry wel—en niet—beweren

Het onderzoek is juist nuttig omdat het ontmoedigt om te geloven in wondermiddelen. Datzelfde zou moeten gelden voor productarchitectuur.

De sterkste architectuur is daarom niet "plaats een gateway voor de agent." Het is een reeks expliciete vertrouwensgrenzen waarvan de verantwoordelijkheden nauw genoeg zijn om over te redeneren en waarvan het bewijsmateriaal achteraf gecorreleerd kan worden.

11. De praktische beveiligingsbeoordeling

Als die vragen niet beantwoord kunnen worden, is het probleem niet dat de organisatie nog een extra prompt-filter nodig heeft. Het heeft een duidelijkere beveiligingsarchitectuur voor agents nodig.

Referenties

• Yuchen Ling, Shengcheng Yu, Zhenyu Chen, en Chunrong Fang. Toward Secure LLM Agents: Threat Surfaces, Attacks, Defenses, and Evaluation (2026; v2 23 augustus 2026). Onderzoek van 247 artikelen en de primaire bron voor het beveiligingskader dat in dit artikel wordt gebruikt.
• TrueForge — Introduction. Huidige documentatie voor de open-source agent-harness, uitvoeringslus, goedkeuringen, contextbeheer, permanente sessies en het sandbox-as-tool model.
• TrueForge — Setup Sandbox. Huidige documentatie voor sandbox-isolatie, provisioning op aanvraag en het bewaren van model/MCP-credentials in de harness.
• TrueForge — SDK Concepts. Huidig Agent → Sessie → Turn → Event → Delta runtime-model.
• TrueFoundry — AI Gateway. Huidige documentatie voor modeltoegang, routing, rate limits, budgetten, guardrails en observeerbaarheid.
• TrueFoundry — MCP Gateway. Huidige documentatie voor MCP registry, authenticatie, tokenbeheer, tool-toegang, guardrails, goedkeuringen en audit.
• TrueFoundry — Agent Registry. Huidige documentatie voor het registreren van agents, het vaststellen van identiteit en eigenaarschap, op medewerkers gebaseerde toegangscategorieën, routing en agent-tokens.
• TrueFoundry — Agent Gateway. Huidig publiek productoppervlak voor agent-niveau quota/budgetten, toegangsbeheer en execution tracing.
• TrueFoundry — Agent Identity and Delegation. Geplande On-Behalf-Of delegatie-workflow; de pagina is expliciet gemarkeerd als Coming Soon.

Productgedrag is beschreven op basis van de huidige openbare TrueForge- en TrueFoundry-documentatie vanaf 28 augustus 2026. De taxonomie en onderzoeksresultaten van het onderzoek worden toegeschreven aan de auteurs ervan. De productmapping en architectuuraanbevelingen zijn redactionele analyses van TrueFoundry en mogen niet worden gelezen als claims die zijn gemaakt of onderschreven door de auteurs van het onderzoek.

‍

‍

‍

‍