Beveiligingsagenten bouwen die hun vertrouwensgrens niet kunnen verlaten

De koppen over "modellen die ongetemde hackers zijn" verschijnen overal in je feed, waarbij het argument voornamelijk over intentie gaat. Intentie is echter het minst interessante deel. Wat echt van belang is, is dat je dit type model direct toegang geeft tot je eigen infrastructuur. Wanneer het gaat om het automatiseren van je beveiliging, zou het krankzinnig zijn om hen de uiteindelijke beslissing over hun acties te laten nemen. Totdat ze stoppen met het maken van fouten, kun je het je niet veroorloven dat je agent door hallucinaties data verwijdert of configuraties van je cloudinfrastructuur wijzigt.

Alternatieve benaderingen en hun beperkingen

Een manier om dit te omzeilen is door cruciale delen van je infrastructuur te spiegelen naar een data lake, waarbij de agent daar opereert en niet direct je live-infrastructuur aanraakt. Dit is hoe alle SaaS-beveiligingsproducten werken: Palo Alto Networks, CrowdStrike, Wiz en de AI-native uitdagers. Het is een valide pad, maar het heeft een prijs: kosten, partiële data, synchronisatievertraging en, belangrijker nog, je bent gedwongen te kiezen tussen verlies van datasouvereiniteit en enorme operationele overhead.

De klassieke asymmetrie tussen verdediger en aanvaller is reëel, en het wordt een groter probleem nu aanvallers beschikken over frontier-modellen en coderingsagenten om elke potentiële zwakke plek te vinden en automatisch uit te buiten. Middelen alleen compenseren dit gat niet langer zoals vroeger; je hebt een soevereine agent nodig met directe toegang tot je infrastructuur.

We hebben hetzelfde patroon gezien bij partners van enkele van de grootste ondernemingen, die beperkte vroege toegang kregen tot een van de topmodellen van de frontier-labs. Eindelijk hadden ze toegang tot een redeneermodel dat krachtiger was dan dat van de aanvallers. Maar omdat ze geen agent hadden die ze konden vertrouwen met dergelijke gevoelige toegang, kozen ze ervoor om code-repositories via de prompt te kopiëren en plakken — wat kostbaar is, waarbij de code geen runtime-omgeving heeft, er geen synchronisatie is en er een overhead ontstaat door een toegewezen team voor speciale missies dat geïsoleerd is van de rest van de organisatie.

De noodzaak van strikte grenzen

Je zou je agent least-privilege read-only toegang tot je infrastructuur moeten verlenen. Maar dat is niet genoeg: server-side identity and access management (IAM) in een grote organisatie heeft de neiging om te gaan "driften". Agenten zullen creatieve manieren vinden om hun eigen grenzen te wijzigen als je ze de kans geeft.

De aanpak die we hebben gehanteerd om dit gat te dichten bij het bouwen van onze infrastructure security deep research agent, Cynative, is een tweezijdige architectuur: een sandbox en een actie-poort (action-gate).

De Sandbox

De sandbox voert de door het model geschreven code uit zonder toegang tot de buitenwereld. Dit betekent:

• Geen netwerk;
• Geen bestandssysteem;
• Geen host-API's;
• Niets anders dan de tools die wij expliciet registreren.

De Action-gate

De actie-poort autoriseert elke connector-aanroep tegen een read-only beleid voordat er een credential wordt gekoppeld, en faalt in gesloten toestand (fails closed). De agent is dus by construction read-only, niet door middel van een optioneel filter waar hij via manipulatie omheen kan praten.

Op deze manier heeft de soevereine agent de flexibiliteit van een coderingsagent om tijdelijk te redeneren over de live data die hij nodig heeft, terwijl hij op geen enkele manier de live-infrastructuur kan wijzigen of data daaruit kan lekken. Hetzelfde principe geldt voor de rest: sessies die door de cloudprovider zelf read-only worden gehouden, geheimen die worden geredigeerd voordat ze het model bereiken en een fail-closed auditlog.

Implementatie en Soevereiniteit

Het model ziet nog steeds alles waar je het naar wijst. Daarom wordt Cynative geleverd als een enkel binair bestand dat draait binnen je eigen omgeving, tegen welk model-endpoint je ook kiest — inclusief de endpoints die je cloudprovider al voor je draait. Als je dit richt op die endpoints en de infrastructuur, bevinden het model en de agent zich in hetzelfde account: je voert beveiliging uit op je infrastructuur, vanuit je infrastructuur.

Voorwaarden voor een veilige grens

Als je je eigen beveiligingsagent bouwt, blijft de grens overeind wanneer aan twee voorwaarden wordt voldaan:

1. De redeneeromgeving kan niets bereiken dat je niet expliciet hebt overhandigd.
2. De toegestane set is bepaald tijdens het ontwerp (design time), zonder dat de agent een weg heeft om deze tijdens de uitvoering te verbreden.

Als je dit fout doet, wordt de grens een suggestie die het model vrij kan herinterpreteren op het moment dat het besluit dat de taak daarom vraagt. Als je het goed doet, kun je het systeem op de productieomgeving richten en met een gerust hart gaan slapen.

We hebben dit ontwikkeld als een open-source project, zodat je het gratis kunt gebruiken om diepgaand onderzoek te doen naar je infrastructuur of als framework om je eigen beveiligingsagenten te bouwen door gebruik te maken van deze architectuur en het implementeren van je eigen workflows en logica.

Code en documentatie zijn beschikbaar op: github.com/cynative/cynative