De digitale verleiding is bekend: als iets “standaard” werkt, hoeft het niet opnieuw kritisch bekeken te worden. Toch kan juist die vanzelfsprekendheid leiden tot ongewenste routes van buitenaf naar interne instructies—en uiteindelijk tot gecompromitteerde login bij ETS in de praktijk, niet omdat een model faalt, maar omdat de omgeving eromheen dat wél kan.
In een publicatie over Salesforce Agentforce en verwante intakefeatures wordt een patroon geschetst dat verder gaat dan losse misconfiguraties. Het gaat om ketens: publieke input → case/records → agentprompt → agentactie → reactie terug. Wanneer je governance die keten niet operationeel doorlicht, blijft een cruciale laag buiten beeld.
Waarom “standaard” gedrag toch een route kan worden
Veel teams vertrouwen op gedocumenteerde onderdelen van het platform. In de beschreven situatie draait het om twee soorten functionaliteit:
- Agentreacties op basis van events, waarbij data via flows in de prompt van een agent terechtkomt.
- Inkomende berichten die als cases worden opgeslagen (zoals Email-to-Case en Web-to-Case), een werkwijze die in ondersteuningsprocessen vaak juist bedoeld is.
Op papier lijkt dit logisch en veilig: een klantbericht wordt een case, de agent gebruikt de informatie om te antwoorden. Maar onderzoekers tonen aan dat wanneer deze onderdelen samen een keten vormen, een onbevoegde buitenstaander via de intake alsnog in de context van interne instructies kan belanden. Het resultaat is niet per se een “hack van het model”, maar een lek in de toepassingslogica eromheen.
De kern zit in de keten, niet in het model
De beschreven route werkt conceptueel als volgt: een bericht komt binnen via het publieke internet, wordt omgezet naar een case-structuur, belandt vervolgens in de prompt van een agent, waarna de agent acties uitvoert. Daarna verlaat de reactie opnieuw het systeem via dezelfde ingangskanaal-logica.
Belangrijk: er is geen aanwijzing dat iets “per ongeluk” verkeerd staat. De bevinding draait juist om het feit dat niemand de combinatie van features opnieuw doorrekent zodra agenten en flows zijn toegevoegd of gewijzigd. Het beveiligingsvraagstuk verschuift daardoor van “is deze instelling goed?” naar “is de volledige use-case keten opnieuw beoordeeld?”.
Governance faalt wanneer niemand naar de applicatielaag kijkt
Een veelgemaakte aanname is dat promptfilters of controles op input voldoende zicht bieden. In dit soort scenario’s kunnen die filters echter het oorsprongsprobleem missen: een promptfilter leest input, maar begrijpt niet altijd of de input afkomstig is van een “vreemde” buitenstaander via een intakefeature zoals Email-to-Case.
Daarmee ontstaat een risico dat je niet met enkel model- of promptlaagverdediging oplost. De variabelen die het verschil maken, zitten elders:
- Welke intakefeatures aanstaan
- Welke triggers afgaan bij case-updates
- Welke objecten zichtbaar zijn voor gastgebruikers
- Welke automatiseringen onbetrouwde data doorgeven
- Welke modelversie de agent onder water aanspreekt
Waarom scanners en vragenlijsten de echte risico’s niet vinden
Onderzoekers stellen dat “inherited agents” beveiligd moeten worden op een diepte die normaal gesproken bij admins hoort, niet bij procurement of tooling-bewaking. Met andere woorden: je kunt niet volstaan met een éénmalige risicobeoordeling op het moment dat het platform wordt ingekocht, omdat agenten pas later ontstaan.
Dat verklaart waarom standaard checklists tekortschieten. Een questionnaire vraagt naar beleid en principes, maar ziet vaak niet:
- hoeveel agenten er nu draaien
- wat ze precies kunnen bereiken
- wie ze beheert en wanneer wijzigingen zijn doorgevoerd
Daarmee komt een hard probleem boven: als regels “op papier” worden opgesteld vóórdat de security crew de feitelijke uitvoeringsdetails kan beoordelen, dan kan het beleid de realiteit niet sturen.
Schaduw-agents en agents die agents bouwen
Een extra complicatie is de schaalbaarheid van agentbouw. In het besproken ecosysteem wordt het creëren van agents steeds toegankelijker. Teams gebruiken die mogelijkheden voor legitieme doelen—van pipelineoverzichten tot financiële reconciliatie—en die agents krijgen daarbij automatisch permissies op basis van de maker.
Het risico zit dan in de vermenigvuldiging van toegang: een medewerker kan data en context in een chatbot plakken (shadow AI), en vervolgens kan een agent worden gebouwd die die toegang automatisch uitvoert (shadow agents). Wanneer makers bovendien agents laten “helpen” bij het bouwen van andere agents, groeit het geheel snel zonder dat er een nieuwe reviewlaag ontstaat.
Waarom dit raakt aan het onderwerp gecompromitteerde login
De term gecompromitteerde login bij ETS past bij het bredere patroon dat onderzoekers beschrijven: wanneer een externe partij via een logisch bestaand ingangskanaal in een interne context terechtkomt en die context kan leiden tot acties of terugkoppeling, kan dat in de praktijk als “logincompromittering” worden ervaren of resulteren in ongeautoriseerde toegang.
Het punt is niet dat dezelfde technische oorzaak altijd exact identiek is. Het punt is dat je dezelfde fout kunt maken: denken dat beveiliging “intern” geregeld is, terwijl de applicatielaag rondom de agent als brug fungeert. De defense moet dus expliciet de intake → case → prompt → actie → output-keten afdekken.
Bottom-up testen: de enige manier om bewijslast te krijgen
De publicatie benadrukt een praktische aanpak: test laag voor laag. Governance werkt niet goed als je alleen documenten, policy statements of externe scanning inzet. In plaats daarvan heb je operationele validatie nodig die aantoont dat je daadwerkelijk ziet wat er draait en welke configuraties het gedrag bepalen.
Concreet betekent dit: beoordeel niet alleen of de agent “aan” staat, maar ook welke triggers, dataobjecten, user-rollen en modelaanroepen in jouw omgeving samengaan met intakefeatures zoals Email-to-Case.
Van beleid naar aantoonbaarheid (en waarom dat nu extra telt)
Veel ondernemingen worstelen met governance die vooral uit papier bestaat. In de besproken context wordt gekoppeld aan het idee dat regulering (zoals de EU AI Act) vergelijkbaar zwaar kan wegen als eerdere privacywetgeving: sancties zijn groot, maar vooral de bewijsvoering telt bij toezichthouders.
GDPR liet volgens de tekst zien wat er gebeurt wanneer compliancerapporten niet operationeel kunnen worden onderbouwd. Bedrijven werden niet alleen “afgestraft” omdat beleid onvolledig was, maar omdat auditors of toezichthouders geen realistische bevestiging konden krijgen van wat er in de praktijk werd gedaan.
Een governance-aanpak die bottom-up werkt, levert volgens dezelfde redenering bewijs op als bijproduct: inventaris, eigenaren, configuraties en reviewhistorie. Dat is precies wat je nodig hebt wanneer een incident of onderzoek op tafel komt.
Praktische checklist voor jouw omgeving
Wil je voorkomen dat een keten van intake naar agentactie ongemerkt ontstaat? Gebruik dan een checklist die expliciet naar applicatiegedrag kijkt:
- Inventariseer alle agenten en hun eigenaarschap, inclusief sub-agents.
- Check welke intakekanalen (zoals Email-to-Case/Web-to-Case) bij jouw use-cases actief zijn.
- Leg per case-type vast welke flows en triggers afgaan en welke data in de prompt wordt gestoken.
- Beoordeel welke objecten worden blootgesteld aan gebruikersrollen (met name gast- of externe rollen).
- Valideer hoe onbetrouwbare input door automatiseringen heen reist.
- Documenteer welke modelversie de agent werkelijk gebruikt en wie daar toegang toe heeft.
Door dit operationeel te doen, sluit je aan op de “diepte” die in de publicatie als ontbrekend wordt gezien bij typische vragenlijsten en scanners.
Gerelateerde artikelen om ketenrisico’s beter te begrijpen
Als je dit patroon van misbruik via bestaande ketens wilt verdiepen, kunnen deze onderwerpen helpen om breder te kijken dan alleen agents:
- Contextuele cybersecurity: van losse alerts naar actie
- ConnectWise stopt cloudservices na misbruik login
- MITRE ATT&CK v20: AI-misbruik en MFA-bypass
Conclusie: governance moet de keten kunnen zien
De kern van het beschreven risico is helder: gecompromitteerde login bij ETS (als symptoom of uitkomst) komt niet alleen voort uit een zwakte in een agent, maar uit het feit dat governance niet diep genoeg kijkt naar de applicatielaag en de keten eromheen.
Om dat te doorbreken heb je bottom-up, operationele tests nodig die tonen welke intakefeatures geactiveerd zijn, welke data door flows gaat en welke acties de agent vervolgens uitvoert. Alleen dan maak je governance aantoonbaar—en verklein je de kans dat een “standaard” keten verandert in een route voor ongeautoriseerde toegang.
Bron: https://thehackernews.com/2026/10/from-email-to-case-to-boardroom-how.html
2 reacties