Obsidian Security lanserar en policybeslutsmotor för körning som ska styra AI-agenters åtgärder

Obsidian Security har lanserat en policybeslutsmotor för körning som ska göra det möjligt för företag att styra vad AI-agenter gör i affärsapplikationer innan en åtgärd utförs. Tillkännagivandet utökar företagets plattform för agentsäkerhet med en MCP-säkerhetsproxy, ett API för policybeslut och utökat stöd för kodverktyg och agenter som är inbyggda i programvara från tredje part.

Lanseringen tar sikte på ett problem som vanliga åtkomstkontroller inte löser fullt ut: en agent kan ha giltiga inloggningsuppgifter och använda en godkänd applikation, men ändå försöka utföra en olämplig åtgärd. Behörighet att läsa kunduppgifter innebär till exempel inte nödvändigtvis att agenten får exportera dem till en extern destination.

Obsidian utvärderar den föreslagna åtgärden mot centralt hanterade policyer med hänsyn till personen bakom agenten, personens anställning och behörigheter, den berörda applikationen och kundens egna dataklassificeringar. Anslutna kontrollpunkter tillåter eller blockerar sedan åtgärden, eller kräver godkännande där den funktionen stöds.

Från att upptäcka agenter till att styra deras åtgärder

Agentidentifiering visar vilka verktyg som finns och vad de kan komma åt. Styrning kan minska onödiga behörigheter eller identifiera riskfyllda konfigurationer. Policyer vid körning hanterar den återstående frågan: Vad ska en i övrigt behörig agent få göra just nu?

Obsidian beskriver i sitt tillkännagivande både agenter som används av anställda och agenter som ingår i programvara som företaget redan använder. De utökade funktionerna för identifiering och styrning omfattar Salesforce Agentforce, Databricks, GitHub, Microsoft 365, Snowflake, ServiceNow och Workday.

Det här är olika kontrollpunkter. Att hitta en agent i en SaaS-applikation innebär inte i sig att varje åtgärd i applikationen fångas upp. Kontroll vid körning beror på vilken integration som stöds och vilken väg åtgärden passerar genom.

Företaget har också lagt till stöd för policyer vid körning för OpenAI Codex, utöver sina befintliga kontroller för kodningsagenter. I tillkännagivandet pekar företaget på risker som destruktiva kommandon, exponering av inloggningsuppgifter och läsning utanför projektets avsedda omfattning – åtgärder som kan förekomma under en i övrigt legitim utvecklingssession.

Kunskapsgrafen tillför det sammanhang som saknas

En gateway kan granska en begäran, men begäran i sig kanske inte visar vilken behörighet som ligger bakom den. För att fatta ett välgrundat säkerhetsbeslut kan det krävas information om huruvida det anropande kontot tillhör en anställd eller en uppdragstagare, om anställningen har upphört och vilka behörigheter kontot faktiskt har i destinationsapplikationen.

Obsidians Knowledge Graph-arkitektur kopplar samman personer, konton, applikationer, token, behörigheter och deras inbördes relationer. Företaget beskriver hur information från administrativa API:er, aktivitetsflöden och integrationer normaliseras till en gemensam modell, med versionshanterade entiteter och relationer som fångar förändringar över tid.

Den strukturen gör det lättare att spåra åtkomst i flera system, i stället för att granska varje konto för sig. En agent kan verka ha en begränsad roll, samtidigt som en token eller en ärvd behörighet ger den större räckvidd på andra håll. Genom att koppla samman relationerna får policymotorn ett bättre underlag för att avgöra om en viss åtgärd följer organisationens regler.

Kunder kan lägga till eget sammanhang, bland annat klassificeringsetiketter. En policy kan därmed skilja mellan en vanlig fil och en fil som företaget klassar som mycket känslig, i stället för att enbart förlita sig på en säkerhetsleverantörs allmänna definition av konfidentiella uppgifter.

Där beslutet omsätts i kontroll

Arkitekturen skiljer mellan att fatta beslut och att utföra åtgärder. I Obsidians förklaring av körningsmotorn pausar en kontrollpunkt en föreslagen åtgärd, skickar in uppgifter om den för utvärdering och tillämpar det returnerade beslutet och dess motivering.

Det nya API:et för policybeslut utökar modellen till kunddrivna gateways, agenternas körmiljöer och arbetsflöden. Ett företag kan behålla sin befintliga infrastruktur och samtidigt be Obsidian om ett kontextmedvetet beslut. Kundens kontrollkomponent måste sedan tillämpa beslutet innan åtgärden kan fortsätta.

Obsidian dokumenterar också ett flaggläge för att testa policyträffar mot verklig trafik innan åtgärder blockeras. Beslutsloggar registrerar agenten, personen som gjorde anropet, verktyget, argumenten, resultatet och den matchande policyn, så att säkerhetsteam kan utreda varför en åtgärd tilläts eller stoppades.

Stödet för godkännande är mer begränsat än den övergripande lösningen för att tillåta eller blockera åtgärder: enligt företagets aktuella dokumentation går det att kräva godkännande för Claude Code-policyer som körs innan en åtgärd utförs. Därför är funktionerna på integrationsnivå viktiga när kontroller utformas för en blandad uppsättning agenter.

MCP-proxyn håller applikationernas token borta från AI-klienter

Säkerhetsproxy för MCP styr anslutningar mellan AI-klienter och företagsapplikationer som stöds. Model Context Protocol, eller MCP, ger agenter ett standardiserat sätt att anropa verktyg som exponeras av externa servrar. Obsidian placerar en policykontroll mellan klienten och applikationens MCP-server.

I produktdokumentationen beskriver företaget hur leverantörens direkta MCP-URL ersätts med en slutpunkt som styrs av Obsidian. Användarna godkänner åtkomsten via tillämpningsleverantörens samtyckesflöde. AI-klienten får en token som utfärdats av proxyn, i stället för att själv lagra tillämpningens åtkomsttoken.

Proxyn kopplar en session till användaren, användarens konto i tillämpningen och den aktuella klientorganisationen, till exempel en viss Salesforce-organisation eller arbetsyta. Den kontrollerar verktygsanrop innan de vidarebefordras och registrerar om de tilläts eller blockerades. Enligt Obsidian sker detta inom ramen för användarens befintliga behörigheter i tillämpningen, i stället för att utöka behörigheterna via ett delat tjänstekonto.

I tillkännagivandet nämns också ett samarbete med Cloudflare och företagets MCP Server Portal. Målet är att kombinera en gateways position i trafikflödet med Obsidians identitets-, tillämpnings- och datakontext.

Därför är kontroller på åtgärdsnivå viktiga

För företag som inför agenter är den praktiska utmaningen att tillåta nyttigt arbete och samtidigt begränsa konsekvenserna av allvarliga misstag. Ett generellt förbud kan stoppa ett arbetsflöde helt, medan ett snävt avgränsat beslut kan tillåta rutinmässiga läsåtgärder och samtidigt stoppa en obehörig export eller kräva granskning av en destruktiv ändring.

Obsidian samlar dessa beslut i ett gemensamt policylager för verktyg och kontrollpunkter som stöds. Värdet beror på kvaliteten på den underliggande åtkomstkontexten och på hur fullständigt de berörda flödena omfattas av kontrollen. I takt med att agenter får ett större operativt ansvar blir möjligheten att förklara och verkställa ett beslut innan det genomförs en allt viktigare del av företagssäkerheten.