Obsidian Security lanceert een runtimebeleidsengine om acties van AI-agenten te beheersen

Obsidian Security heeft een runtime-engine voor beleidsbeslissingen gelanceerd waarmee ondernemingen kunnen bepalen wat AI-agenten binnen bedrijfsapplicaties doen, voordat een actie wordt uitgevoerd. De aankondiging breidt het platform voor agentbeveiliging van het bedrijf uit met een MCP-beveiligingsproxy, een API voor beleidsbeslissingen en aanvullende ondersteuning voor programmeertools en agenten die zijn ingebouwd in software van derden.

De lancering richt zich op een probleem dat met gewone toegangscontroles niet volledig wordt opgelost: een agent kan geldige inloggegevens hebben en een goedgekeurde applicatie gebruiken, maar toch proberen een ongepaste actie uit te voeren. Toestemming om klantgegevens te lezen betekent bijvoorbeeld niet noodzakelijkerwijs dat er ook toestemming is om die gegevens naar een externe bestemming te exporteren.

Obsidian beoordeelt de voorgestelde actie aan de hand van centraal beheerd beleid. Daarbij kijkt het naar de persoon achter de agent, diens dienstverband en machtigingen, de betrokken applicatie en door de klant aangeleverde gegevensclassificaties. Aangesloten handhavingspunten staan de actie vervolgens toe of blokkeren die, of vereisen goedkeuring wanneer die mogelijkheid wordt ondersteund.

Van agenten opsporen naar hun acties beheersen

Agentdetectie brengt in kaart welke tools aanwezig zijn en waartoe ze toegang hebben. Governance kan onnodige machtigingen beperken of risicovolle configuraties opsporen. Runtimebeleid richt zich op de resterende vraag: wat mag een verder bevoegde agent op dit moment doen?

De aankondiging van Obsidian heeft betrekking op zowel agenten die door medewerkers worden bediend als agenten die zijn opgenomen in software die de onderneming al gebruikt. De uitgebreide mogelijkheden voor detectie en governance omvatten Salesforce Agentforce, Databricks, GitHub, Microsoft 365, Snowflake, ServiceNow en Workday.

Dit zijn verschillende aangrijpingspunten voor controle. Het opsporen van een agent in een SaaS-applicatie betekent op zichzelf niet dat elke actie in die applicatie wordt onderschept. Handhaving tijdens runtime hangt af van de ondersteunde integratie en het punt waarlangs een actie wordt uitgevoerd.

Het bedrijf heeft ook runtimebeleidsondersteuning toegevoegd voor OpenAI Codex, naast de bestaande controles voor programmeeragenten. In de aankondiging worden risico’s genoemd zoals destructieve opdrachten, het blootleggen van inloggegevens en het lezen van gegevens buiten de beoogde reikwijdte van een project. Dergelijke acties kunnen plaatsvinden tijdens een verder legitieme ontwikkelsessie.

De Knowledge Graph levert de ontbrekende context

Een gateway kan een verzoek inspecteren, maar uit het verzoek alleen blijkt mogelijk niet welke bevoegdheden eraan ten grondslag liggen. Voor een goed onderbouwde beveiligingsbeslissing kan het nodig zijn te weten of de account van waaruit het verzoek wordt gedaan bij een werknemer of opdrachtnemer hoort, of het dienstverband is beëindigd en over welke machtigingen de account daadwerkelijk beschikt in de doelapplicatie.

De architectuur van de Knowledge Graph van Obsidian brengt personen, accounts, applicaties, tokens, rechten en de onderlinge relaties daartussen met elkaar in verband. Het bedrijf beschrijft hoe informatie uit beheer-API’s, activiteitenstromen en integraties wordt genormaliseerd tot één gemeenschappelijk model, met geversioneerde entiteiten en relaties om veranderingen in de loop van de tijd vast te leggen.

Dankzij die structuur kan toegang in meerdere systemen worden gevolgd, in plaats van elke account afzonderlijk te bekijken. De rol die een agent lijkt te hebben, kan beperkt zijn, terwijl een token of overgeërfd recht die agent elders een ruimer bereik geeft. Door die relaties met elkaar in verband te brengen, beschikt de beleidsengine over een betere basis om te bepalen of een bepaalde actie strookt met de regels van de organisatie.

Klanten kunnen hun eigen context toevoegen, waaronder classificatielabels. Zo kan beleid onderscheid maken tussen een gewoon bestand en een bestand dat het bedrijf als zeer gevoelig aanmerkt, in plaats van uitsluitend af te gaan op de generieke definitie van vertrouwelijke gegevens van een beveiligingsleverancier.

Waar de beslissing wordt gehandhaafd

De architectuur scheidt beslissen van handelen. In Obsidians uitleg over de runtime-engine pauzeert een handhavingspunt een voorgestelde bewerking, stuurt het de details ervan ter beoordeling door en past het de geretourneerde beslissing en reden toe.

De nieuwe API voor beleidsbeslissingen breidt dit model uit naar gateways, agentharnassen en workflows die door klanten worden beheerd. Een onderneming kan haar bestaande infrastructuur behouden en tegelijk Obsidian om een contextbewust oordeel vragen. Het handhavingsonderdeel van de klant moet dat oordeel vervolgens toepassen voordat de bewerking wordt voortgezet.

Obsidian documenteert ook een flagmodus om beleidstreffers op echt verkeer te testen voordat bewerkingen worden geblokkeerd. Beslissingsgegevens leggen de agent, de persoon die het verzoek indient, de tool, de argumenten, de uitkomst en het overeenkomende beleid vast. Zo kunnen beveiligingsteams onderzoeken waarom een actie werd toegestaan of tegengehouden.

Ondersteuning voor goedkeuring is beperkter dan de algemene architectuur voor toestaan of blokkeren: volgens de huidige documentatie van het bedrijf is het vereisen van goedkeuring beschikbaar voor Claude Code-beleid dat vóór een bewerking wordt uitgevoerd. Daarom zijn de mogelijkheden op integratieniveau van belang bij het ontwerpen van controles voor een gemengde verzameling agenten.

De MCP-proxy houdt applicatietokens buiten AI-clients

De MCP-beveiligingsproxy beheert verbindingen tussen AI-clients en ondersteunde zakelijke toepassingen. Het Model Context Protocol, of MCP, biedt agents een gestandaardiseerde manier om tools aan te roepen die door externe servers beschikbaar worden gesteld. Obsidian plaatst een beleidscontrole tussen de client en de MCP-server van de toepassing.

In de productdocumentatie beschrijft Obsidian hoe de directe MCP-URL van de leverancier wordt vervangen door een door Obsidian beheerd eindpunt. Gebruikers verlenen toegang via de toestemmingsprocedure van de applicatieleverancier; de AI-client ontvangt een door de proxy uitgegeven token, in plaats van zelf het toegangstoken voor de applicatie op te slaan.

De proxy koppelt een sessie aan de gebruiker, diens account bij de applicatie en de relevante tenant, zoals een specifieke Salesforce-organisatie of -werkruimte. De proxy controleert toolaanroepen voordat die worden doorgestuurd en registreert of ze zijn toegestaan of geblokkeerd. Volgens Obsidian werkt dit binnen de bestaande machtigingen van de gebruiker voor de applicatie, zonder extra rechten toe te kennen via een gedeeld serviceaccount.

In de aankondiging wordt ook melding gemaakt van een samenwerking met Cloudflare en diens MCP Server Portal. Het doel is de positie van een gateway in het netwerkverkeer te combineren met Obsidian’s context over identiteit, applicaties en gegevens.

Waarom controles op actieniveau belangrijk zijn

Voor ondernemingen die agents inzetten, is de praktische uitdaging om nuttig werk mogelijk te maken en tegelijk de gevolgen van ernstige fouten te beperken. Een algeheel verbod kan een workflow volledig stilleggen; met een nauwkeurig afgebakende beslissing kunnen routinematige leesacties doorgaan, terwijl een ongeoorloofde export wordt tegengehouden of voor een ingrijpende wijziging eerst goedkeuring wordt vereist.

Obsidian brengt deze beslissingen onder in één gedeelde beleidslaag voor ondersteunde tools en handhavingspunten. De waarde daarvan hangt af van de kwaliteit van de onderliggende toegangscontext en van de volledigheid van de paden waarover controle wordt uitgeoefend. Naarmate agents meer operationele verantwoordelijkheid krijgen, wordt het vermogen om een beslissing vóór uitvoering toe te lichten en af te dwingen een steeds belangrijker onderdeel van de beveiliging van ondernemingen.