Obsidian Security, AI 에이전트의 동작을 제어하는 런타임 정책 엔진 출시

Obsidian Security는 AI 에이전트가 비즈니스 애플리케이션에서 수행하는 작업을 실행 전에 기업이 제어할 수 있도록 설계된 런타임 정책 결정 엔진을 출시했다. 이번 발표로 회사의 에이전트 보안 플랫폼이 확장되어 MCP 보안 프록시와 정책 결정 API가 추가됐으며, 코딩 도구와 타사 소프트웨어에 내장된 에이전트에 대한 지원 범위도 넓어졌다.

이번 출시는 일반적인 접근 제어만으로는 완전히 해결되지 않는 문제를 다룬다. 에이전트가 유효한 자격 증명을 보유하고 승인된 애플리케이션을 사용하더라도 부적절한 작업을 시도할 수 있다. 예를 들어 고객 기록을 읽을 권한이 있다고 해서 외부 대상으로 내보낼 권한까지 반드시 있는 것은 아니다.

Obsidian은 에이전트 뒤에 있는 사용자와 그 사용자의 고용 상태 및 권한, 관련 애플리케이션, 고객이 제공한 데이터 분류를 바탕으로 제안된 작업을 중앙에서 관리하는 정책에 따라 평가한다. 그런 다음 연결된 집행 지점에서 작업을 허용하거나 차단하고, 해당 기능이 지원되는 경우 승인을 요구할 수 있다.

에이전트 탐지에서 에이전트 동작 제어까지

에이전트 탐지는 어떤 도구가 있는지, 그리고 그 도구가 무엇에 접근할 수 있는지 파악한다. 거버넌스는 불필요한 권한을 줄이거나 위험한 구성을 식별할 수 있다. 런타임 정책은 그다음 질문에 답한다. 다른 면에서는 권한이 있는 에이전트가 바로 지금 어떤 작업을 수행하도록 허용해야 하는가?

Obsidian의 발표는 직원이 직접 운영하는 에이전트와 기업이 이미 사용하는 소프트웨어에 내장되어 제공되는 에이전트를 모두 다룬다. 확장된 탐지 및 거버넌스 기능에는 Salesforce Agentforce, Databricks, GitHub, Microsoft 365, Snowflake, ServiceNow, Workday가 포함된다.

이들은 서로 다른 제어 지점이다. SaaS 애플리케이션 안에서 에이전트를 찾아냈다고 해서 해당 애플리케이션의 모든 작업이 가로채지는 것은 아니다. 런타임 집행은 지원되는 통합 기능과 작업이 통과하는 지점에 따라 달라진다.

회사는 기존 코딩 에이전트 제어 기능에 더해 OpenAI Codex에 대한 런타임 정책 지원도 추가했다. 발표에서는 파괴적인 명령, 자격 증명 노출, 프로젝트의 의도된 범위를 벗어난 읽기 작업 등을 위험 요소로 꼽았다. 이런 작업은 그 밖의 과정이 정상적으로 진행되는 개발 세션 중에도 발생할 수 있다.

누락된 맥락을 제공하는 지식 그래프

게이트웨이는 요청을 검사할 수 있지만, 요청만으로는 그 요청에 따르는 권한의 근거를 파악하기 어려울 수 있다. 보안 결정을 제대로 내리려면 요청 계정이 직원이나 계약직 근로자의 계정인지, 고용 관계가 종료됐는지, 그리고 해당 계정이 대상 애플리케이션에서 실제로 어떤 권한을 보유하는지 알아야 할 수 있다.

Obsidian의 Knowledge Graph 아키텍처는 사람, 계정, 애플리케이션, 토큰, 권한 및 이들 간의 관계를 연결한다. 회사 설명에 따르면 관리 API, 활동 스트림, 통합 기능에서 얻은 정보를 공통 모델로 정규화하고, 버전이 관리되는 엔터티와 관계를 이용해 시간에 따른 변화를 기록한다.

이 구조를 이용하면 각 계정을 따로 살펴보는 대신 여러 시스템에 걸친 접근 권한을 추적할 수 있다. 에이전트의 겉보기 역할은 제한적일 수 있지만, 토큰이나 상속된 권한으로 다른 곳까지 더 폭넓게 접근할 수도 있다. 이러한 관계를 연결하면 특정 작업이 조직의 규칙에 부합하는지 판단할 때 정책 엔진이 더 충분한 근거를 바탕으로 결정을 내릴 수 있다.

고객은 분류 레이블을 포함해 자체 맥락 정보를 추가할 수 있다. 따라서 정책은 보안 업체의 일반적인 기밀 데이터 정의에만 의존하지 않고, 일반 파일과 기업이 매우 민감한 정보로 지정한 파일을 구분할 수 있다.

결정이 집행으로 이어지는 지점

이 아키텍처는 판단과 실행을 분리한다. Obsidian의 런타임 엔진 설명에 따르면 집행 지점은 제안된 작업을 일시 중지하고, 평가를 위해 세부 정보를 제출한 뒤, 반환된 결정과 사유를 적용한다.

새로운 정책 결정 API는 이 모델을 고객이 운영하는 게이트웨이, 에이전트 하니스, 워크플로까지 확장한다. 기업은 기존 인프라를 유지하면서 Obsidian에 맥락을 고려한 판단을 요청할 수 있다. 그런 다음 작업이 진행되기 전에 고객의 집행 구성 요소가 해당 판단을 적용해야 한다.

Obsidian은 작업을 차단하기 전에 실제 트래픽을 대상으로 정책이 일치하는지 시험할 수 있는 플래그 모드도 문서화했다. 결정 기록에는 에이전트, 요청한 사람, 도구, 인수, 결과, 일치한 정책이 포함되므로 보안팀은 작업이 허용되거나 중단된 이유를 조사할 수 있다.

승인 기능은 전반적인 허용 또는 차단 아키텍처보다 적용 범위가 좁다. 회사의 최신 문서에 따르면 작업 전에 실행되는 Claude Code 정책에서만 승인을 요구할 수 있다. 따라서 다양한 에이전트가 혼재된 환경을 위한 제어 기능을 설계할 때는 통합 수준에서 지원되는 기능을 고려하는 것이 중요하다.

MCP 프록시로 애플리케이션 토큰이 AI 클라이언트에 노출되지 않도록 보호

MCP 보안 프록시는 AI 클라이언트와 지원되는 비즈니스 애플리케이션 간의 연결을 관리합니다. 모델 컨텍스트 프로토콜(Model Context Protocol, MCP)은 에이전트가 외부 서버에 공개된 도구를 호출하는 표준 방식을 제공합니다. Obsidian은 클라이언트와 애플리케이션의 MCP 서버 사이에서 정책을 확인합니다.

제품 문서에 따르면, 공급업체의 직접 MCP URL을 Obsidian이 관리하는 엔드포인트로 대체합니다. 사용자는 애플리케이션 공급업체의 동의 절차를 거쳐 액세스를 승인하며, AI 클라이언트는 애플리케이션 액세스 토큰을 직접 저장하는 대신 프록시가 발급한 토큰을 받습니다.

프록시는 세션을 사용자, 해당 사용자의 애플리케이션 계정, 그리고 특정 Salesforce 조직이나 작업 공간과 같은 관련 테넌트에 연결합니다. 도구 호출을 전달하기 전에 확인하고, 허용 또는 차단 여부를 기록합니다. Obsidian은 공유 서비스 계정으로 권한을 추가하는 것이 아니라 사용자가 기존에 보유한 애플리케이션 권한 범위 안에서 작동한다고 설명합니다.

발표에서는 Cloudflare 및 해당 MCP Server Portal과의 협력도 언급합니다. 트래픽 경로상 게이트웨이가 차지하는 위치와 Obsidian이 제공하는 ID, 애플리케이션 및 데이터 맥락을 결합하는 것이 목표입니다.

작업 단위 제어가 중요한 이유

에이전트를 배포하는 기업이 실제로 해결해야 할 과제는 유용한 작업은 허용하면서 중대한 실수는 방지하는 것입니다. 일괄 금지는 워크플로 전체를 중단시킬 수 있지만, 범위를 좁혀 판단하면 일상적인 읽기 작업은 계속 허용하면서 무단 내보내기를 차단하거나 파괴적인 변경에 대한 검토를 요구할 수 있습니다.

Obsidian은 지원되는 도구와 집행 지점 전반에 걸쳐 이러한 판단을 공통 정책 계층으로 통합하고 있습니다. 그 효과는 기반이 되는 액세스 맥락의 품질과 통제 대상 경로를 얼마나 빠짐없이 포괄하는지에 달려 있습니다. 에이전트가 더 많은 운영 책임을 맡게 될수록, 실행 전에 판단의 근거를 설명하고 이를 집행하는 기능은 기업 보안에서 점점 더 중요해집니다.