본문으로 건너뛰기

Omnigent 컨텍스트 정책으로 치명적 삼중 위험 차단

세 단계가 한 세션에서 결합될 때 발생하는 데이터 유출을 세션 상태로 탐지해 마지막 단계에서 차단하는 Omnigent 접근법

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

Databricks 블로그 글은 Omnigent의 컨텍스트 정책으로 에이전트 세션에서 '개인 데이터 접근', '비신뢰 입력', '외부 전송' 세 가지가 결합될 때 발생하는 데이터 유출을 세션 상태로 탐지해 마지막 아웃바운드 호출만 차단하는 방법을 설명합니다. 정책은 각 축을 도구 호출이나 호출 인수 기준으로 켜고 세션 전체에 상태를 유지하므로 단일 동작은 정상적으로 허용됩니다. 축 정의는 사람이 에이전트 설정에서 고정하며 정책은 하위 에이전트와 인수 검사까지 확장되어 실제 작업의 오탐을 최소화합니다.

섹션별 상세

에이전트 보안에서 문제는 개별 권한 검사로는 포착할 수 없는 '세션 차원의 결합 위험'이 존재한다는 점입니다. 전통적 접근 방식은 특정 호출이 허용되는지만 확인하므로 내부 문서 조회나 외부에 이메일을 보내는 각 동작은 합법적으로 통과됩니다. 그러나 공격자가 지원 티켓 등 비신뢰 입력에 악성 지시를 넣으면 동일 세션에서 그 지시가 내부 데이터 접근과 외부 전송으로 이어져 기밀 정보가 유출될 수 있다는 위험이 발생합니다.
컨텍스트 정책은 세션 상태를 기억하는 방식으로 이 위험을 제어합니다. 정책은 세 가지 축을 세션 상태로 관리하는데, 내부 데이터 접근이 발생하면 private-data 축을 켜고 외부에서 온 입력을 수신하면 untrusted-content 축을 켭니다. 두 축이 이미 켜진 상태에서 외부 전송 도구 호출이 발생하면 정책이 해당 아웃바운드 호출을 거부하고 나머지 작업은 계속 허용하므로, 유출 경로만 정확히 차단하는 방식으로 동작합니다.
근거
  • 컨텍스트 정책은 private-data와 untrusted-content 축이 켜진 세션에서 outbound 호출을 거부해 데이터 유출을 차단한다. 본문 예시에서 에이전트가 티켓을 읽고 내부 문서를 조회한 뒤 send_email을 호출할 때 정책이 호출을 거부한 사례와 정책 동작 설명.
실사용 예로 지원 자동화 에이전트가 제시되었으며, 에이전트는 read_ticket, read_internal_doc, send_email 같은 도구를 갖고 있습니다. 공격자는 티켓 본문에 내부 문서를 조회하라는 정상 지시처럼 위장한 유출 절차를 넣고, 에이전트가 그 순서를 따르면 문서 내용이 외부 주소로 이메일 전송되어 유출이 발생합니다. Omnigent 정책을 적용하면 읽기 두 동작으로 두 축이 켜진 상태에서 send_email 호출이 들어올 때 정책이 호출을 거부하여 민감 수치가 외부로 나가지 않게 막습니다.
콘솔 출력 스크린샷으로 에이전트가 티켓을 읽고 내부 문서를 가져온 뒤 이메일 전송까지 완료해 유출이 발생한 사례를 보여줍니다.
Screenshot스크린샷은 per-action 권한만 있던 상황에서 각 호출이 정상으로 통과되어도 전체 시퀀스가 기밀 수치의 외부 전송으로 이어질 수 있음을 사례로 제시합니다. 실제 도구 호출 순서와 최종 결과가 화면에 드러나 정책 부재 시 위험 경로를 확인할 수 있습니다.
정책이 적용된 경우의 콘솔 출력을 담은 스크린샷으로, 아웃바운드 이메일 호출이 보안 정책에 의해 차단된 메시지를 포함합니다.
Screenshot이 화면은 정책이 어떻게 거부 사유를 표시하고 에이전트가 차단 결과를 사용자에게 보고하는지를 보여줍니다. 차단된 항목과 허용된 읽기 동작이 구분되어 있어 정책의 정밀 차단 능력을 확인할 수 있습니다.
정책 설계는 실제 작업에 대한 오탐을 피하도록 구성되어 있습니다. 축은 도구 호출이나 호출 인수로 '실제로 데이터가 접근되었는지' 기준으로만 켜지므로, 내부 조회가 결과를 반환하지 않거나 단순한 티켓 처리처럼 민감 데이터 접근이 없는 세션은 차단되지 않습니다. 또한 축 할당은 사람 운영자가 에이전트 설정에서 정의하며 에이전트 스스로 런타임에 재분류할 수 없도록 하여 프롬프트 인젝션으로 정책을 우회하는 것을 방지합니다.
루틴 티켓(비민감) 처리 사례의 스크린샷으로, 비신뢰 입력만 존재해 에이전트가 정상적으로 이메일을 전송하는 흐름을 보여줍니다.
Screenshot이 사례는 정책이 단지 조합된 위험만 차단하고 정상 단일 축 워크플로우는 방해하지 않는다는 근거를 제공합니다. 내부 검색이 결과를 반환하지 않거나 민감 데이터 접근이 없는 세션에서는 아웃바운드 호출이 허용되는 모습을 확인할 수 있습니다.
근거
  • 축 상태는 사람이 에이전트 설정에서 정의하며 정책은 호출 인수까지 검사해 축을 켤 수 있다. 본문의 '인간이 에이전트 구성에서 각 축을 정의한다'와 '정책은 호출의 인수를 검사할 수 있다' 문단.

이미지 분석

세 개의 원이 교차하는 다이어그램으로 private data, untrusted input, communicate externally 세 축이 겹칠 때 'lethal trifecta'가 형성되는 구조를 보여줍니다.
Diagram

다이어그램은 위험이 단일 도구가 아니라 세션에서 세 요소가 결합될 때 발생한다는 핵심 직관을 시각적으로 제시합니다. 정책이 두 축이 이미 켜진 상태에서 세 번째 축의 아웃바운드 호출을 차단한다는 흐름도 함께 제시되어 있어 정책 동작을 직관적으로 이해할 수 있습니다.

세 개의 원이 교차하는 다이어그램으로 private data, untrusted input, communicate externally 세 축이 겹칠 때 'lethal trifecta'가 형성되는 구조를 보여줍니다.

용어 해설

치명적 삼중구성(lethal trifecta)
세션에서 개인 데이터 접근, 외부로의 통신 능력, 그리고 공격자가 제어하는 입력이 동시에 존재할 때 데이터 유출 위험이 발생하는 개념으로, 각 요소는 개별적으로는 합법적이지만 결합되면 민감 데이터가 외부로 유출될 수 있습니다.
컨텍스트 정책(contextual policy)
에이전트의 세션 상태를 기억하면서 이전 행동과 결합된 위험 패턴을 탐지해 특정 호출만 차단하는 정책 엔진 규칙으로, 단일 동작 허용을 유지하면서 시퀀스 기반 위험을 차단하는 역할을 합니다.
개인 데이터 축(private data leg)
에이전트가 기밀 내부 문서나 민감 정보를 실제로 조회하여 세션 수준에서 '개인 데이터 접근'으로 표시되는 상태 플래그로, 해당 플래그가 켜져야 이후 결합 위험을 판단할 수 있습니다.
비신뢰 입력 축(untrusted content leg)
사용자 또는 외부 공격자가 통제할 수 있는 입력을 에이전트가 수신했을 때 세션에 설정되는 플래그로, 이 플래그는 프롬프트 인젝션에 의해 악용될 가능성이 있는 입력 유입을 식별합니다.
유출(출력) 축(exfiltration leg)
세션의 마지막 단계로 외부로 정보를 보내는 도구 호출(예: 이메일 전송)이 발생할 때 해당 호출이 데이터 유출로 이어질 수 있는지를 판단하는 트리거 역할을 하는 축입니다.

기술

  • Omnigent
  • read_internal_doc
  • read_ticket
  • send_email
  • 컨텍스트 정책 엔진

활용 사례

  • 고객 지원 티켓 자동화에서 민감 정보 유출 방지
  • 다중 에이전트 시스템에서 하위 에이전트가 전파하는 지시를 비신뢰로 처리해 유출 경로 차단
  • 권한이 합법적인 도구들을 결합해 발생하는 시퀀스 기반 위험 통제
AI 분석 전체 내용 보기

AI 요약 · 북마크 · 개인 피드 설정 — 무료

출처 · 인용 안내

원문 발행 2026. 08. 11.수집 2026. 08. 11.출처 타입 RSS

인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.