Obsidian Security lanserer policybeslutningsmotor for kjøretid som skal styre handlingene til KI-agenter

Obsidian Security har lansert en beslutningsmotor for kjøretidspolicy, utviklet for å la virksomheter kontrollere hva KI-agenter gjør i forretningsapplikasjoner, før en handling utføres. Kunngjøringen utvider selskapets plattform for agentsikkerhet med en sikkerhetsproxy for MCP, et API for policybeslutninger og utvidet dekning av kodeverktøy og agenter som er innebygd i tredjepartsprogramvare.

Lanseringen tar sikte på å løse et problem som vanlige tilgangskontroller ikke håndterer fullt ut: En agent kan ha gyldig påloggingsinformasjon og bruke en godkjent applikasjon, men likevel forsøke å utføre en upassende handling. Tillatelse til å lese kundeopplysninger innebærer for eksempel ikke nødvendigvis tillatelse til å eksportere dem til et eksternt mål.

Obsidian evaluerer den foreslåtte handlingen opp mot sentralt administrerte retningslinjer. Vurderingen tar utgangspunkt i personen bak agenten, vedkommendes ansettelsesforhold og tillatelser, den aktuelle applikasjonen og dataklassifiseringer som kunden har oppgitt. Tilknyttede kontrollpunkter kan deretter tillate eller blokkere handlingen, eller kreve godkjenning der denne funksjonen støttes.

Fra å oppdage agenter til å styre handlingene deres

Agentoppdagelse avklarer hvilke verktøy som finnes, og hva de har tilgang til. Styring kan redusere unødvendige tillatelser eller avdekke risikable konfigurasjoner. Retningslinjer for kjøretid tar for seg det gjenstående spørsmålet: Hva bør en agent som ellers er autorisert, få lov til å gjøre akkurat nå?

Obsidian kunngjør støtte for både agenter som brukes av ansatte, og agenter som følger med programvare virksomheten allerede bruker. De utvidede funksjonene for oppdagelse og styring omfatter Salesforce Agentforce, Databricks, GitHub, Microsoft 365, Snowflake, ServiceNow og Workday.

Dette er ulike kontrollpunkter. At en agent oppdages i en SaaS-applikasjon, betyr ikke i seg selv at alle handlinger i applikasjonen fanges opp. Håndheving ved kjøretid avhenger av den støttede integrasjonen og hvilket punkt handlingen går gjennom.

Selskapet har også lagt til støtte for retningslinjer ved kjøretid for OpenAI Codex, i tillegg til de eksisterende kontrollene for kodeagenter. I kunngjøringen peker selskapet på risikoer som destruktive kommandoer, eksponering av påloggingsinformasjon og lesing utenfor prosjektets tiltenkte omfang – handlinger som kan forekomme i en ellers legitim utviklingsøkt.

Kunnskapsgrafen gir den manglende konteksten

En gateway kan undersøke en forespørsel, men forespørselen alene forklarer kanskje ikke hvilke rettigheter som ligger bak den. For å ta en god sikkerhetsbeslutning kan det være nødvendig å vite om kontoen som utløser handlingen, tilhører en ansatt eller en konsulent, om arbeidsforholdet er avsluttet, og hvilke tillatelser kontoen faktisk har i målapplikasjonen.

Obsidians Knowledge Graph-arkitektur kobler sammen personer, kontoer, applikasjoner, tokener, rettigheter og relasjonene mellom dem. Selskapet beskriver hvordan informasjon fra administrative API-er, aktivitetsstrømmer og integrasjoner normaliseres til en felles modell med versjonerte enheter og relasjoner, slik at endringer over tid kan fanges opp.

Denne strukturen gjør det enklere å spore tilgang på tvers av flere systemer, i stedet for å undersøke hver konto isolert. En agent kan tilsynelatende ha en begrenset rolle, samtidig som et token eller en arvet rettighet gir den bredere tilgang andre steder. Når disse relasjonene kobles sammen, får policy-motoren et bedre grunnlag for å avgjøre om en bestemt handling er i tråd med virksomhetens regler.

Kundene kan legge til sin egen kontekst, blant annet klassifiseringsetiketter. Dermed kan en policy skille mellom en vanlig fil og en fil virksomheten har klassifisert som svært sensitiv, i stedet for å basere seg utelukkende på en sikkerhetsleverandørs generelle definisjon av konfidensielle data.

Fra beslutning til håndheving

Arkitekturen skiller mellom å ta en beslutning og å utføre en handling. I Obsidians forklaring av kjøretidsmotoren setter et håndhevingspunkt en foreslått operasjon på pause, sender inn opplysningene om den for vurdering og følger den returnerte beslutningen og begrunnelsen.

Det nye API-et for policybeslutninger utvider denne modellen til kundedrevne gatewayer, agentrammeverk og arbeidsflyter. En virksomhet kan beholde den eksisterende infrastrukturen sin og samtidig be Obsidian om en kontekstsensitiv vurdering. Kundens håndhevingskomponent må deretter iverksette beslutningen før operasjonen fortsetter.

Obsidian beskriver også en flaggmodus for å teste hvilke policyer som slår inn på reell trafikk, før operasjoner blokkeres. Beslutningslogger registrerer agenten, personen som utløste handlingen, verktøyet, argumentene, utfallet og den aktuelle policyen. Dermed kan sikkerhetsteam undersøke hvorfor en handling ble tillatt eller stanset.

Støtten for godkjenning er mer begrenset enn den overordnede modellen for å tillate eller blokkere handlinger: Ifølge selskapets gjeldende dokumentasjon er det mulig å kreve godkjenning for Claude Code-policyer som kjøres før en operasjon. Derfor er funksjonene i de enkelte integrasjonene viktige når man utformer kontroller for en blandet samling agenter.

MCP-proxyen holder applikasjonstokener utenfor KI-klienter

MCP-sikkerhetsproxyen styrer forbindelsene mellom KI-klienter og støttede forretningsapplikasjoner. Model Context Protocol, eller MCP, gir agenter en standardisert måte å kalle opp verktøy som eksterne tjenere tilbyr. Obsidian legger inn en policykontroll mellom klienten og applikasjonens MCP-tjener.

Produktdokumentasjonen beskriver hvordan leverandørens direkte MCP-URL erstattes med et Obsidian-styrt endepunkt. Brukerne gir tilgangstillatelse gjennom applikasjonsleverandørens samtykkeflyt; KI-klienten mottar et token utstedt av proxyen i stedet for å lagre applikasjonens tilgangstoken selv.

Proxyen knytter en økt til brukeren, brukerens applikasjonskonto og den relevante leietakeren, for eksempel en bestemt Salesforce-organisasjon eller et bestemt arbeidsområde. Den kontrollerer verktøykall før den videresender dem, og registrerer om de ble tillatt eller blokkert. Obsidian sier at dette skjer innenfor brukerens eksisterende applikasjonstillatelser, i stedet for å gi ekstra privilegier via en delt tjenestekonto.

Kunngjøringen omtaler også et samarbeid med Cloudflare og deres MCP Server Portal. Målet er å kombinere en gateways plassering i trafikkbanen med Obsidians kontekst om identitet, applikasjoner og data.

Derfor er kontroller på handlingsnivå viktige

For virksomheter som tar i bruk agenter, er den praktiske utfordringen å tillate nyttig arbeid og samtidig begrense konsekvensene av alvorlige feil. Et totalforbud kan stanse en arbeidsflyt fullstendig; en avgrenset beslutning kan la rutinemessige leseoperasjoner gå videre, samtidig som den stanser en uautorisert eksport eller krever gjennomgang av en destruktiv endring.

Obsidian samler disse beslutningene i et felles policylag på tvers av støttede verktøy og håndhevingspunkter. Verdien vil avhenge av kvaliteten på den underliggende tilgangskonteksten og hvor fullstendig kontrollen dekker alle banene. Etter hvert som agenter får større operativt ansvar, blir evnen til å forklare og håndheve en beslutning før den iverksettes en stadig viktigere del av virksomhetssikkerheten.