Cyberbeveiligingsstrategieën voor de ontwikkeling van low-code- versus high-code-agents

Wanneer organisaties AI-agents inzetten in hun bedrijfssystemen, raken de ontwikkelsnelheid en het beveiligingstoezicht nauw met elkaar verweven. Cyberbeveiligingsstrategieën voor de ontwikkeling van low-code- en high-code-agents moeten rekening houden met de manier waarop elke aanpak toegang tot informatie verleent en acties mogelijk maakt. Gerichte beveiligingsmaatregelen kunnen die verschillen ondervangen, terwijl gezamenlijk toezicht ervoor zorgt dat de activiteiten van agents afgestemd blijven op geautoriseerde taken naarmate de implementaties zich uitbreiden.

Wat het verschil is tussen de ontwikkeling van low-code- en high-code-AI-agents

Met low-codeplatforms kunnen ontwikkelaars agents samenstellen via visuele interfaces en vooraf gebouwde connectors die bedrijfsdiensten met elkaar verbinden. High-codedevelopment geeft programmeurs meer flexibiliteit om het gedrag van agents te bepalen met aangepaste code, toolintegraties en uitvoeringsomgevingen. Bij beide aanpakken is toezicht nodig op de informatie waartoe agents toegang hebben en de acties die ze kunnen uitvoeren.

De beveiligingsverantwoordelijkheden verschillen omdat de controle op verschillende plekken ligt. Low-codeontwikkelaars werken met platforminstellingen voor het delen van informatie en toegang via connectors, waardoor configuratiekeuzes bijzonder belangrijk zijn. High-codeteams dragen meer verantwoordelijkheid voor de software en omgevingen die agentinstructies uitvoeren, waaronder de afbakening van toegang tot bestanden en inloggegevens.

De Cybersecurity and Infrastructure Security Agency benoemt verschillende risico’s van agentische AI die voor beide benaderingen een bruikbaar kader bieden. Een uitgebreid aanvalsoppervlak verwijst naar extra toegangspunten, terwijl sluipende uitbreiding van toegangsrechten verwijst naar de opeenstapeling van toegangsrechten. Gedragsmatige afwijking houdt in dat wordt afgeweken van de beoogde taken, en ondoorzichtige gebeurtenisregistraties bemoeilijken het onderzoek. Een veelgebruikte koppeling en een opdrachtregelprogramma zonder beperkingen kunnen verschillende varianten van dezelfde problemen veroorzaken.

Beveiligingsrisico’s en oplossingen voor low-code-AI-agents

Dankzij de toegankelijkheid van low-code kunnen ook medewerkers buiten traditionele ontwikkelteams agents maken. Het beveiligingstoezicht moet zich ook uitstrekken tot deze ontwikkelaars, zodat handige verbindingen in overeenstemming blijven met geautoriseerde zakelijke toepassingen.

Waar low-codeomgevingen tekortschieten op het gebied van beveiliging

Medewerkers zonder programmeerachtergrond kunnen een agent koppelen aan gedeelde bestanden of bedrijfstoepassingen zonder de machtigingen van de agent volledig te begrijpen. Toegang die via zulke verbindingen wordt verleend, kan gevoelige informatie blootleggen of acties mogelijk maken die buiten de beoogde workflow vallen. Ruime deelrechten en onduidelijk eigenaarschap kunnen die blootstelling vergroten.

De omvang van het gebruik maakt consistent toezicht binnen afdelingen belangrijk. In een marktanalyse uit 2024 meldt Forrester dat 87% van de ontwikkelaars in grote ondernemingen low-codeplatforms gebruikt voor bepaalde ontwikkeltaken. Die bevinding gaat over ontwikkeling in het algemeen en laat dus zien hoe wijdverbreid de platforms zijn, maar meet niet specifiek het gebruik ervan voor AI-agents.

Praktische manieren om de beveiliging van low-code-agents te verbeteren

Teams moeten de machtigingen van connectors toetsen aan de taak die aan elke agent is toegewezen en toegang volgens het least-privilegeprincipe toepassen. Een centrale inventaris moet voor elke implementatie de eigenaar en de gekoppelde diensten vastleggen, met goedkeuringsvereisten voor gevoelige acties. Zo kunnen beveiligingsteams niet-geregistreerde agents opsporen en ongepaste toegang onderzoeken.

De aanpak van Microsoft voor gegevensbeheer benadrukt gecontroleerde toegang tot bedrijfsinformatie. Naveen Jangir, principal architect bij Microsoft Digital, adviseert organisaties om “de toegang ertoe te beheren en die informatie met passende toegangsbeperkingen te beschermen”. Dankzij deze maatregelen kunnen bevoegde gebruikers en AI-mogelijkheden de informatie gebruiken zonder die onnodig bloot te stellen binnen de vastgestelde machtigingsgrenzen. Door connectorbeleid te combineren met duidelijk eigenaarschap kunnen die beperkingen deel uitmaken van de dagelijkse ontwikkeling.

Beveiligingsrisico’s en oplossingen voor high-code-AI-agents

Wanneer teams AI-codeeragents gebruiken om aangepaste systemen te bouwen, kunnen gegenereerde wijzigingen binnenkomen in een tempo dat mensen niet kunnen bijhouden. Beveiliging bij high-codeontwikkeling vereist daarom maatregelen voor zowel het ontwikkelproces als de omgevingen waarin agents taken uitvoeren.

De unieke beveiligingsuitdagingen van high-codeontwikkeling

Codeeragents kunnen te maken krijgen met indirecte promptinjectie wanneer ze externe repositories lezen die instructies bevatten die door kwaadwillenden zijn aangeleverd. Als een agent die instructies opvolgt terwijl hij toegang heeft tot ontwikkeltools, kan hij onveilige opdrachten uitvoeren of inloggegevens blootleggen. De mogelijke gevolgen hangen deels af van de bestanden, tools en externe bestemmingen die de uitvoeringsomgeving toegankelijk maakt.

De richtlijnen van NVIDIA voor sandboxing behandelen het risico dat inloggegevens binnen die uitvoeringsgrens worden blootgesteld. Daarin staat dat “sandboxomgevingen expliciet geïnjecteerde geheimen moeten gebruiken” om de toegang tot inloggegevens te beperken. Daarom mogen agents niet alle omgevingsreferenties overnemen wanneer hun taken slechts beperkte toegang vereisen. Teams moeten inloggegevens beschikbaar stellen voor de specifieke taak en niet-gerelateerde geheimen buiten het bereik van de agent houden.

Strategieën voor het beveiligen van high-code-agentpijplijnen

Beperkte uitvoeringsomgevingen moeten de toegang tot bestanden en uitgaande verbindingen beperken op basis van de taak. Teams moeten ook statische applicatiebeveiligingstests uitvoeren op gegenereerde code. Onafhankelijke beoordelaars moeten autorisatiebeslissingen of bedrijfslogica controleren die geautomatiseerde controles mogelijk over het hoofd zien. Deze lagen pakken zowel de grenzen van de uitvoeringsomgeving als zwakke plekken in de resulterende software aan.

Amazon Web Services beveelt in zijn raamwerk voor beheersmaatregelen voor codeeragents aan om codegeneratie en evaluatie van elkaar te scheiden. Het merkt op dat “een aparte sessie helpt om bevestigingsvooroordeel te voorkomen”. Twee sessies met hetzelfde model kunnen tijdens een beoordeling echter dezelfde onderliggende blinde vlekken vertonen. Waar dat praktisch haalbaar is, kunnen een ander beoordelingsmodel en menselijke evaluatie van beveiligingsgevoelige wijzigingen voor extra controle zorgen.

Een beveiligingsstrategie ontwikkelen die beide benaderingen omvat

Voor AI-beveiliging bij de ontwikkeling van low-code- en high-code-agents is een gedeeld beeld nodig van de activiteiten op alle plekken waar agents informatie uitwisselen. Een low-code-workflow kan bijvoorbeeld inhoud naar een op maat gebouwde agent sturen, die vervolgens een andere bedrijfsservice aanroept. Als elk onderdeel afzonderlijk wordt beoordeeld, missen beveiligingsteams mogelijk de context die nodig is om de volledige reeks stappen te begrijpen.

De AI-beveiligingsexperts van Darktrace stellen dat organisaties  prompts en sessies moeten inspecteren, naast reacties binnen generatieve-AI-tools voor bedrijven en bij beide ontwikkelbenaderingen. Hun perspectief omvat ook software-as-a-service- en secure access service edge-omgevingen. Dankzij dit inzicht krijgen organisaties de context om “slimme conversationele promptaanvallen en kwaadaardige ketenvorming te detecteren”.

De visie van Darktrace ondersteunt een bredere AI-beveiligingsstrategie voor de ontwikkeling van low-code- en high-code-agents. Inzicht in prompts, sessiebewaking en toezicht op identiteiten helpen teams te begrijpen hoe agents met elkaar communiceren via verbonden tools. Beveiligingsteams moeten nagaan hoe instructies veranderen in verbonden sessies en of vervolghandelingen blijven overeenkomen met de oorspronkelijke autorisatie. Ook moeten ze rekening houden met de gevoeligheid van informatie die voor onderzoek wordt bewaard.

Governance en monitoring voor langdurige AI-agentbeveiliging

Elke agent moet een verantwoordelijke eigenaar hebben en een duidelijk afgebakende reeks toegestane werkzaamheden, ongeacht de ontwikkelmethode. Governance moet ook vastleggen wie wijzigingen in die reikwijdte mag goedkeuren en wie de activiteiten kan opschorten als een agent zich onverwacht gedraagt.

Onderzoek naar agentgovernance wijst erop dat agents  bevoegdheden nodig hebben waarvan de authenticiteit kan worden vastgesteld en die kunnen worden gecontroleerd, zodat verantwoordingsplicht wordt ondersteund. Zo wordt de persoon die toestemming verleent gekoppeld aan de taken die een agent mag uitvoeren. Organisaties kunnen een handeling vervolgens toetsen aan die autorisatie.

Teams moeten activiteiten registreren en daarin gedelegeerde machtigingen koppelen aan het gebruik van tools en de uitkomsten daarvan. Bij periodieke controles moeten die machtigingen opnieuw worden beoordeeld wanneer de mogelijkheden veranderen, moet overgebleven toegang na afronding van werkzaamheden worden ingetrokken en moet worden bevestigd dat het eigenaarschap nog actueel is. Ontwikkel- en beveiligingsteams kunnen deze controles gebruiken om operationele beheersmaatregelen in overeenstemming te houden met het goedgekeurde doel van de agent.

AI-agentbeveiligingsrisico’s voorblijven

Bij low-code-ontwikkeling zijn zorgvuldig beheer van platformmachtigingen en governance van connectors nodig, terwijl high-code-ontwikkeling vraagt om nauwlettend toezicht op aangepaste uitvoeringsomgevingen en codebeoordeling. Gecentraliseerde monitoring en consistente verantwoordingsplicht bieden een gemeenschappelijke basis om toezicht te houden op de manier waarop agents informatie raadplegen en handelen binnen verbonden bedrijfssystemen. Naarmate de mogelijkheden toenemen, moeten ontwikkelaars beveiligingsmaatregelen opnieuw beoordelen wanneer de tools en verantwoordelijkheden van agents veranderen. Zo blijft gedurende de hele levenscyclus van elke implementatie duidelijk welke activiteiten zijn toegestaan.