Databricks에서 AI 에이전트에 대한 프롬프트 주입 위험 완화

개요

2024년에 Databricks AI 보안 프레임워크(DASF) 를 출시한 이후 AI에 대한 위협 환경은 극적으로 변화했습니다. AI는 전형적인 챗봇에서 벗어나 거의 또는 전혀 개입 없이 사용자를 대신하여 추론하고, 도구를 사용하고, 행동을 취할 수 있는 에이전트로 변모했습니다. 보안팀은 이제 모델과 상호작용하는 사용자에 대해서만 생각할 필요가 없으며, 자율적으로 행동하고 MCP를 통해 서비스와 상호작용하며 스스로 인터넷을 탐색하는 수많은 지능형 에이전트에 대해서도 생각해야 합니다.

프롬프트 인젝션은 추론 시대에 이미 알려진 위험이었지만, 대체로 사용자의 요청과 응답 범위 내에 국한되었습니다. 자율적으로 행동할 수 있는 에이전트가 등장하면서 그 위험은 기하급수적으로 증가했습니다.

타사 API를 호출하는 스크립트를 작성하도록 AI 에이전트에게 작업을 지시하는 데이터 전문가를 생각해 보십시오. 에이전트는 인터넷에서 문서를 검색하고 코드를 작성한 후 실행합니다. 사용자가 깨닫지 못하는 것은 문서 페이지에 악성 프롬프트가 포함되어 있었고, 이 프롬프트가 에이전트에게 사용자의 compute 환경에서 웹훅으로 자격 증명을 유출하도록 지시했다는 점입니다. 이러한 공격은 실제로 잘 문서화되어 있습니다. 하지만 그것이 언제, 왜 성공하는지 추론하는 데 도움이 되는 프레임워크가 있습니다.

Meta의 '에이전트 2의 법칙'과 Simon Willison의 '치명적인 삼중주'와 같은 유사한 모델을 포함한 최근 산업 연구는 프롬프트 주입 공격이 성공하는 조건을 강조합니다. 이러한 패턴은 엔터프라이즈 데이터에서 작동하는 AI 에이전트를 보호하기 위한 실용적인 모델을 제공하는 Databricks AI 보안 프레임워크(DASF)에 정의된 통제 방식과 밀접하게 일치합니다.

둘 다 동일한 결론에 도달합니다. AI 에이전트는 다음 세 가지 특성을 모두 가질 때 프롬프트 주입에 취약해지며, 위험을 완화하려면 이 중 두 가지만 허용해야 합니다.

• 민감한 시스템 또는 개인 데이터에 대한 액세스
• 신뢰할 수 없는 입력에 대한 노출
• 상태를 변경하거나 외부와 통신하는 기능

실제로 이러한 위험은 데이터 액세스, 모델 상호 작용, 운영 실행 전반에 걸쳐 AI 보안을 구성하는 Databricks AI 보안 프레임워크(DASF)에 정의된 심층 방어 제어에 직접적으로 매핑됩니다. 아래 섹션에서는 Databricks 플랫폼의 네이티브 제어를 사용하여 이러한 위험을 완화할 수 있는 방법을 보여줍니다.

AI 에이전트의 핵심 위험 이해

개요에서 언급했듯이, Meta의 에이전트 2의 법칙 프레임워크는 AI 에이전트를 프롬프트 주입에 취약하게 만드는 핵심 요소를 분석하는 데 도움이 됩니다.

1. 민감한 시스템 또는 개인 데이터에 대한 액세스: 에이전트는 민감한 사용자 데이터를 읽거나 상호 작용할 수 있습니다.
2. 신뢰할 수 없는 입력 처리: 에이전트는 외부 또는 공격자가 제어하는 소스에서 제공하는 콘텐츠를 사용할 수 있습니다.
3. 상태 변경 또는 외부 통신: 에이전트는 로컬 환경 외부에서 HTTP 요청을 하거나 외부 시스템을 수정하는 등의 작업을 수행할 수 있습니다.

세 가지 핵심 요소가 모두 존재하면 시스템은 이미 민감한 시스템이나 개인 데이터에 액세스할 수 있으며(첫 번째), 공격자는 신뢰할 수 없는 입력을 통해 악의적인 지침을 주입하여(두 번째) 에이전트가 해당 데이터를 외부로 유출하도록 할 수 있습니다(세 번째). 이 섹션에서는 Databricks의 맥락에서 각각이 어떻게 적용되는지 살펴보겠습니다.

첫 번째 원칙: 민감한 시스템 또는 비공개 데이터에 대한 액세스

공격자가 가치 있는 것을 빼내려면 에이전트가 먼저 해당 항목에 액세스해야 합니다. 이것이 에이전트 2원칙의 첫 번째 기둥이며, 실제로는 거의 항상 필수입니다. 에이전트는 실제의 가치 높은 데이터에 대해 작동할 수 있을 때 가장 유용합니다. 이는 고객 피드백에 대한 감성 분석, 수요 예측, 사기 탐지 또는 코드 지원과 같은 작업에 점점 더 많이 사용됩니다. 효과를 발휘하기 위해 이러한 에이전트에게는 고객 기록, 거래 내역, 독점 문서 또는 대규모 내부 코드베이스에 대한 액세스 권한이 의도적으로 부여됩니다. 다시 말해, 조직에 경쟁 우위를 제공하는 바로 그 데이터가 공격자들이 가장 관심을 갖는 데이터이기도 합니다.

통합 데이터 및 인텔리전스 플랫폼인 Databricks는 조직의 가장 가치 있는 데이터 세트를 중앙 집중화하고 처리하도록 설계되었습니다. 플랫폼에서 실행되는 애플리케이션과 에이전트는 설계상 민감한 정보에 근접하여 작동합니다. 이는 많은 실제 배포 환경에서 에이전트 2의 법칙의 첫 번째 요소를 가상적인 우려로 취급하기보다는 존재하는 것으로 가정해야 함을 의미합니다.

제2원칙: 신뢰할 수 없는 입력 처리

에이전트 2의 원칙(Agents Rule of Two)의 두 번째 원칙은 신뢰할 수 없는 데이터가 시스템에 들어오는 방식에 중점을 둡니다. 가장 간단한 경우, 이 위험은 명백합니다. LLM 채팅 인터페이스는 악의적인 지침이 포함된 사용자 입력을 직접 받을 수 있습니다. 이것은 공격자가 상호 작용의 일부로 페이로드를 명시적으로 제공하는 직접적인 프롬프트 주입입니다.

그러나 위험은 직접적인 사용자 입력을 넘어 확장됩니다. 에이전트와 LLM 기반 애플리케이션은 데이터베이스, 문서, APIs 또는 지식 베이스와 같은 외부 소스에서 데이터를 검색하고 처리하는 경우가 많습니다. 이러한 경우, 악의적인 지침이 합법적인 콘텐츠 내에 포함되어 있다가 에이전트가 해당 데이터를 읽거나 추론할 때만 표면화될 수 있습니다. 이것이 간접적인 프롬프트 주입입니다. 최신 LLM이 자연어, 구조화된 데이터, 특수 문자, 이미지, 인코딩된 페이로드 등 다양한 입력을 해석하도록 설계되었다는 사실로 인해 문제는 더욱 복잡해집니다. 이러한 다양성으로 인해 기존의 입력 유효성 검사 기술을 사용하여 악의적인 지침을 탐지하기가 어렵습니다.

Databricks 플랫폼에서는 데이터 원본의 다양성으로 인해 이 점이 특히 중요합니다. 단일 Unity Catalog 테이블에는 주문 관리 시스템의 트랜잭션 기록, 직원과 고객 간의 지원 대화 또는 웹 양식을 통해 제출된 제품 피드백이 포함될 수 있습니다. 에이전트가 해당 데이터에 대한 액세스 권한을 부여받으면 간단하지만 중요한 질문을 해야 합니다. 이 데이터의 일부가 외부 행위자의 영향을 받았을 수 있는가?

대답이 '예'라면 에이전트 2원칙의 두 번째 기둥이 이미 마련된 것입니다.

실제로 이 평가는 간단한 경우가 거의 없습니다. 데이터를 원래 소스로 다시 추적하고 악의적인 지침이 포함될 수 있는 댓글, 자유 텍스트 필드, 메타데이터 또는 첨부 파일과 같이 눈에 잘 띄지 않는 삽입 지점을 고려해야 하는 경우가 많습니다. 일반적인 비즈니스 데이터처럼 보이는 것도 에이전트의 관점에서는 실행 가능한 지침이 될 수 있습니다.

기둥 3: 상태 변경 또는 외부 통신

에이전트 2원칙의 마지막 원칙은 에이전트가 실제로 수행하도록 허용된 작업과 그에 따라 공격의 영향 범위가 얼마나 커질 수 있는지에 중점을 둡니다. 초기 LLM 애플리케이션에서는 모델이 사실상 읽기 전용이었습니다. 사용자가 프롬프트를 제공하면 모델이 응답을 생성하고 해당 응답이 단순히 표시되었습니다. 모델에 비공개 런타임 데이터에 액세스하거나 작업을 실행하는 기능이 없었기 때문에 공격자가 모델의 출력에 영향을 미치더라도 그 영향은 일반적으로 사용자에게 표시되는 텍스트로 제한되었습니다.

최신 에이전트는 근본적으로 다릅니다. 더 이상 텍스트 생성에만 국한되지 않고, Python 코드 실행이나 SQL 쿼리 실행과 같은 작업을 통해 상태를 변경하고, API를 호출하거나 모델 컨텍스트 프로토콜(MCP)과 같은 메커니즘을 통해 시스템과 상호 작용하여 외부와 통신할 수 있습니다.

Databricks 플랫폼에서 AI 기능으로 구축된 에이전트는 MCP 서버, 사용자 정의 함수 또는 외부 API에 쉽게 연결할 수 있습니다. 설계 단계에서는 이러한 도구의 의도된 사용뿐만 아니라 잠재적인 오용도 고려하는 것이 중요합니다. 도구가 에이전트의 외부 통신을 허용하거나 테이블을 덮어쓰는 경우, Agents Rule of Two의 마지막 기둥이 활성화됩니다.

다른 핵심 요소와 마찬가지로 에이전트의 기능을 완전히 파악하는 것은 항상 간단하지 않습니다. 언뜻 보기에 무해해 보이는 도구도 예상치 못한 방식으로 사용될 수 있습니다. 따라서 개발자는 효과적인 역량, 즉 에이전트가 수행하도록 설계된 작업뿐만 아니라 적대적 영향 하에서 무엇을 할 수 있는지를 생각해야 합니다.

종합하기

세 가지 원칙 각각을 개별적으로 보면 관리 가능해 보일 수 있습니다. 에이전트가 민감한 데이터에 액세스할 수 없다면 프롬프트 주입은 덜 우려됩니다. 에이전트가 민감한 데이터에 대해 조치를 취할 능력이 없다면 해당 데이터에 대한 액세스는 덜 위험합니다. 그리고 에이전트가 신뢰할 수 있는 입력만 처리한다면 강력한 도구는 덜 위험합니다. 이러한 요소들이 한데 모일 때 위험은 커집니다. 이러한 조건 하에서 적은 에이전트의 의도된 용도를 넘어선 방식으로 에이전트의 행동에 영향을 미칠 수 있으며, 일상적인 상호 작용처럼 보이는 것을 실제 결과를 초래하는 보안 사고로 바꿀 수 있습니다.

방어적인 관점에서 볼 때, 이는 우리에게 실용적인 설계 원칙을 제시합니다. 바로 세 가지 기둥을 분리하는 것입니다. 대부분의 실제 AI 애플리케이션에서는 단일 요소를 완전히 제거하기가 어렵습니다. 에이전트가 유용해지려면 데이터가 필요하고, 다양한 입력을 처리해야 하며, 작업을 자동화하기 위한 도구가 필요한 경우가 많습니다. 그럼에도 불구하고 각 요소와 관련된 위험을 억제할 수 있는 구체적인 방법이 있습니다.

많은 AI 플랫폼에서 이러한 위험은 ID 시스템, 네트워크 제어, 모델 게이트웨이 및 데이터 거버넌스 솔루션에 걸친 임시방편적인 도구들을 통해 해결됩니다. Databricks는 다른 접근 방식을 취합니다. 데이터, AI 모델, 애플리케이션이 Unity Catalog와 Agent Bricks가 관리하는 통합 플랫폼에서 실행되기 때문에, 조직은 추가적인 보안 사일로를 도입하지 않고도 데이터 액세스부터 모델 상호 작용, 런타임 실행에 이르기까지 전체 AI 시스템에 계층화된 제어를 적용할 수 있습니다.

Databricks 플랫폼은 이러한 각 계층에서 제어 기능을 제공하며, 다음 섹션에서는 실제 사례인 새로운 AI 에이전트 Social Gauge를 사용하여 이를 살펴보겠습니다.

기둥별 AI 에이전트의 프롬프트 삽입 위험에 대한 제어

프롬프트 주입을 완화하는 가장 효과적인 방법은 세 가지 원칙 중 하나를 완전히 제거하는 것이며, 이는 여전히 유효합니다. 하지만 실제로 대부분의 에이전트는 민감한 데이터에 대한 액세스, 외부 입력에 대한 노출, 조치를 취할 수 있는 능력이라는 세 가지 모두가 어느 정도 필요합니다. 따라서 기둥을 제거하는 대신, 각각을 강화하여 공격 표면을 줄이는 것이 목표가 됩니다.

실행 예시인 Social Gauge를 사용하여 세 가지 기둥 모두에 걸쳐 9가지 제어를 살펴보겠습니다. Social Gauge는 소셜 미디어 및 뉴스 소스에서 데이터를 가져온 다음 해당 데이터를 Unity Catalog에서 관리하는 기존 고객 기록과 결합하는 Databricks 앱에 내장된 에이전트입니다. 제품 출시에 대한 정서를 추적하는 마케팅 팀, 분기별 보도를 통합하는 재무 팀 또는 유선 서비스를 모니터링하는 뉴스룸을 생각해 보세요. 이 연습에서는 Social Gauge를 사용하여 신제품에 대한 사용자 정서를 추적하는 소매 고객에 초점을 맞출 것입니다.

이러한 맥락에서 세 가지 기둥을 각각 살펴볼 때 다음 공격 시나리오를 염두에 두십시오.

1. Social Gauge는 의도된 사용에 필요한 범위를 넘어 민감한 금융 데이터에 액세스할 수 있습니다.
2. 악의적인 지침을 포함하는 프롬프트 삽입이 포함된 소셜 미디어 게시물이 수집됩니다.
3. 이 지침은 에이전트가 범위를 벗어난 재무 데이터를 검색하여 외부로 유출하거나 내부 스키마 내에서 수정하여 다운스트림 결정에 영향을 미치도록 지시합니다.

각 섹션에서 설명하는 제어 수단은 다양한 단계에서 이 공격 체인을 차단, 완화 또는 모니터링하도록 설계되었습니다.

원칙 1: 민감한 시스템 또는 비공개 데이터에 대한 액세스 - 제어

이 요소는 거의 피할 수 없습니다. 에이전트는 실제 데이터에서 작동하기 때문에 유용합니다. Social Gauge는 "1월에 제품 판매량이 감소한 이유가 있나요?"와 같은 질문에 답하기 위해 Unity Catalog를 통해 고객 기록을 쿼리해야 합니다. 고객 정서와 관련이 있나요?" 해당 액세스 권한이 없으면 에이전트는 실질적인 인사이트를 제공할 수 없습니다.

저희의 공격 시나리오에서 Pillar 1 위험은 Social Gauge가 본래 용도에 필요한 수준을 넘어선 금융 데이터에 액세스할 수 있다는 점으로, 이는 에이전트가 범위 밖의 데이터를 가져오도록 지시하는 간접 프롬프트 인젝션에 취약하게 만듭니다. 이 핵심 위험을 완전히 제거할 수는 없으므로, Social Gauge의 접근 범위를 요청을 보내는 사용자와 관련된 데이터로만 제한하여 이 위험을 억제하고자 합니다.

Databricks는 AI 에이전트가 Unity Catalog를 통해 관리되는 엔터프라이즈 데이터에서 직접 작동하기 때문에 이러한 위험을 완화하는 데 독보적인 위치에 있습니다. 이를 통해 조직은 인간 사용자와 AI 에이전트 모두에게 세분화된 액세스 제어, 정책 시행 및 데이터 보호 메커니즘을 일관되게 적용할 수 있습니다.

사용자 대신 인증:
AI 에이전트와 통합을 구축할 때 고객은 Databricks API에 대해 사용자 대신(OBO) 인증 을 사용하도록 선택할 수 있습니다. 이는 기본 SDK가 데이터에 액세스하기 위해 호출될 때 에이전트 자체에 연결된 서비스 주체가 아니라 에이전트와 상호 작용하는 최종 사용자의 권한을 사용함을 의미합니다.

이는 모든 AI 애플리케이션을 구축할 때 첫 번째 단계여야 합니다. 이는 본질적으로 권한을 제한하고 과도한 권한이 부여된 에이전트가 단일 침해 지점이 되는 것을 방지합니다.

Unity Catalog - 세분화된 액세스 제어 목록:
OBO 인증이 효과적이려면 고객은 Unity Catalog에 세분화된 액세스 제어 목록이 있어야 사용자와 작업 공간이 액세스해서는 안 되는 데이터에 액세스할 수 없도록 해야 합니다.

보호 가능한 개체에 대한 권한 은 대부분의 고객에게 익숙한 액세스 제어입니다. 이는 카탈로그, 스키마, 테이블, 볼륨 등 Unity Catalog 보안 개체에 대해 사용자가 수행할 수 있는 작업을 결정합니다. 많은 고객의 경우 거버넌스 전략의 일부로 이러한 설정이 이미 마련되어 있습니다. 권한 관리에 대한 자세한 내용은 Unity Catalog 모범 사례에 대한 설명서 를 참조하세요.

Unity Catalog - 속성 기반 액세스 제어(ABAC):
세분화된 액세스 제어는 사용자가 데이터 엔지니어, 애널리스트 또는 비즈니스 사용자와 같이 명확하게 정의된 그룹에 속할 때 잘 작동합니다. 하지만 여러 비즈니스 라인에서 근무하는 비즈니스 사용자나 다른 지역에 기반을 둔 사용자는 어떻습니까? 바로 이럴 때 ABAC 가 사용됩니다.

ABAC를 사용하면 정책을 한 번 정의하여 카탈로그, 스키마, 테이블 등에 걸쳐 적용할 수 있습니다. 정책 유형은 두 가지가 있습니다. 행 필터 정책은 사용자의 속성을 기반으로 테이블을 자동으로 필터링합니다. 예를 들어, 사용자가 EMEA에 기반을 둔 경우 테이블은 해당 지역의 레코드로만 축소됩니다. 열 마스크 정책은 사용자가 특정 그룹에 속하지 않는 한 민감한 열을 마스킹하여 PII 노출을 줄이는 간단한 방법을 제공합니다.

AI 가드레일 - PII 탐지:
위의 제어 기능은 누가 무엇에 액세스할 수 있는지를 제한하는 데 중점을 둡니다. 하지만 에이전트가 실제로 반환하는 내용을 모니터링하는 것도 마찬가지로 중요합니다. 많은 고객이 AI 액세스를 위한 중앙 거버넌스 레이어로 Mosaic AI 게이트웨이 를 사용합니다. AI 게이트웨이는 통합 모델 액세스, 라우팅, 사용량 추적, 속도 제한 외에도 PII 탐지와 같은 가드레일을 제공하여 모델의 입력 또는 출력에 민감한 데이터가 나타나는 모든 곳에서 이를 자동으로 차단하거나 수정합니다. 이는 에이전트가 조작되어 노출해서는 안 되는 데이터를 표시하는 시나리오로부터 보호합니다.

요약: 민감한 시스템 또는 개인 데이터에 대한 액세스 제어
이러한 제어를 통해 Social Gauge의 노출은 근본적으로 달라 보입니다. 에이전트가 프롬프트 삽입 공격에 의해 조작되더라도 요청하는 사용자가 이미 액세스할 수 있는 데이터에만 도달할 수 있으며, 해당 지역으로 범위가 지정되고 민감한 열이 관련된 경우 마스킹되며, 유출 시 PII가 모니터링됩니다. 에이전트를 손상시키는 공격자는 모든 권한을 상속하는 것이 아니라 문을 지키는 경비원과 함께 단일 사용자의 권한을 상속합니다.

원칙 2: 신뢰할 수 없는 입력 처리 - 제어

Databricks는 권한 없는 외부 사용자에 대한 노출을 완화하는 다양한 플랫폼 제어 기능을 제공합니다: MFA를 사용한 SSO, 컨텍스트 기반 인그레스 제어, 프런트 엔드 PrivateLink 또는 IP ACL. 하지만 신뢰할 수 없는 입력에 노출될 위험이 로그인 화면에서 끝나지는 않습니다.

Social Gauge의 핵심 기능은 소비재에 대한 소셜 미디어 게시물과 뉴스 기사를 인터넷에서 검색하는 것입니다. 해당 기능은 간접 프롬프트 주입, 즉 정상적인 웹 콘텐츠에 포함된 악의적인 명령어에 시스템을 노출시킵니다. 따라서 승인되지 않은 사용자가 Social Gauge의 인터페이스에 직접 액세스할 수는 없지만 간접 공격 표면은 여전히 유효합니다.

또한 내부자 위험도 있습니다. 즉, 사용자가 탈옥 기술을 사용하여 볼 수 없는 데이터에 액세스하거나, Social Gauge를 원래 목적이 아닌 용도로 변경하거나, 분석을 조작하는 경우입니다(예: "내 제품이 아주 훌륭하다고 말하는 출처를 만들어내!").

우리의 공격 시나리오에서 Pillar 2의 위험은 프롬프트 주입이 포함된 소셜 미디어 게시물이 수집되고, 내장된 악성 콘텐츠가 에이전트에 의해 정상적인 명령으로 해석되는 것입니다. 신뢰할 수 없는 입력에 대한 에이전트의 처리를 강화하는 제어를 통해 이 위험을 완화할 수 있습니다.

AI Guardrails: 콘텐츠 안전 및 프롬프트 삽입:

지금까지 살펴본 바와 같이 Mosaic AI Gateway에는 안전 필터링 및 PII 탐지와 같이 적용할 수 있는 몇 가지 기본 내장 가드레일이 있습니다. 이러한 가드레일은 에이전트의 입력 또는 출력(또는 둘 다)에 적용할 수 있습니다. 이러한 기본 내장 가드레일 외에도 Mosaic AI Model Serving에 사용자 지정 모델 을 배포하여 활용할 수도 있습니다. 예를 들어 최신 Llama Protection 모델은 프롬프트 주입, 유해 콘텐츠 또는 코드 인터프리터 남용을 탐지하도록 미세 조정된 특수 LLM입니다. 이러한 모델은 에이전트 주위에서 방어 계층 역할을 하여 상호 작용이 인시던트로 번지기 전에 검사할 수 있습니다.

이러한 가드레일이 얼마나 효과적일 수 있는지 알아보기 위해 저희는 작은 실험을 진행했습니다. 저희는 자동화된 LLM 보안 테스트를 위해 Databricks와 쉽게 통합 되는 NVIDIA 개발 오픈 소스 도구인 Garak 취약점 스캐너에서 수백 개의 악성 프롬프트를 수집했습니다. 이 데이터 세트에서 저희는 세 가지 일반적인 공격 범주를 선택했습니다.

1. 프롬프트 주입: 웹사이트, 번역 작업 또는 이메일과 같은 컨텍스트에 숨겨진 악의적인 지시로, 모델을 조작하여 의도치 않은 행동을 하도록 설계되었습니다.
2. 탈옥(Jailbreaks): 정렬 안전장치를 우회하고 유해하거나 제한된 출력을 유도하기 위해 신중하게 만들어진 프롬프트입니다.
3. 다운스트림 주입 공격: 다른 시스템에서 해석될 때만 위험해지는 콘텐츠를 모델이 생성하도록 유도하는 프롬프트입니다. 예를 들어 애플리케이션에 의해 실행되는 악의적인 SQL 문이나 HTML로 렌더링될 때 민감한 데이터를 유출하는 조작된 마크다운 이미지 태그 등이 있습니다.

그런 다음 이러한 공격의 성공률을 기준 모델(이 경우 Llama-4-Maverick 배포)과 비교하여 측정했습니다. 결과는 명확했습니다. 가드레일이 없으면 상당수의 악의적인 프롬프트가 표적 행동을 성공적으로 트리거했습니다. 맞춤형 가드레일 모델(프롬프트 주입 및 탈옥용 Prompt Guard 2, 다운스트림 주입용 llama guard 3-8b)을 모델 앞에 배치했을 때 세 가지 범주 모두에서 성공률이 90% 이상 감소했습니다.

추가적인 가드레일 기술, 오픈 소스 접근 방식 또는 최신 PII 탐지 모델에 대해 자세히 알아보려면 Databricks 담당자에게 문의하여 맞춤형 가드레일 배포에 대해 알아보세요.

프롬프트 레지스트리:
잘 만들어진 시스템 프롬프트는 전용 탐지 모델만큼 강력하지는 않지만, 때로는 공격의 성공 여부를 가를 수 있으므로 올바르게 설정할 가치가 있습니다. MLflow 프롬프트 레지스트리 는 임시방편으로 프롬프트를 조합하는 대신 조직 전체에서 프롬프트의 버전을 관리하고, 추적하고, 테스트하고, 재사용할 수 있도록 하여 GenAI 애플리케이션의 프롬프트 엔지니어링 및 관리를 간소화합니다.

요약: 신뢰할 수 없는 입력 처리를 위한 제어
Social Gauge는 여전히 공개 인터넷에서 읽어오는데, 이것이 핵심 요구사항입니다. 하지만 공격자가 악용할 수 있는 공격 표면이 상당히 좁아졌습니다. 웹 콘텐츠에 포함된 악의적인 프롬프트는 이제 에이전트에 도달하기 전에 미세 조정된 탐지 모델을 통과해야 하며, 시스템 프롬프트는 즉석에서 되는대로 조합되는 것이 아니라 버전 관리 및 테스트를 거칩니다. 이러한 제어 기능 중 어느 것도 단독으로는 완벽하지 않지만, 함께 사용하면 완전히 개방된 공격 표면을 공격자가 악용하기 훨씬 더 어렵게 만듭니다.

세 번째 원칙: 상태 변경 또는 외부 통신 - 제어

공격 시나리오의 마지막 단계에서 세 번째 원칙의 위험은 프롬프트 주입이 처리되면 에이전트가 외부로 데이터를 유출하거나 내부 스키마 내에서 데이터를 수정하여 다운스트림 의사 결정에 영향을 미치는 등 악의적인 지침을 수행할 수 있는 능력을 갖게 된다는 것입니다.

Social Gauge는 제품 성능을 조사하는 사용자를 위해 기존 데이터를 타사 데이터로 보강하므로, 본질적으로 카탈로그, 스키마, 테이블 및 기타 개체에 써야 합니다. 기본 상태가 변경되고 있습니다. 세 가지 제어, 즉 아웃바운드 네트워크 액세스 제한, 외부 스토리지에 대한 액세스 제한, Unity Catalog 내 상태 변경 제한에 중점을 둘 것입니다.

서버리스 이그레스 제어 - 인터넷 위치:
프롬프트 주입이 에이전트에 의해 처리되더라도 Databricks 네트워크 정책을 통해 서버리스 이그레스 제어 를 적용하면 결과적인 폭발 반경을 상당히 줄일 수 있습니다. 이를 통해 관리자는 서버리스 워크로드(Databricks Apps 포함)의 아웃바운드 연결에 대해 기본적으로 거부 태세를 정의한 다음, 에이전트에 실제로 필요한 신뢰할 수 있는 대상만 명시적으로 허용할 수 있습니다.

Social Gauge와 같은 에이전트를 실행하는 작업 공간에 제한된 네트워크 정책을 연결하면 에이전트가 임의의 인터넷 엔드포인트에 도달하는 기능이 제한되어 간접적인 프롬프트 주입 공격 표면이 줄어들고 알 수 없는 대상으로 데이터가 유출될 위험이 감소합니다.

Serverless Egress Controls - Unity Catalog 개체:
FQDN 필터링을 통해 알려진 Endpoint에 대한 액세스를 제한하는 것 외에도, 서버리스 이그레스 제어의 두 번째 기능은 S3 버킷과 같은 클라우드 스토리지 위치에 대한 액세스를 제한하는 기능입니다. 워크스페이스, 시스템 테이블 및 샘플 데이터세트와 연결된 버킷은 기본적으로 읽기 전용으로 유지되지만, 이 제어는 한 걸음 더 나아가 AI 에이전트가 승인되지 않은 버킷에 쓰는 것을 방지하여 가장 일반적인 데이터 유출 경로 중 하나를 차단합니다.

Unity Catalog - 워크스페이스 바인딩:
워크스페이스-카탈로그 바인딩 을 사용하면 고객이 특정 워크스페이스에서 카탈로그에 대한 액세스를 제한할 수 있습니다. 이는 개발자가 여러 환경에서 데이터에 액세스할 수 있지만 해당 데이터가 개발 경계를 넘어서는 안 될 때 중요합니다. 데이터 엔지니어는 프로덕션 데이터를 읽을 권한이 있을 수 있지만 개발 작업 공간에서는 그렇게 할 수 없습니다.

Social Gauge는 OBO 자격 증명으로 작동하므로, 워크스페이스 바인딩은 에이전트가 개발 환경에서 작동하는 동안 실수로 프로덕션 상태를 변경할 가능성을 완화합니다.

요약: 상태 변경 또는 외부 통신 제어
serverless 이그레스 제어로 아웃바운드 연결에 default 거부(deny-by-default) 상태를 적용하고 외부 스토리지를 잠그며, 워크스페이스 바인딩으로 환경 경계를 적용하여 가장 명백한 데이터 유출 및 상태 조작 경로를 차단했습니다. 이제 이러한 방어망을 통과하는 것을 어떻게 잡아낼 수 있는지 알아보겠습니다.

보안 위험에 대한 AI 에이전트 모니터링

위에서 언급했듯이 고객은 Mosaic AI Gateway 를 사용하여 기업 전체의 모든 AI 모델과 에이전트에 대한 액세스를 관리하고 통제할 수 있으며, 이러한 통합은 관찰 가능성과 모니터링에도 적용됩니다. AI Gateway를 사용하면 추론 테이블을 통해 조직 전체의 AI 모델 및 에이전트에 대한 모든 입력과 출력을 중앙에서 Logs할 수 있으며, 이 데이터를 사용하여 AI 요청을 모니터링 및 감사하고 모델 성능과 보안을 향상시킬 수 있습니다.

유추 테이블

아래 query를 사용하여 추론 테이블 을 모니터링하여 기본 내장된 Trigger 가 작동했는지 확인할 수 있습니다. 이 query는 어떤 가드레일(입력 또는 출력)이 Trigger되었는지, 그리고 어떤 유해한 카테고리가 감지되었는지를 추출합니다. 물론 보안에 있어서는 사후 대응보다 사전 예방이 항상 더 낫습니다. 따라서 query를 검증한 후에는 조사가 필요한 상황이 발생할 때 귀하 또는 보안 운영 센터(SOC)에 자동으로 알리도록 알림으로 구성하는 추가 단계를 진행하는 것이 좋습니다.

시스템 테이블
추론 테이블 외에도 Databricks 시스템 테이블 에는 Databricks에서 발생하는 중요한 이벤트에 대한 풍부한 인사이트가 포함되어 있습니다. 저희는 과거 블로그 에서 이를 활용하여 잠재적인 보안 위협과 침해 지표(IoC)를 사전에 모니터링하고 경고하는 방법에 대해 설명했으며, 이는 AI 에이전트의 핵심 보안 위험으로 확장될 수 있습니다. 예를 들어 아래 쿼리는 서버리스 이그레스 제어를 모니터링하고 누군가(또는 일부 에이전트)가 외부와 통신하기 위해 이를 우회하려고 하는지 여부를 확인하는 데 사용할 수 있습니다.

심판으로서의 AI
심판으로서의 AI 를 사용하는 것은 에이전트 및 인공 지능 분야 전반에서 보편적입니다. 사실, 대부분의 가드레일 모델은 기본적으로 특정 목적을 수행하기 위해 특정 시스템 프롬프트에 의해 미세 조정되거나 안내되는 LLM입니다. 위에서 언급했듯이 Mosaic AI Model Serving에 사용자 지정 모델 을 쉽게 배포할 수 있으며, Databricks에 Llama Guard 4 및 Llama Prompt Guard 2 와 같은 최신의 가장 우수한 가드레일 모델 대부분을 배포하는 예시가 있습니다. 사용자 지정 가드레일로 배포하는 것 외에도 Databricks의 개방형 플러그형 아키텍처가 제공하는 이점 중 하나는 MLflow의 일반 mlflow.pyfunc flavor를 사용하여 모델을 로깅한 후 다양한 방식으로 활용할 수 있다는 것입니다. 예를 들어 배치 Spark 워크플로 또는 Spark 선언적 파이프라인으로 배포하거나, SQL에서 ai_query로 호출하거나, Spark Structured Streaming을 사용하여 거의 실시간 또는 마이크로 배치 시나리오에 적용할 수 있습니다.

경우에 따라 모든 요청 또는 응답에 가드레일을 적용하는 것이 불가능할 수도 있습니다. 이는 가드레일이 에이전트가 작동하는 비즈니스 목표나 주제 도메인을 방해할 수 있는, 전적으로 타당한 시나리오입니다. 가드레일이 적용되지 않더라도 추론 테이블과 배치 또는 스트리밍 파이프라인을 사용하여 잠재적으로 유해한 콘텐츠를 분류함으로써 에이전트의 안전성을 계속 모니터링할 수 있습니다.

추가 리소스

이 게시물의 제어는 결승점이 아니라 출발점입니다. 프롬프트 삽입 위험은 에이전트의 기능이 향상됨에 따라 진화하며, 목표는 이에 맞춰 반복 가능한 보안 프로그램을 만드는 것입니다. 이는 일회성 강화 작업이 아닙니다!

이러한 에이전트 보안 패턴은 Databricks AI 보안 프레임워크의 다음 진화를 형성하고 있습니다. 예정된 DASF 업데이트는 프레임워크를 확장하여 자율 AI 에이전트, 도구 사용, 새롭게 부상하는 프롬프트 주입 위험을 해결하고, 조직이 모델뿐 아니라 전체 AI 시스템을 보호하도록 지원합니다.

세 가지 단계에 맞춰 가장 관련성이 높은 리소스를 정리했습니다.

정의:

• Databricks AI 보안 프레임워크(DASF) 2.0은 MITRE ATLAS, NIST, OWASP, HITRUST와 같은 표준에 매핑되는 AI 시스템의 12가지 핵심 구성 요소에 대한 포괄적인 위험 분석을 제공합니다. 프롬프트 삽입, 탈옥, 데이터 유출과 같은 위험을 줄이기 위한 67가지의 실용적인 제어를 제공합니다. 이 블로그에서 논의된 DASF 제어:
  • DASF 5: 데이터 및 기타 객체에 대한 액세스 제어
  • DASF 64: AI 모델 및 에이전트의 액세스 제한
  • DASF 57: 속성 기반 액세스 제어(ABAC) 사용
  • DASF 58: 필터 및 마스킹으로 데이터 보호
  • DASF 54: AI 가드레일 구현
  • DASF 62: 네트워크 세분화 구현
  • DASF 37: 모델 모니터링 및 디버깅을 위한 추론 테이블 설정
  • DASF 49: LLM 평가 자동화
  • DASF 73: 프롬프트 등록
  • DASF 55: 감사 로그 모니터링
• Databricks AI 거버넌스 프레임워크(DAGF) 는 조직이 설계 및 개발부터 배포 및 모니터링에 이르기까지 전체 수명 주기에 걸쳐 AI 시스템을 관리하는 방법을 정의합니다.
• Databricks 보안 모범 사례 가이드 (AWS, Azure 및 GCP용)는 보안 의식이 가장 높은 고객과 협력하여 확인한 성공 사례를 기반으로 일반 환경 및 고도로 안전한 환경에 권장하는 주요 보안 제어에 대한 상세한 개요를 제공합니다.

배포

• Databricks Security Reference Architecture - Terraform Templates(SRA)를 사용하면 보안 모범 사례로 구성된 Databricks 작업 공간과 클라우드 인프라를 배포할 수 있습니다.

모니터링

• 보안 분석 도구(SAT) 는 보안 및 플랫폼 팀이 Databricks 작업 공간의 보안 상태를 신속하게 평가하는 데 도움이 됩니다.
• Databricks Detection Tool 은 작업 공간의 활동을 모니터링하는 데 도움이 되도록 사용하기 쉬운 노트북으로 통합된 일련의 독자적인 탐지 기능입니다.

이러한 리소스를 통합함으로써 팀은 단일 에이전트에 대한 일회성 강화에서 벗어나, 혁신과 진화하는 위협 환경에 보조를 맞출 수 있는 반복적이고 확장 가능한 Databricks AI 보안 프로그램으로 나아갈 수 있는 실용적인 방법을 갖게 됩니다.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)