Onderzoekers beschrijven hoe geërfde agents in enterpriseplatforms kunnen ontsporen, niet door een fout in het model zelf, maar door de manier waarop de omgeving het model aanstuurt. Het gaat om een keten waarin standaard Salesforce-functies, zoals Email-to-Case en een Flow die input in een agentprompt doorgeeft, als vanzelf tot risico kunnen leiden.
Het resultaat is volgens de onderzoekers een route waarbij een externe partij via de “buitenkant” van de applicatie bij agent-instructies kan komen, waarna ook de reactie weer via dezelfde weg terug kan lopen richting de buitenwereld. Kortom: als de governance rond agents niet tot op toepassingsniveau wordt doorgevoerd, blijft het beheer achter bij de realiteit.
Van e-mail naar agentactie: zo ontstaat een keten
De beschreven aanpak werkt doordat meerdere, op zich normale functies worden gecombineerd. In Salesforce Agentforce is een gangbare werkwijze dat een agent op events reageert via een Flow. Concreet wordt dan een record aangemaakt of een case geüpdatet, en geeft die Flow relevante gegevens door aan de prompt van de agent.
Daarnaast worden Email-to-Case en Web-to-Case gebruikt om binnenkomende klantberichten om te zetten naar case-records. Dat is een klassiek patroon voor support intake in sectoren zoals luchtvaart en hotels. Zet je die intakefeatures naast de Agentforce-Flow, dan ontstaat een pad dat – volgens de onderzoekers – kan eindigen bij agentacties en bijbehorende antwoorden.
- publiek internet → e-mailbericht
- → case record
- → agent prompt
- → agent actie
- → case comment
- → uitgaande reply
Belangrijk is dat de onderzoekers benadrukken dat er niet per se sprake is van een verkeerde configuratie “in de zin van een vergeten knop”. Het gaat eerder om het feit dat een agent binnen een bestaande applicatieketen terechtkomt, en dat niemand die keten opnieuw heeft getoetst op het nieuwe dreigingsmodel dat door agents ontstaat.
Waarom promptfilters tekortschieten
Veel organisaties nemen aan dat beveiliging rond prompts en input voldoende is. Maar in deze casus blijkt dat promptfilters niet vanzelf begrijpen waar de input vandaan komt en welke context daarbij hoort. Als de input via Email-to-Case ontstaat, kan een filter de herkomst als “onbekend van buiten” niet herkennen op een manier die governance afdwingt.
Daarmee ontstaat een praktisch probleem: een filter ziet mogelijk “een bericht” in de prompt, maar kan de semantiek van het platformpad niet doorgronden. Het punt dat de onderzoekers maken: de risico’s zitten in de applicatieketen eromheen, dus in de intake, triggers, zichtbare objecten en automatiseringen die untrusted data doorgeven.
Waar je echt naar moet kijken: intake, triggers en objecten
De kern van geërfde agents is dat ze niet vanaf nul ontworpen zijn met security in gedachten. Ze “erven” permissies, flows, en datastromen van het platform waarin ze draaien. Daarom adviseert de aanpak om naar precies de variabelen te kijken die bepalen of de Agentforce-keten veilig is of alleen maar lijkt op beveiliging.
Concreet noemt de broncontext de volgende beslissende factoren:
- Welke intakefeatures zijn ingeschakeld (bijvoorbeeld Email-to-Case of Web-to-Case).
- Welke triggers er afgaan in de bijbehorende automatiseringen of flows.
- Welke objecten beschikbaar komen voor gebruikers, waaronder mogelijk externe/guest-accounts.
- Hoe en waar automatisering data doorgeeft die niet vertrouwd is.
- Welke modelversie de agent “onder water” gebruikt.
Een bijkomend probleem is dat procurementreviews vaak op het moment van aanschaf focussen op wat er toen bekend was. Maar een agent bestond mogelijk nog niet in die fase, waardoor de relevante componenten in de securitybeoordeling simpelweg ontbreken.
Governance op papier werkt niet voor agentketens
Veel organisaties kunnen een document over agent governance overleggen: acceptabel gebruik, een commissie die maandelijks bijeenkomt, en principes die iedereen onderschrijft. Toch is het probleem volgens de onderzoekers dat dit soort governance zelden de operationele werkelijkheid afdekt.
De vraag die dan telt is: hoeveel agents draaien er op dit moment, wat kunnen ze bereiken, en wie is eigenaar van elk van die agents? In de beschreven context blijkt dat governance-rapporten vaak achterlopen, omdat agents in de praktijk ontstaan uit productiviteit en niet uit een centraal securityproces.
Het gat dat scanners missen
Daarnaast beschrijft de broncontext dat een skill of agent die in een derdepartijplatform draait, voor externe scanners niet altijd “zichtbaar” is. Dat is waarom tools die van buiten naar binnen kijken, het ontbrekende detail in de interne keten niet kunnen beoordelen. Met andere woorden: het platform is het “onzichtbare domein” waar de risico’s eigenlijk worden gevormd.
De onderzoekers koppelen dit aan bredere bevindingen over agentic skills: governance faalt vaak omdat regels worden opgesteld vóórdat de securityafdeling de echte configuraties kan zien waar die regels op moeten worden toegepast.
Hoe je dit praktisch veiliger maakt (zonder alleen op beleid te leunen)
De broncontext pleit voor een aanpak bottom-up. Dat betekent: ga niet uit van één allesomvattende governance policy, maar voer operationele tests uit per laag van de technische keten. Als je wilt weten of een “program” echt bestaat en werkt zoals bedoeld, test je het op het niveau waar de risico’s ontstaan.
In de praktijk komt dit neer op het kunnen bewijzen van drie zaken: inventaris, ownership en configuratiegeschiedenis. Niet alleen “wat staat er in documenten”, maar wat er daadwerkelijk draait en hoe de keten is ingericht.
Maak de agent-inventaris aantoonbaar
Omdat agents (en sub-agents) zich via verschillende routes kunnen verspreiden, is een goede inventaris lastig als je alleen naar identiteiten kijkt. De broncontext noemt als voorbeeld een aanpak die agents vanuit meerdere invalshoeken ontdekt en er een risicoprofiel aan koppelt, ook als ze niet via SSO te traceren zijn. Het doel is dat je daarna pas beleid kunt toepassen.
Herbeoordeel de “host application” op ketenniveau
Als Email-to-Case of andere intakefeatures deel zijn van de omgeving, dan moet je de flow-keten niet alleen beoordelen vanuit de agent, maar vanuit het gehele pad: triggers, objectexpositie, datadoorgifte en outputrouting. Het is precies die keten die in de beschreven situatie bepaalt of input van een onbekende bron uiteindelijk leidt tot instructielekkage of ongewenste acties.
Waarom dit breder speelt dan één platform
De broncontext verwijst ook naar een wereldwijd actieve datadiefstal-campagne (genaamd City-Forum) die zich richtte op Salesforce en ServiceNow-omgevingen. Dat sluit aan op het idee dat het risico niet in een geïsoleerde “agentbug” zit, maar in een patroon: platforms maken het makkelijk om agents te bouwen of te activeren, terwijl governance soms vooral op papier bestaat.
Daar komt bij dat het aantal builders en toepassingen groeit. Marketingteams kunnen agents inzetten voor pipeline-rapportage, finance voor reconciliatie, en operations voor andere taken. Elke agent erft de rechten van zijn maker, wat handig is, maar ook de kans vergroot dat een agent ongecontroleerd toegang krijgt tot wat ooit nodig leek voor een mens, maar niet voor een onbewaakte agent.
De broncontext benoemt zelfs dat agents kunnen leiden tot “agents die agents bouwen”: orchestration kan sub-agents opsplitsen, elk met eigen verbindingen, zonder dat dezelfde security review automatisch wordt toegepast. In zo’n wereld kan het idee “een mens vraagt elke agent aan” langzaam onhoudbaar worden.
Conclusie: geërfde agents vragen om keten-governance
Geërfde agents vormen een nieuw governancevraagstuk: niet “is het model veilig?”, maar “is de applicatieketen veilig waarin het model input krijgt en output levert?”. De beschreven Agentforce-inrichting laat zien dat standaard intakefeatures zoals Email-to-Case, gecombineerd met flows die naar een agent promptschrijven, onverwachte routes kunnen creëren van buiten naar binnen.
Wil je dit voorkomen, dan is een document alleen niet genoeg. Zet in op inventaris, ownership en operationele herbeoordeling van intake → triggers → datadoorgifte → output. Als je eerder alleen promptfilters baseerde op wat je denkt te zien, dan is het tijd om het platformpad zelf opnieuw te bekijken.
Wil je meer lezen over vergelijkbare kwesties rond platformketens en agent-achtige incidenten? Bekijk dan ook GhostAction: font-misleiding en OAuth-tokenroof en OpenCode Console-breuk: mogelijke AI API-key exposure.
Bron: https://thehackernews.com/2026/10/from-email-to-case-to-boardroom-how.html
