Wat gebeurt er als de leverancier van jouw AI-agent wordt gehackt?

Organisaties besteden steeds meer digitale functies uit aan externe leveranciers.

Cloudsoftware, identity providers, SaaS-platforms, API’s en beveiligingsdiensten zijn inmiddels diep verweven met bedrijfsprocessen.

AI-agents voegen daar een nieuwe dimensie aan toe.

Een leverancier kan straks niet alleen toegang hebben tot informatie, maar indirect ook tot bevoegdheden waarmee een agent namens een organisatie handelt.

Dat verandert het risico fundamenteel.

De vraag is dan niet alleen:

Is onze AI-agent veilig?

Maar ook:

Wat gebeurt er als de leverancier achter die agent wordt gecompromitteerd?

Van datalek naar bevoegdhedenmisbruik

Bij een traditioneel datalek draait het vaak om vertrouwelijkheid: een aanvaller krijgt toegang tot gegevens.

Bij een autonome AI-agent kan het verder gaan.

Een agent kan bijvoorbeeld bevoegd zijn om:

• leveranciers te selecteren;
• bestellingen te plaatsen;
• facturen te verwerken;
• betaalopdrachten klaar te zetten;
• API’s aan te roepen;
• wallets te gebruiken;
• contracten of workflows te starten;
• andere agents aan te sturen.

Als een leverancier die technische toegang faciliteert wordt gehackt, kan een aanvaller mogelijk proberen die bevoegdheden te misbruiken.

Dan verandert een supply-chainincident van een dataprobleem in een transactierisico. De bestaande inventarisatie van aanvalsroutes staat op de pagina over risico’s van agenttransacties.

Gedelegeerde toegang is de kern

Organisaties zullen AI-agents alleen nuttig vinden als die agents daadwerkelijk iets mogen doen.

Daarom krijgen agents gedelegeerde bevoegdheden.

Bijvoorbeeld:

“Deze agent mag tot €500 per bestelling zelfstandig software inkopen.”

Of:

“Deze agent mag betalingen voorbereiden, maar boven €2.500 is menselijke goedkeuring nodig.”

Dat klinkt beheersbaar.

Maar dan moet ook duidelijk zijn waar die bevoegdheid technisch wordt afgedwongen.

Zit die uitsluitend binnen de eigen infrastructuur?

Of kan een externe leverancier via tokens, API-keys, cloudrechten of beheerinterfaces invloed uitoefenen?

Hoe meer bevoegdheden buiten de eigen controlelaag terechtkomen, hoe groter het supply-chainrisico. Hoe organisaties mandaat en verantwoordelijkheid vastleggen, staat op Governance.

Een leverancier mag nooit onbeperkte financiële macht krijgen

De fundamentele ontwerpregel zou moeten zijn:

Een externe leverancier mag nooit méér financiële bevoegdheid hebben dan strikt noodzakelijk.

Dat betekent onder andere:

• least privilege;
• afzonderlijke rechten per agent;
• limieten per transactie;
• limieten per dag of periode;
• beperkingen per leverancier of wallet;
• extra verificatie bij nieuwe tegenpartijen;
• en menselijke goedkeuring boven bepaalde grenzen.

Zelfs als een leverancier wordt gecompromitteerd, moet de schade daardoor begrensd blijven.

Kill switch is geen luxe

Organisaties moeten een agent of leverancier onmiddellijk financieel kunnen uitschakelen.

Niet alleen de gebruikersinterface blokkeren, maar ook:

• API-tokens intrekken;
• wallets afsluiten;
• betaalrechten stoppen;
• sessies ongeldig maken;
• gedelegeerde autorisaties terugtrekken.

Dat moet mogelijk zijn zonder afhankelijk te zijn van dezelfde leverancier die mogelijk is gecompromitteerd.

Een kill switch die alleen via de getroffen leverancier werkt, is geen echte kill switch. Het bestaande artikel over de kill switch voor AI-agents beschrijft hoe intrekbare bevoegdheden en noodstops onderdeel van het ontwerp worden.

Logging moet buiten de leverancier kunnen bestaan

Nog een belangrijk probleem ontstaat bij bewijsvoering.

Als alle logs uitsluitend bij één leverancier staan, kan een incidentonderzoek afhankelijk worden van dezelfde partij waar het probleem is ontstaan.

Voor kritieke transacties is het daarom verstandig dat essentiële gegevens ook elders worden vastgelegd.

Denk aan:

• welke agent handelde;
• welke opdracht de agent kreeg;
• welke bevoegdheid is gebruikt;
• welk account of wallet werd aangesproken;
• welke transactie werd uitgevoerd;
• welke gebruiker of organisatie verantwoordelijk was;
• en of menselijke goedkeuring plaatsvond.

Zo ontstaat een onafhankelijke audit trail. Het artikel over controle over transacties van AI-agents gaat verder in op verifieerbare logging en reconstructie.

De supply chain wordt onderdeel van financiële governance

Cybersecurity en financiële controle liepen lange tijd grotendeels naast elkaar.

AI-agents brengen die werelden samen.

Een gehackte SaaS-leverancier is niet langer alleen een IT-probleem als die leverancier deel uitmaakt van de keten waarmee financiële agents worden aangestuurd.

Dan wordt leveranciersbeheer onderdeel van financiële governance.

Organisaties zullen daarom niet alleen moeten beoordelen:

Is deze leverancier technisch veilig?

Maar ook:

Welke economische bevoegdheden kunnen via deze leverancier worden geraakt?

Dat is een veel concretere vraag.

Ontwerp voor een gehackte leverancier

De veiligste architectuur gaat er niet vanuit dat een leverancier nooit wordt gehackt.

Ze gaat ervan uit dat dit ooit kan gebeuren.

De relevante vraag is dan:

Hoeveel schade kan één gecompromitteerde partij veroorzaken?

Goede agent-governance zorgt ervoor dat het antwoord niet luidt:

“Alles.”

Een AI-agent kan autonoom werken.

Een leverancier kan cruciaal zijn.

Maar financiële bevoegdheden moeten altijd begrensd, intrekbaar en controleerbaar blijven.

De veiligheid van een AI-agent eindigt niet bij de agent zelf. De hele keten erachter telt mee.