Obsidian Security lancerer en politikmotor til kørsel, der styrer AI-agenters handlinger

Obsidian Security har lanceret en beslutningsmotor til politikker under kørsel, der skal gøre det muligt for virksomheder at styre, hvad AI-agenter gør i forretningsapplikationer, før en handling udføres. Med lanceringen udvides virksomhedens platform til agentsikkerhed med en MCP-sikkerhedsproxy, et API til politikbeslutninger og udvidet dækning af programmeringsværktøjer og agenter, der er indlejret i tredjepartssoftware.

Lanceringen tager fat på et problem, som almindelige adgangskontroller ikke løser fuldt ud: En agent kan have gyldige legitimationsoplysninger og bruge en godkendt applikation, men stadig forsøge at udføre en uhensigtsmæssig handling. Tilladelse til at læse kundeoplysninger betyder for eksempel ikke nødvendigvis, at man også har tilladelse til at eksportere dem til en ekstern destination.

Obsidian evaluerer den foreslåede handling i forhold til centralt administrerede politikker. I vurderingen indgår personen bag agenten, vedkommendes ansættelsesforhold og tilladelser, den pågældende applikation samt dataklassifikationer, som kunden har angivet. Tilknyttede håndhævelsespunkter tillader eller blokerer derefter handlingen eller kræver godkendelse, hvor denne funktion understøttes.

Fra opdagelse af agenter til styring af deres handlinger

Opdagelse af agenter afdækker, hvilke værktøjer der er til stede, og hvad de har adgang til. Styring kan begrænse unødvendige tilladelser eller identificere risikable konfigurationer. Politikstyring ved kørsel besvarer det resterende spørgsmål: Hvad bør en agent, der ellers er godkendt, have lov til at gøre lige nu?

Obsidians annoncering omfatter både agenter, der betjenes af medarbejdere, og agenter, der følger med software, som virksomheden allerede bruger. De udvidede funktioner til opdagelse og styring omfatter Salesforce Agentforce, Databricks, GitHub, Microsoft 365, Snowflake, ServiceNow og Workday.

Der er tale om forskellige kontrolpunkter. At finde en agent i en SaaS-applikation betyder ikke i sig selv, at alle handlinger i applikationen opfanges. Håndhævelse af politikker ved kørsel afhænger af den understøttede integration og det punkt, som handlingen passerer igennem.

Virksomheden har også tilføjet understøttelse af politikstyring ved kørsel for OpenAI Codex, som supplement til de eksisterende kontroller for kodningsagenter. I sin annoncering fremhæver virksomheden risici som destruktive kommandoer, eksponering af legitimationsoplysninger og læsning uden for et projekts tilsigtede afgrænsning – handlinger, der kan forekomme under en ellers legitim udviklingssession.

Vidensgrafen leverer den manglende kontekst

En gateway kan undersøge en anmodning, men anmodningen alene forklarer muligvis ikke, hvilke rettigheder der ligger bag den. For at træffe en sikkerhedsbeslutning kan det være nødvendigt at vide, om den konto, der foretager handlingen, tilhører en medarbejder eller en kontrahent, om ansættelsesforholdet er ophørt, og hvilke tilladelser kontoen faktisk har i destinationsapplikationen.

Obsidians Knowledge Graph-arkitektur forbinder personer, konti, applikationer, tokens, rettigheder og relationerne mellem dem. Virksomheden beskriver, hvordan oplysninger fra administrative API’er, aktivitetsstrømme og integrationer normaliseres til en fælles model med versionsstyrede enheder og relationer, der registrerer ændringer over tid.

Denne struktur gør det lettere at spore adgang på tværs af flere systemer i stedet for at undersøge hver konto isoleret. En agents tilsyneladende rolle kan være begrænset, mens et token eller en nedarvet rettighed giver den bredere adgang andre steder. Når disse relationer forbindes, får politikmotoren et bedre grundlag for at afgøre, om en bestemt handling er i overensstemmelse med organisationens regler.

Kunderne kan tilføje deres egen kontekst, herunder klassifikationsmærkater. En politik kan dermed skelne mellem en almindelig fil og en fil, som virksomheden betegner som yderst følsom, i stedet for udelukkende at basere sig på en sikkerhedsleverandørs generelle definition af fortrolige data.

Her bliver beslutningen håndhævet

Arkitekturen adskiller beslutningstagning fra handling. I Obsidians forklaring af kørselsmotoren sætter et håndhævelsespunkt en foreslået handling på pause, sender dens oplysninger til vurdering og anvender den returnerede beslutning og begrundelse.

Den nye API til politikbeslutninger udvider denne model til gateways, agentmiljøer og arbejdsgange, som kunden selv driver. En virksomhed kan beholde sin eksisterende infrastruktur og samtidig bede Obsidian om en kontekstbaseret vurdering. Kundens håndhævelseskomponent skal derefter anvende vurderingen, før handlingen kan fortsætte.

Obsidian beskriver også en flagtilstand, hvor politikoverensstemmelser kan afprøves mod faktisk trafik, før handlinger blokeres. Beslutningsregistreringer indeholder oplysninger om agenten, personen, der foretog handlingen, værktøjet, argumenterne, udfaldet og den politik, der blev matchet. Det giver sikkerhedsteams mulighed for at undersøge, hvorfor en handling blev tilladt eller stoppet.

Understøttelsen af godkendelse er mere begrænset end den overordnede model, hvor handlinger enten tillades eller blokeres: Virksomhedens aktuelle dokumentation angiver, at kravet om godkendelse kun er tilgængeligt for Claude Code-politikker, der køres, før en handling udføres. Derfor er funktionerne på integrationsniveau vigtige, når der skal udformes kontroller til en blandet sammensætning af agenter.

MCP-proxyen holder applikationstokens ude af AI-klienter

MCP-sikkerhedsproxyen styrer forbindelser mellem AI-klienter og understøttede forretningsapplikationer. Model Context Protocol, eller MCP, giver agenter en standardiseret måde at kalde værktøjer, der stilles til rådighed af eksterne servere. Obsidian placerer et politikontrolpunkt mellem klienten og applikationens MCP-server.

Produktdokumentationen beskriver, hvordan leverandørens direkte MCP-URL erstattes med et slutpunkt, der styres af Obsidian. Brugerne godkender adgangen via applikationsleverandørens samtykkeproces; AI-klienten modtager et token udstedt af proxyen i stedet for selv at lagre applikationens adgangstoken.

Proxyen knytter en session til brugeren, dennes applikationskonto og den relevante tenant, f.eks. en bestemt Salesforce-organisation eller et bestemt arbejdsområde. Den kontrollerer værktøjskald, inden de videresendes, og registrerer, om de blev tilladt eller blokeret. Obsidian oplyser, at dette fungerer inden for brugerens eksisterende applikationstilladelser i stedet for at tilføje rettigheder via en delt tjenestekonto.

Meddelelsen fremhæver også et samarbejde med Cloudflare og virksomhedens MCP Server Portal. Målet er at kombinere en gateways placering i trafikstrømmen med Obsidians kontekst om identitet, applikationer og data.

Derfor er kontroller på handlingsniveau vigtige

For virksomheder, der tager agenter i brug, er den praktiske udfordring at tillade nyttigt arbejde og samtidig begrænse alvorlige fejl. Et generelt forbud kan standse en arbejdsgang fuldstændigt; en snævert afgrænset beslutning kan lade rutinemæssige læsehandlinger fortsætte, mens den stopper en uautoriseret eksport eller kræver gennemgang af en destruktiv ændring.

Obsidian samler disse beslutninger i et fælles politiklag på tværs af understøttede værktøjer og håndhævelsespunkter. Værdien afhænger af kvaliteten af den underliggende adgangskontekst og af, hvor fuldstændigt de relevante adgangsveje er dækket af kontroller. Efterhånden som agenter får større operationelt ansvar, bliver evnen til at forklare og håndhæve en beslutning, før den udføres, en stadig vigtigere del af virksomhedssikkerheden.