Databricks의 '결합 전까지 무죄' 정책, 결합 지점에서 에이전트 위험 차단

Databricks는 각각으로는 평범한 세 가지 기능이 위험한 연결고리를 형성할 때에만 에이전트를 차단하는 새로운 Omnigent 보안 패턴을 공개했다. Databricks의 '결합 전까지 무죄' 접근법은 하나의 세션 안에서 비공개 데이터, 신뢰할 수 없는 콘텐츠, 외부 통신이 모두 가능해지는 순간을 겨냥한다.

이 조합은 치명적 삼요소(lethal trifecta)로 알려져 있다. 에이전트는 내부 파일을 읽거나, 공개 웹페이지를 살펴보거나, 메시지를 전송하는 작업을 각각 따로 수행할 때는 안전할 수 있다. 그러나 세 기능이 하나의 실행 경로에 들어가면, 주입된 지시가 정당한 접근 권한을 데이터 탈취로 바꿀 수 있다.

중요한 변화는 프롬프트 인젝션에 대한 또 하나의 경고가 아니다. Databricks는 집행 결정을 모델 밖으로 옮겨, 에이전트를 실행하고 관리하기 위한 오픈소스 메타 하니스인 Omnigent에 맡기고 있다. 정책 계층은 세션이 마주한 상황을 기억한 뒤 이후 작업을 다르게 처리한다.

정적 권한은 에이전트가 도구를 호출할 수 있는지를 묻는다. 컨텍스트 정책은 그 호출 전에 어떤 일이 있었는지도 묻는다. 이 차이는 코딩 에이전트, 브라우저 에이전트, Model Context Protocol 통합을 통해 광범위하고 지속적인 도구 접근 권한을 사용하는 팀에 부담으로 작용한다.

Databricks가 Omnigent에서 바꾼 것

Databricks는 에이전트의 이력을 실질적인 권한 집합의 일부로 취급하고 있다.

회사의 보안 사례 연구는 Omnigent의 컨텍스트 정책에 관한 연재를 확장한다. 앞선 사례들은 세션 상태, 장기 누적형 공격, 사용자 본래 의도에 연계된 권한 부여에 초점을 맞췄다.

최신 사례는 이 모델을 치명적 삼요소에 적용한다. 보안 연구자 Simon Willison은 2025년 6월 이를 비공개 데이터 접근, 신뢰할 수 없는 콘텐츠 노출, 외부 통신 채널의 조합으로 정의했다. 그의 위협 모델은 세 가지가 결합되면 주입된 지시가 정보를 훔쳐갈 경로를 얻는다고 경고한다.

Omnigent는 모델, 도구, 실행 루프를 관리하는 런타임인 에이전트 하니스 위에 위치한다. 이 프로젝트는 널리 쓰이는 코딩 에이전트 환경과 커스텀 에이전트를 지원하며, 공통 정책 계층이 이들의 활동을 관찰할 수 있게 한다.

이 위치가 중요한 이유는 정책이 기반 모델이 모든 악성 문구를 식별할 필요가 없기 때문이다. 세션 동안 기록된 사실을 토대로 도구 사용을 관리할 수 있다.

내부 제품 문서를 검토하도록 요청받은 에이전트를 생각해 보자. 해당 문서를 읽는 것은 예상되는 작업이다. 승인된 요약을 회사 채널로 보내는 것 역시 예상되는 작업일 수 있다.

하지만 에이전트가 숨겨진 지시를 담은 공개 이슈, 웹페이지 또는 리포지터리를 방문했다고 가정해 보자. 세션이 또 하나의 신뢰 경계를 넘었기 때문에 이후의 외부 요청은 다른 보안 의미를 갖게 된다.

기존 허용 목록은 워크플로 전반에서 동일한 승인 도구를 본다. 컨텍스트 정책은 시간이 지나며 위험이 변한 순서를 본다.

Omnigent 정책은 허용, 확인 또는 거부 결정을 반환할 수 있다. 허용은 작업을 진행시키고, 확인은 사람에게 넘기며, 거부는 작업을 차단한다. 따라서 세션에 민감한 접근이나 위험한 이벤트가 누적될수록 응답은 더 엄격해질 수 있다.

이 집행 모델은 모든 소스, 도구 또는 작업이 그 자체로 위험할 것을 요구하지 않는다. 대신 정책은 안전하지 않은 데이터 경로를 만드는 조합을 감시한다.

Databricks는 워크스페이스 ID 및 모델 서비스에 연결된 관리형 베타 형태로도 Omnigent를 제공하고 있다. 현재 관리형 배포는 내장 컨텍스트 정책 핸들러를 지원하지만, 임의의 커스텀 정책 함수는 여기서 아직 사용할 수 없다.

이 제약은 오픈소스 설계와 관리형 제품을 구분한다. 발표를 평가하는 팀은 시연된 정책 패턴과 선택한 배포 방식에서 실제로 사용할 수 있는 제어 기능을 구별해야 한다.

그럼에도 핵심 변화는 분명하다. 에이전트 권한 부여는 로그인 시점이나 도구 등록 시점에 고정되는 방식에서 세션 의존적인 방식으로 바뀌고 있다.

Databricks의 '결합 전까지 무죄'가 보안 경계를 바꾸는 이유

위험한 대상은 더 이상 하나의 도구 호출이 아니라, 여러 허용된 호출을 연결하는 경로다.

전통적인 접근 제어는 ID, 리소스, 작업을 평가한다. 서비스 계정은 하나의 데이터베이스를 읽고, 하나의 버킷에 쓰며, 하나의 API를 호출할 수 있다. 에이전트 역시 일반적인 자격 증명으로 작동하므로 이러한 규칙은 여전히 필요하다.

하지만 신뢰할 수 없는 언어가 그러한 자격 증명의 사용 방식에 영향을 미칠 때는 충분하지 않다. 공격자는 토큰을 훔치거나 애플리케이션 코드를 악용할 필요가 없을 수 있다. 데이터에 접근하고 외부 작업을 수행할 수 있는 모델에 악성 콘텐츠만 도달시키면 된다.

첫 번째 요소는 비공개 데이터다. 여기에는 내부 문서, 소스 코드, 자격 증명, 고객 기록, 이메일, 데이터베이스 결과, 그리고 공격자 권한 범위 밖의 모든 정보가 포함된다.

두 번째 요소는 신뢰할 수 없는 콘텐츠다. 웹페이지, 지원 티켓, 풀 리퀘스트, 이메일, 공유 파일, 도구 응답 또는 이미지는 에이전트의 신뢰 경계 밖에 있는 사람이 제어하는 지시를 담을 수 있다.

세 번째 요소는 외부 통신이다. 이메일과 HTTP 요청은 명확한 사례지만, 범주는 더 넓다. 댓글 게시, 코드 푸시, 원격 리소스 로드, 공유 시스템에 쓰기 등도 외부 통로를 만들 수 있다.

이 기능들 중 어느 것도 이례적이지 않다. 바로 그 유용성 때문에 이 조합은 수많은 에이전트 설계에 등장한다.

리서치 에이전트에는 외부 소스와 내부 컨텍스트가 필요하다. 코딩 에이전트는 비공개 리포지터리를 읽고, 공개 문서를 참고하며, 브랜치를 푸시할 수 있다. 이메일 보조 도구는 신뢰할 수 없는 메시지를 읽고, 비공개 서신을 검색하며, 답장을 보낸다.

어떤 기능이든 영구적으로 제거하면 에이전트의 유용성이 크게 떨어질 수 있다. 상시 승인 프롬프트는 사용자가 일상적인 요청을 수락하는 데 익숙해질 수 있다는 또 다른 문제를 만든다.

Databricks의 '결합 전까지 무죄' 프레이밍은 다른 선택지를 제시한다. 저위험 작업은 진행시키되, 세션 상태가 금지된 조합을 완성할 때는 단계를 높이는 방식이다.

이는 보안 경계를 개별 커넥터에서 워크플로로 옮긴다. 브라우저는 단순히 신뢰되거나 신뢰되지 않는 것이 아니다. 같은 세션이 민감한 정보와 외부 전송 경로도 보유하고 있는지에 따라 그 의미가 달라진다.

이 모델은 시스템이 신뢰 수준 간 데이터 이동을 추적하는 정보 흐름 제어와 닮아 있다. 기밀 정보가 하나의 컨텍스트에 들어오면, 이후 보호 수준이 낮은 대상에 쓰는 작업은 더 엄격한 처리를 받는다.

Omnigent가 공개한 정책 카탈로그에는 이미 관련된 Google Drive 제어 기능이 있다. 세션이 선언된 기밀 파일을 읽으면, 이 정책은 기밀 집합 밖으로의 쓰기를 막을 수 있다.

이 카탈로그에는 위험 점수 정책도 포함돼 있다. 도구 호출과 민감 데이터 레이블에 점수를 누적한 뒤, 구성된 임계값을 넘으면 보호 대상 도구의 단계를 높인다.

이 사례들은 왜 상태가 핵심인지 보여준다. 에이전트가 민감한 문서를 읽은 뒤에도 쓰기 요청의 API 형태는 바뀌지 않는다. 세션 이력 때문에 그 의미가 바뀌는 것이다.

같은 원리가 치명적 삼요소에도 적용된다. 정책은 보편적으로 금지된 작업이 아니라 위험한 조합을 찾는다.

이 구분은 또 하나의 프롬프트 필터보다 플랫폼 팀의 관심을 끌어야 한다. 필터는 텍스트가 악성처럼 보이는지 판단하려 한다. 컨텍스트 기반 집행은 모델이나 필터가 인젝션을 식별하지 못해도 안전하지 않은 작업을 차단할 수 있다.

정적 권한은 순서를 놓친다

정적 허용 목록은 이용 가능한 기능을 설명할 수 있지만, 에이전트가 어떻게 특정 작업에 이르렀는지는 설명할 수 없다.

개발자가 에이전트에 비공개 리포지터리 읽기, 문서 탐색, 풀 리퀘스트 열기 권한을 부여했다고 가정해 보자. 각 권한은 일반적인 코딩 워크플로를 뒷받침한다.

그런 다음 공격자가 이슈, 종속성 문서 또는 가져온 웹페이지 안에 지시를 넣는다. 그 지시는 에이전트에게 비밀을 수집해 공개 풀 리퀘스트 설명에 포함하라고 지시한다.

리포지터리 읽기는 허용된다. 웹 검색도 허용된다. 풀 리퀘스트 열기도 허용된다. 각각의 요청을 독립적으로 평가하는 제어 장치는 전체 연결고리를 승인할 수 있다.

콘텐츠 필터는 그 지시를 탐지할 수도 있다. 하지만 간접 요청, 인코딩된 데이터, 낯선 언어 또는 대상 모델에 맞춰 설계된 페이로드는 놓칠 수도 있다.

연구 결과는 모델 행동에만 의존하는 데 신중해야 함을 뒷받침한다. WASP 벤치마크는 여러 모델과 스캐폴드를 활용해 웹 에이전트 시스템을 상대로 현실적인 프롬프트 인젝션 공격을 시험했다.

연구진은 시험된 구성 전반에서 에이전트가 적대적 지시를 실행하기 시작한 비율이 16%에서 86% 사이였다고 밝혔다. 공격자의 엔드투엔드 성공률은 더 낮아 0%에서 17% 범위였다.

그 격차는 고무적이지만 안심할 만한 것은 아니다. 현재 에이전트는 복잡한 공격을 끝마치기 전에 실패하는 경우가 많지만, 에이전트 신뢰성이 개선되면 악성 워크플로 역시 더 쉽게 완성될 수 있다.

시스템은 에이전트가 적절한 순간에 혼란을 겪을 것이라고 기대해서는 안 된다. 모델이 다단계 실행을 더 잘하게 되더라도 효과를 유지하는 제어 기능이 필요하다.

정적 권한은 지연된 공격에도 취약하다. 주입된 지시는 즉각적인 외부 작업을 유발하지 않을 수 있다. 이후의 계획, 위임된 작업, 생성된 파일 또는 도구 호출에 영향을 미칠 수 있다.

세션 인식 정책은 그러한 지연 동안 보안 관련 사실을 유지할 수 있다. 모든 의심스러운 이벤트가 모델의 활성 컨텍스트에서 최종 작업 바로 옆에 있을 필요는 없다.

이러한 지속성은 장시간 실행되는 에이전트의 실질적인 약점을 해결한다. 대화 이력은 압축되거나 요약되거나 여러 워커로 분할될 수 있다. 도구와 자격 증명은 계속 사용 가능하더라도 모델은 이전 제약을 잊을 수 있다.

따라서 정책 상태는 텍스트 창 밖에 존재해야 한다. 집행 계층에는 민감한 읽기, 신뢰할 수 없는 입력, 대상지, 승인, 위험 변화에 대한 자체적인 지속형 기록이 필요하다.

이 아키텍처는 에이전트의 자기 보고에 대한 의존도도 낮춘다. 모델에 신뢰할 수 없는 콘텐츠를 만났는지 묻는 것은 어떤 커넥터가 콘텐츠를 제공했는지 기록하는 것보다 약하다.

가장 강력한 신호는 인프라에서 나온다. 문서 시스템은 파일의 분류를 알고 있다. 네트워크 게이트웨이는 대상지를 안다. ID 계층은 사용자와 워크스페이스를 안다. 도구 브로커는 어떤 작업이 요청됐는지 안다.

Omnigent는 실행 환경을 감싸기 때문에 이러한 신호를 결합할 수 있다. 에이전트가 작업을 제안하지만, 기록된 컨텍스트 아래에서 해당 작업이 여전히 허용 가능한지는 정책이 결정한다.

이것이 경쟁 에이전트 플랫폼의 압박 지점이다. 도구 수준 승인은 설명하고 구현하기가 더 쉽다. 그러나 에이전트가 더 많은 커넥터를 아우르며 더 긴 세션을 실행할수록 신뢰성은 떨어진다.

벤더는 자신의 제어 기능이 도구를 가로지르는 데이터와 신뢰 전환을 추적하는지 보여줘야 한다. 긴 권한 목록만으로는 더 이상 핵심 보안 질문에 답할 수 없다.

컨텍스트 정책은 데이터가 나가기 전에 연결고리를 끊는다

유용한 제어 지점은 공격 경로를 완성하는 전환이며, 대개 민감한 읽기 또는 외부 작업이다.

맥락 기반 정책은 관찰 가능한 이벤트에서 시작됩니다. 여기에는 도구 호출, 도구 결과, 데이터 라벨, 대상 위치, 모델 요청 또는 사용자 승인 등이 포함될 수 있습니다.

정책은 선택된 사실을 세션 상태에 저장합니다. 예를 들어 에이전트가 신뢰할 수 없는 콘텐츠를 소비했는지, 기밀 객체에 접근했는지, 승인된 경계 밖으로 통신을 시도했는지를 기록할 수 있습니다.

이후 이벤트는 해당 상태를 기준으로 평가됩니다. 다음 작업이 금지된 조합을 완성하는 경우, 정책은 승인을 요구하거나 요청을 거부할 수 있습니다.

순서는 달라질 수 있습니다. 에이전트는 신뢰할 수 없는 페이지를 방문하기 전에 비공개 데이터를 읽을 수 있습니다. 또는 주입된 콘텐츠를 먼저 접한 뒤 내부 파일에 대한 접근을 요청할 수도 있습니다.

견고한 구현은 두 경로를 모두 감지해야 합니다. 위험은 하나의 고정된 순서가 아니라, 기능들이 서로 연결되는 데서 발생합니다.

집행은 여러 지점에서 이뤄질 수도 있습니다. 신뢰할 수 없는 콘텐츠가 세션에 들어온 뒤 민감한 읽기 작업을 차단하는 정책이 있을 수 있습니다. 또 다른 설계는 분석은 허용하되 이후의 외부 통신을 막을 수 있습니다.

외부 반출을 차단하면 더 많은 로컬 활용성을 보존하는 경우가 많습니다. 에이전트는 정보를 노출할 경로를 얻지 못한 채 계속 읽고 초안을 작성할 수 있습니다. 그러나 외부 반출 통제는 명백한 전송 기능만 포괄해서는 안 됩니다.

생성된 링크에는 데이터가 인코딩될 수 있습니다. 원격 이미지 요청은 쿼리 매개변수를 전송할 수 있습니다. 소스 제어 푸시, 이슈 댓글, 분석 호출 또는 공유 문서 쓰기는 모두 신뢰 경계를 넘을 수 있습니다.

대상 맥락도 중요합니다. 요약을 승인된 내부 채널로 보내는 것과 공개 리포지토리에 게시하는 것은 다릅니다. 모든 쓰기 작업을 똑같이 취급하면 불필요한 중단이 발생합니다.

맥락과 대상이 명확할 때 사람의 승인은 가치가 있습니다. 유용한 프롬프트는 세션이 기밀 데이터를 읽었고, 이후 신뢰할 수 없는 콘텐츠를 소비했으며, 이제 특정 외부 엔드포인트에 접속하려 한다는 점을 설명해야 합니다.

일반적인 “이 도구를 허용하시겠습니까” 메시지는 권한 상승의 이유를 숨깁니다. 검토자가 워크플로를 수동으로 재구성해야 하므로 승인 피로를 부추깁니다.

조직이 절대 수용하지 않는 조합에는 강제 거부가 적합합니다. 예를 들어 정책은 공개 콘텐츠에 노출된 세션이 제한된 데이터 세트의 정보를 격리 구역 밖으로 전송하는 것을 막을 수 있습니다.

필수 맥락이 누락된 경우 정책 엔진은 안전하게 실패해야 합니다. 누락된 데이터 라벨, 지원되지 않는 도구 또는 관찰되지 않은 네트워크 경로는 사각지대를 만들 수 있습니다.

Omnigent의 더 폭넓은 접근 방식은 정책과 샌드박싱을 결합합니다. 샌드박스는 운영체제 경계에서 파일 시스템 및 네트워크 접근을 제한해, 모델이 요청하더라도 에이전트가 도달할 수 있는 범위를 줄입니다.

이 계층들은 서로 다른 목적을 수행합니다. 샌드박스는 원시 기능을 제한합니다. 맥락 기반 정책은 세션에 누적된 상태에 따라 권한을 조정합니다.

어느 쪽도 일반적인 신원 통제, 커넥터 권한 부여, 로깅 또는 데이터 유출 방지를 대체하지는 않습니다. 이 발표는 해당 스택 안의 한 집행 계층으로 해석할 때 가장 유용합니다.

OWASP의 agentic security report는 프롬프트 인젝션을 AI 시스템을 겨냥한 주요 공격 기법으로 지목합니다. 더 큰 메시지는 에이전트 보안에 실행, 도구, 신원 및 데이터 이동을 둘러싼 통제가 필요하다는 것입니다.

이는 Databricks의 아키텍처 방향을 뒷받침합니다. 확률적 모델은 작업을 제안할 수 있지만, 결정론적 경계가 그 작업의 허용 여부를 판단해야 합니다.

Databricks 정책이 해결하지 못하는 사항

맥락 기반 집행은 공격 경로를 좁히지만, 그 신뢰성은 완전한 가시성과 신뢰할 수 있는 분류에 달려 있습니다.

첫 번째 미해결 과제는 적용 범위입니다. 정책은 관찰하지 못하는 채널을 차단할 수 없습니다.

에이전트는 커넥터, 셸 명령, 브라우저 요청, 임베디드 리소스 또는 생성된 아티팩트를 통해 통신할 수 있습니다. 경계 밖으로 데이터를 이동시킬 수 있는 모든 경로는 정책 모델에 표현되거나 다른 방식으로 제한돼야 합니다.

두 번째 과제는 분류입니다. 시스템은 어떤 콘텐츠가 신뢰할 수 없는지, 어떤 데이터가 민감한지를 알아야 합니다.

단순한 규칙으로는 공개 웹페이지를 신뢰할 수 없는 것으로, 이름이 지정된 문서를 기밀로 분류할 수 있습니다. 하지만 엔터프라이즈 환경에는 공유 드라이브, 계약업체 계정, 복사된 텍스트, 생성 파일, 여러 저민감도 소스에서 조합된 데이터 등 더 어려운 사례가 존재합니다.

거짓 음성은 위험한 조합을 감지하지 못하게 합니다. 거짓 양성은 일상 업무를 중단시키고, 사용자가 경고를 검토하지 않은 채 승인하도록 학습시킬 수 있습니다.

세 번째 과제는 상태 범위입니다. 세션은 편리한 단위이지만, 정보는 파일, 메모리 저장소, 캐시, 서브에이전트 및 복사된 요약을 통해 세션 간에 이동할 수 있습니다.

한 작업자가 기밀 데이터를 읽고 다른 작업자가 그 결과를 전송한다면, 세션별 추적은 결합된 흐름을 놓칠 수 있습니다. 멀티에이전트 시스템에는 위임 전반에서 관련 라벨을 보존하는 전파 규칙이 필요합니다.

네 번째 과제는 정책 무결성입니다. 집행 계층, 구성 및 이벤트 스트림은 보안상 핵심 인프라가 됩니다. 공격자는 정책 공백, 잘못된 형식의 도구 메타데이터, 모호한 대상 또는 실패 시 허용되는 동작을 노릴 수 있습니다.

팀은 모델뿐 아니라 실제 정책 경계를 테스트해야 합니다. 적대적 평가는 대체 외부 반출 경로, 지연된 작업, 에이전트 간 전송 및 불완전한 메타데이터를 포함해야 합니다.

다섯 번째 과제는 사용성입니다. 너무 자주 승인을 요청하는 통제는 해결하려던 약점을 되풀이할 수 있습니다.

위험 기반 권한 상승에는 신중하게 선택된 임계값과 유용한 프롬프트가 필요합니다. 보안 팀은 승인 빈도, 거부 정확도, 재정의 비율 및 사용자가 예외를 수용하는 이유를 측정해야 합니다.

관리형 Omnigent 베타에는 또 다른 실무적 제약이 있습니다. Databricks는 현재 관리형 환경에서 임의의 사용자 지정 정책 코드가 아닌 내장 핸들러 지원을 문서화하고 있습니다.

특수한 분류 체계나 독점 커넥터를 사용하는 조직은 이용 가능한 정책이 충분한 맥락을 노출하는지 확인해야 합니다. 오픈 소스의 유연성이 관리형 서비스의 동등한 기능으로 자동 전환되지는 않습니다.

또한 하나의 시연을 보편적 검증으로 간주할 근거는 아직 없습니다. Databricks의 글은 보안 패턴과 구현 접근 방식을 설명합니다. 모든 Omnigent 구성이 모든 프롬프트 인젝션 기법을 차단한다는 점을 입증하지는 않습니다.

정확한 주장은 더 좁습니다. 세션 인식 집행은 개별 도구가 각각 정당하게 남아 있더라도 치명적 트리펙타 경로를 끊을 수 있습니다.

그것만으로도 의미가 있습니다. 보안 아키텍처는 애플리케이션이 모든 공격자 메시지를 인식하도록 가르치는 것이 아니라, 공격에 필요한 조건 하나를 제거함으로써 성공하는 경우가 많습니다.

가장 강력한 배포 환경은 맥락 기반 정책을 제한된 자격 증명, 대상 허용 목록, 샌드박싱, 감사 로그 및 독립적인 테스트와 결합할 것입니다. 또한 정책 정의를 버전 관리되는 보안 코드로 다룰 것입니다.

이 모델의 유효성을 보여줄 세 가지 신호

다음 시험대는 맥락 기반 정책이 설득력 있는 시연이 아니라 측정 가능한 인프라가 되는지 여부입니다.

첫 번째 신호는 도구와 에이전트 하니스 전반에서의 더 폭넓은 적용 범위입니다. Databricks는 브라우저, 코드 리포지토리, 문서 시스템, 셸 및 위임된 에이전트를 포함하는 일반적인 워크플로에서 보안 라벨과 세션 상태가 유지된다는 점을 보여줘야 합니다.

기능 목록에 지원 항목이 있다는 것만으로는 충분하지 않습니다. 팀에는 서로 다른 하니스와 커넥터 구현 전반에서 동등한 작업이 동등한 집행을 받는다는 증거가 필요합니다.

일관된 적용 범위는 공유 메타 하니스에 대한 근거를 강화할 것입니다. 런타임 간에 실질적인 차이가 있다면 에이전트 전반에 하나의 거버넌스 계층을 제공하겠다는 약속은 약화됩니다.

두 번째 신호는 적대적 평가입니다. Omnigent에는 지연된 유출, 간접 외부 반출, 세션 간 전송 및 메타데이터 조작을 시도하는 반복 가능한 테스트가 필요합니다.

유용한 결과는 탐지, 승인, 거부 및 성공적인 데이터 이동을 구분해 제시해야 합니다. 또한 모든 워크플로를 차단하는 정책은 안전하지만 사용할 수 없으므로, 정상 작업의 완료 여부도 보고해야 합니다.

공개 테스트 픽스처는 보안 팀이 자체 구성에 대해 결과를 재현할 수 있게 합니다. 독립적인 평가는 공급업체가 선택한 시나리오보다 더 큰 설득력을 가질 것입니다.

세 번째 신호는 관리형 Databricks 환경 내 운영 도입입니다. 확대된 정책 지원, 더 명확한 텔레메트리, 관리 제어 기능 및 엔터프라이즈 데이터 분류와의 문서화된 통합을 주시해야 합니다.

도입은 측정 가능한 결과를 만들어야 합니다. 팀은 정책이 얼마나 자주 트리거되는지, 어떤 기능 조합이 권한 상승을 유발하는지, 검토자가 결정을 번복하거나 승인하는지를 알아야 합니다.

이 신호들이 중요한 이유는 에이전트의 유용성이 커질수록 근본적인 보안 문제가 커질 것이기 때문입니다. 더 나은 에이전트는 지속적인 감독 없이 더 긴 작업을 완료하고, 더 많은 도구를 사용하며, 더 많은 신뢰 경계를 넘게 될 것입니다.

Databricks의 ‘결합되기 전까지는 무해’ 접근 방식은 신뢰할 수 있는 설계 원칙을 제시합니다. 유용한 구성 요소는 허용하면서 위험한 결합은 차단하는 것입니다. 이는 모델이 공격을 이해하는지에서 주변 시스템이 공격의 완료를 허용하는지로 관심을 옮깁니다.

개발자는 어떤 세션이 비공개 데이터에 접근하고, 공격자 통제 콘텐츠를 수집하며, 외부와 통신할 수 있는지 매핑해야 합니다. 엔터프라이즈 구매자는 플랫폼이 시간, 도구 및 위임된 작업자 전반에서 이러한 조건을 추적하는지 물어봐야 합니다.

이 세 가지가 모두 맥락 기반 집행 없이 이용 가능한 상태라면, 세련된 승인 화면은 문제를 해결하지 못합니다. 실질적인 다음 단계는 각 워크플로에서 세 번째 기능이 어디에 들어오는지 파악한 뒤, 그 경계에 테스트 가능한 정책을 배치하는 것입니다.