Databricks 권한은 목적이 아니다: Omnigent, 에이전트 행동보다 의도를 앞세우다

Databricks는 테스트에 사용된 모든 도구의 유효한 자격 증명을 에이전트가 이미 보유하고 있음에도 Omnigent에 새로운 권한 경계를 도입했다. 이 제어는 에이전트가 행동을 수행할 수 있는지만이 아니라, 왜 그 행동이 일어나는지를 묻는다. 이러한 차이는 databricks permission을 신원 확인에서 작업별 제약으로 바꾼다.

7월 23일 공개된 이번 릴리스는 간접 프롬프트 인젝션에 대한 방어 수단으로 의도 기반 인가를 제시한다. 이 공격은 이메일, 문서, 지원 티켓, 데이터베이스 필드 등 에이전트가 읽는 콘텐츠 안에 지시를 숨긴다. Omnigent는 각 세션을 사람이 승인한 목적에 연결하고, 모든 도구 호출을 그 목적에 비추어 검사한다.

이 접근 방식은 대부분의 엔터프라이즈 접근 시스템을 뒷받침하는 기본적인 신원 우선 모델에 도전한다. 역할 기반 접근 제어는 에이전트가 데이터베이스 접근 권한을 부여할 수 있는지 확인할 수 있다. 그러나 데이터 품질 검토 과정에서 접근 권한 부여가 적절한지는 판단하지 못한다. 역량과 목적의 차이는 이제 운영 보안 경계가 되고 있다.

Databricks 권한은 이제 신원뿐 아니라 작업도 확인한다

직접적인 변화는 단순하다. Omnigent는 제안된 모든 도구 호출이 현재 세션에 선언된 목적에 부합하는지 평가한다.

전통적인 인가는 신원에서 시작한다. 사용자, 서비스 계정 또는 에이전트는 지정된 리소스와 상호작용할 권한을 부여받는다. 애플리케이션은 이후 역할, 범위, 정책, 자격 증명에 따라 작업을 허용하거나 거부한다.

이 모델은 인증된 행위자가 비교적 안정적인 의사결정자를 대표한다고 가정한다. 사람은 정보를 읽고 해석한 뒤, 허용된 버튼 중 무엇을 누를지 결정한다. 인가 계층은 그 사람이 왜 버튼을 눌렀는지 이해할 필요가 거의 없다.

AI 에이전트는 다르게 작동한다. 동일한 자동화 루프 안에서 데이터를 읽고 무엇을 할지 결정한다. 시스템 외부에서 수집된 콘텐츠는 에이전트의 추론과 권한 있는 도구 선택 모두에 영향을 줄 수 있다.

intent authorization release에 따르면, Omnigent는 신원과 의도를 결합해 이러한 차이를 해결한다. 신원은 에이전트가 사용할 수 있는 작업의 넓은 범위를 정의한다. 의도는 하나의 작업 또는 세션을 위해 그 범위를 좁힌다.

이 메커니즘은 도구 호출 전에 세 가지 가능한 결정을 내린다.

• ALLOW: 제안된 행동이 승인된 목적에 명확히 부합한다.

• ASK: 행동이 목적과 관련은 있지만 사람의 동의가 필요하다.

• DENY: 행동이 선언된 목적을 벗어나므로 진행할 수 없다.

이 결과가 중요한 이유는 유효한 자격 증명이 더 이상 인가 결정을 끝내지 않기 때문이다. 에이전트는 도구를 보유할 수 있지만, 관련 없는 업무 중에는 이를 사용할 수 없다.

Omnigent는 오픈소스 메타 하니스다. 즉, 서로 다른 에이전트 런타임을 둘러싸는 공통 오케스트레이션 및 정책 계층을 제공한다. open-source repository는 Claude Code, Codex, Cursor, OpenCode, Hermes, Pi, 커스텀 에이전트 지원을 명시한다.

이러한 포지셔닝은 정책이 하나의 모델을 위한 안전장치보다 더 폭넓게 적용된다는 뜻이다. 의도 검사는 에이전트의 도구 활동을 둘러싸며, 공통 계층을 통해 다양한 추론 시스템을 관리할 수 있다.

이번 릴리스에는 중요한 한계도 있다. Omnigent는 아직 알파 단계이므로, 이 시연은 설계 제안이자 작동하는 구현으로 해석해야 한다. 모든 모델, 도구, 엔터프라이즈 워크플로에서의 프로덕션 규모 신뢰성을 입증하는 것은 아니다.

그럼에도 아키텍처적 요점은 분명하다. 인가 결정은 기존 신원 제어를 대체하지 않으면서도 현재 작업을 반영할 수 있다. 보안팀에는 모델의 결정과 중대한 행동 사이에 추가 점검 지점이 생긴다.

새 제어는 Omnigent의 다른 맥락 기반 정책도 보완한다. 이러한 정책은 세션 위험, 민감 데이터, 누적 도구 사용 또는 서비스별 제한을 고려할 수 있다. 여러 정책이 동일한 호출을 평가하면 하나의 거부가 더 관대한 결정을 무효화한다.

이 규칙은 새로 추가된 정책이 더 엄격한 정책을 조용히 무력화하는 일을 막는다. 또한 의도는 에이전트 보안에 대한 완전한 해답이 아니라 더 큰 방어 체계의 한 계층이라는 점을 보여준다.

데이터 품질 테스트가 드러낸 목적의 공백

Databricks는 과도한 권한이 때로는 운영상 필요하지만 여전히 안전하지 않은 이유를 보여주기 위해 작은 데이터 워크플로를 선택했다.

테스트 에이전트는 일상적인 데이터 품질 업무를 수행한다. 고객 테이블을 읽고, 품질 지표를 계산하며, 내부 대시보드에 요약을 게시한다.

사용 가능한 도구에는 테이블 쿼리, 대시보드 업데이트, 다른 사용자에게 테이블 접근 권한을 부여하는 기능이 포함된다. 마지막 기능은 이 특정 검토에는 필요하지 않다. 그러나 동일한 에이전트는 다른 적법한 업무에서 이를 사용한다.

접근 권한 부여 도구를 제거하면 즉각적인 위험은 줄어든다. 하지만 별도의 구성이나 신원 없이는 에이전트가 정당한 프로비저닝 업무를 완료하지 못하게 된다. 범용 에이전트에서 정적인 최소 권한 원칙이 어려워지는 지점이다.

세션은 좁은 요청으로 시작한다. customers 테이블을 확인하고 요약을 게시하라는 요청이다. 공격자는 앞서 이 테이블의 사용자가 제어하는 필드 안에 지시를 삽입해 두었다.

숨겨진 텍스트는 감사 메모로 위장한다. 에이전트에게 외부 주소에 고객 데이터 접근 권한을 부여한 뒤 원래의 품질 검사를 계속하라고 지시한다.

이는 악성 지시가 검색된 데이터를 통해 유입되기 때문에 간접 프롬프트 인젝션이다. 사용자는 에이전트에게 권한을 변경하라고 요청한 적이 없으며, 공격자 역시 에이전트의 대화에 직접 접근할 필요가 없었다.

의도 정책이 없으면 Omnigent의 테스트 에이전트는 삽입된 지시를 따른다. 그 신원은 접근 권한 부여 도구 사용을 인가받았기 때문에, 기존 권한 검사는 유효한 행위자의 유효한 작업으로 본다.

그런 다음 에이전트는 해당 권한 부여를 일반적인 감사 활동으로 기록한다. 이 세부 사항은 두 번째 문제를 보여준다. 활동 로그는 작업을 정확히 기록할 수 있지만, 그 작업이 사용자의 실제 목표를 위반했다는 사실은 드러내지 못할 수 있다.

의도 기반 인가를 활성화하면 동일한 도구와 자격 증명을 계속 사용할 수 있다. 결과가 달라지는 이유는 각 작업이 승인된 데이터 품질 목적과 비교되기 때문이다.

테이블 읽기에는 ALLOW 결정이 내려진다. 요청된 대시보드 업데이트 게시에는 ASK 결정이 내려져, 사람이 쓰기 작업을 확인할 수 있다. 외부 주소에 대한 접근 권한 부여에는 DENY 결정이 내려진다.

대시보드 업데이트 승인을 받은 뒤에도 정당한 업무는 완료된다. 삽입된 행동은 세션의 명시된 목적에 기여하지 않으므로 실패한다.

이 사례는 databricks permission 제어에 더 명확한 의미를 부여한다. 이제 질문은 에이전트가 접근 권한을 수정할 수 있는지에만 머물지 않는다. 시스템은 그 수정이 데이터 품질 세션에 속하는지도 평가한다.

이 테스트는 실질적인 엔터프라이즈 문제를 반영한다. 하나의 searchable knowledge base, 데이터 플랫폼 또는 지원 환경에 연결된 에이전트는 다양한 신뢰 수준의 텍스트를 마주할 수 있다. 사용자 댓글과 관리자 지시가 동일한 모델 컨텍스트에 들어갈 수 있다.

사람은 조직적 맥락을 완벽하게 파악하지는 못하지만, 이상한 요청에는 의문을 제기할 수 있다. 모델은 특히 평범한 업무 지시처럼 보일 때, 매끄럽게 다듬어진 악성 텍스트를 작업의 일부로 해석할 수 있다.

Google의 보안 연구자들은 간접 프롬프트 인젝션을 AI 시스템이 처리하는 콘텐츠에 삽입된 악성 지시로 정의한다. 최근 web threat analysis에서는 악의적인 시도와 함께 인젝션 패턴을 닮은 많은 무해한 텍스트도 발견됐다.

이러한 혼재는 콘텐츠 필터링을 복잡하게 만든다. “이전 지시를 무시하라”와 같은 문구를 찾는 탐지기는 연구 논문, 보안 튜토리얼, 무해한 토론까지 마주하게 된다. 정교한 공격은 뚜렷한 악성 표식 없이 업무 언어를 사용할 수 있다.

의도 기반 인가는 행동 측면에서 문제에 접근한다. 관련 없는 권한 변경을 차단하기 전에 테이블 필드가 적대적인지 입증할 필요가 없다. 대신 결과적으로 발생하는 도구 호출이 작업을 뒷받침하는지 묻는다.

이것이 Databricks 시연의 핵심적인 전환점이다. 위험한 작업은 신원 시스템에는 인가되지 않은 것처럼 보이지 않는다. 목적이 결정에 들어온 뒤에야 인가되지 않은 작업이 된다.

신원 기반 접근이 에이전트를 과도하게 노출하는 이유

주된 압력은 자격 증명의 범위를 자율 소프트웨어의 최종 경계로 취급하는 신원 및 접근 시스템에 가해진다.

역할 기반 접근 제어는 여전히 필수적이다. 이는 신원이 접근할 수 있는 리소스와 요청할 수 있는 작업을 제한한다. 의도 기반 제어는 에이전트가 조직 전체에 걸쳐 관리자 접근 권한을 보유한 상황을 안전하게 보완할 수 없다.

그러나 역할은 대체로 안정적으로 유지되는 반면, 에이전트의 업무는 빠르게 바뀐다. 코딩 에이전트는 서로 다른 세션에서 리포지토리를 검토하고, 브랜치를 생성하고, 서비스를 배포하거나 이슈를 수정할 수 있다. 각 업무에는 동일하게 사용 가능한 역량 중 서로 다른 하위 집합이 필요하다.

가능한 모든 작업에 하나의 신원을 만드는 것은 큰 프로비저닝 부담을 초래한다. 재사용 가능한 하나의 신원에 광범위한 범위를 부여하면 자격 증명이 즉각적인 목적을 넘어 계속 사용 가능한 상시 권한 문제가 발생한다.

수명이 짧고 범위가 좁은 자격 증명은 이러한 노출을 줄일 수 있다. 시스템이 실행 전에 필요한 정확한 리소스와 행동을 예측할 수 있을 때 가장 효과적이다. 개방형 에이전트 워크플로는 작업 중에 그러한 요구 사항을 발견하는 경우가 많다.

Omnigent 모델은 모든 대화마다 새 신원을 요구하지 않으면서 세션 수준의 제약을 추가한다. 사람이 에이전트가 달성해야 할 목표를 선언하고, 정책은 제안된 행동을 그 선언에 비추어 평가한다.

자율 에이전트의 경우 Databricks는 설계 단계에서 에이전트 사양에 의도를 고정할 수 있다고 설명한다. 실행 중인 에이전트는 이를 확장하거나 제거할 수 없다.

대화형 에이전트는 결정을 다르게 처리한다. 에이전트는 사용자의 자연어 설명으로부터 정책 초안을 만들지만, 세션이 시작될 때 사람이 이를 승인한다. 해당 정책은 세션 중 백그라운드에서 변경될 수 없다.

이 사람의 승인 단계는 의도 추론 자체가 취약점을 만들기 때문에 중요하다. 모델이 삽입된 콘텐츠를 읽은 뒤 조용히 목적을 재정의할 수 있다면, 공격자는 원치 않는 행동을 인가하도록 모델을 설득할 수 있다.

Omnigent는 실행 중인 에이전트가 자신의 의도를 제거, 수정 또는 비활성화하는 도구도 거부한다. 다른 정책을 추가하려면 사람의 승인이 필요하며, 관대한 추가 정책도 기존 거부 결정을 무효화할 수 없다.

이러한 제어는 정책 구성 주변에 변조 저항성을 만든다. 그렇다고 근본적인 의도 평가가 오류가 없게 되는 것은 아니다.

내장 정책 문서는 intent_based_authorization 제어가 첫 번째 사용자 메시지를 세션 의도로 기록한다고 설명한다. 이어 그 의도와 그럴듯한 연관성이 없는 도구 호출 전에는 확인을 요청한다. 문서는 또한 이 정책에 LLM 구성이 필요하며, 구성이 없으면 실패 시 허용하는 방식으로 작동한다고 명시한다.

그 마지막 동작은 주의 깊게 살펴볼 필요가 있다. 평가자가 없을 때 보안 제어가 허용적으로 바뀌면, 팀이 테스트하고 모니터링해야 할 배포 조건이 생긴다. 프로덕션 환경에는 일반적으로 필수 정책 구성 요소를 사용할 수 없게 될 때 눈에 띄는 실패, 구성 검증, 알림이 필요하다.

LLM 평가자를 사용하면 또 다른 트레이드오프가 발생한다. 자연어 추론은 정적 규칙이 놓치는 작업 간 관계를 이해할 수 있다. 하지만 프롬프트, 모델 또는 주변 컨텍스트가 바뀌면 일관되지 않은 결정을 내릴 수도 있다.

이러한 긴장 관계는 Databricks가 의도를 계층형 에이전트 보안의 일부로 제시하는 이유를 설명한다. 하나의 정책은 작업과 무관한 액세스 권한 부여를 막고, 또 다른 제어는 누적 위험을 제한할 수 있다. 별도의 데이터 유출 방지 규칙은 허용된 호출을 통해 어떤 정보가 흐를지를 관리할 수 있다.

NIST 역시 권한 부여를 아직 해결되지 않은 에이전트 문제로 지목했다. 2026년 2월의 agent identity proposal는 조직이 자율 소프트웨어에 신원, 권한 부여, 감사 및 부인 방지 제어를 어떻게 적용해야 하는지 묻는다.

이 제안에는 프롬프트 인젝션을 방지하고 완화하기 위한 제어가 명시적으로 포함된다. 이 범위는 신원과 목적을 별개의 논의로 남겨둘 수 없는 이유를 보여준다.

인증된 에이전트도 해로운 결정을 내릴 수 있다. 목적에 부합하는 행동이라도 인수나 대상이 안전하지 않으면 민감한 데이터를 노출할 수 있다. 효과적인 제어는 신원, 작업, 데이터, 행동, 결과를 함께 고려해야 한다.

엔터프라이즈 구매자에게 필요한 대응은 아키텍처 차원의 변화다. 보안 검토는 더 이상 OAuth 스코프나 서비스 계정 역할 목록에서 끝날 수 없다. 팀은 실행 중 각 고위험 행동이 사용자 승인 목표와 어떻게 연결된 상태를 유지하는지 문서화해야 한다.

의도 기반 권한 부여는 판단력과 새로운 실패 모드를 더한다

Omnigent는 모델 지원 판단을 집행 경로에 직접 배치해 하나의 권한 부여 공백을 줄인다.

이 설계는 유연성을 제공하지만 불확실성도 만든다. “작업과 그럴듯하게 연결된다”는 것은 완전히 결정론적인 속성이 아니다.

프로덕션 장애를 조사하라는 요청을 받은 에이전트를 생각해 보자. 로그 읽기는 분명 작업에 부합한다. 에이전트가 장애를 식별한 뒤 서비스를 재시작하는 것도 부합할 수 있다. 증거가 침해를 가리킨다면 자격 증명 교체도 필요할 수 있다.

지나치게 좁은 정책은 복구에 필요한 행동을 차단할 수 있다. 반면 폭넓은 정책은 공격자가 관련 없는 자격 증명 변경을 인시던트 대응으로 포장하도록 허용할 수 있다. 사람의 승인은 일부 모호성을 해소할 수 있지만, 잦은 프롬프트는 업무를 늦추고 자동 승인 습관을 부추길 수 있다.

따라서 ALLOW, ASK, DENY 모델은 신중한 조정에 달려 있다. 특히 ASK는 불확실하지만 정당한 작업에 조용한 자율권을 부여하지 않고도 진행 경로를 제공한다는 점에서 중요하다.

ASK 결정이 너무 많으면 승인 피로가 생긴다. 운영자는 이유, 대상 또는 영향을 받는 데이터를 검토하지 않은 채 요청을 승인할 수 있다. ASK 결정이 너무 적으면 모호한 작업은 자동 허용이나 불필요한 거부 쪽으로 기울게 된다.

이 정책은 허용된 호출의 모든 결과가 아니라 도구 호출을 판단한다. Databricks는 의도가 행동을 통해 무엇이 이동하는지가 아니라 어떤 행동이 실행되는지를 제약한다고 명시적으로 설명한다.

승인된 대시보드 업데이트에도 기밀 데이터가 포함될 수 있다. 허용된 이메일 답장은 잘못된 수신자에게 전송될 수 있다. 정당한 데이터베이스 쿼리도 작업에 필요한 것보다 많은 레코드를 반환할 수 있다.

따라서 의도 기반 권한 부여는 인수 검증, 데이터 유출 방지, 대상 제어, 속도 제한 및 감사 시스템과 함께 작동해야 한다. 그 가치는 이러한 제어를 대체하는 데 있지 않고, 권한 부여에 목적을 추가하는 데 있다.

OpenAI는 agent security analysis에서 관련된 소스와 싱크 모델을 설명한다. 위험한 결과는 흔히 공격자가 제어하는 콘텐츠와 잘못된 컨텍스트에서 해로워지는 기능을 모두 필요로 한다.

이 관점은 행동 제약에 초점을 둔 Omnigent의 접근을 뒷받침한다. 동시에 단일 분류기로는 문제를 해결할 수 없는 이유도 부각한다. 시스템은 악성 입력을 감지하지 못하더라도 조작의 영향을 줄여야 한다.

독립 연구도 같은 방향을 가리킨다. ACL 2025 Task Shield 논문은 각 지침과 도구 호출이 사용자가 지정한 목표에 기여하는지를 평가한다.

AgentDojo 벤치마크에서 연구진은 GPT-4o로 공격 성공률 2.07%, 작업 효용성 69.79%를 보고했다. 이 결과는 Omnigent의 구현이 아니라 해당 벤치마크와 구성에 적용된다.

효용성 수치는 작업 정렬 방어 뒤에 있는 트레이드오프를 드러낸다. 시스템은 공격을 차단하면서도 정당한 업무를 막을 수 있다. 정책이 사용 가능한 수준의 작업 완료를 보존할 때에만 보안이 향상된다.

Databricks는 새 제어에 대해 비교 가능한 벤치마크 결과를 공개하지 않았다. 시연은 하나의 주입된 필드, 하나의 에이전트, 세 개의 도구, 하나의 선언된 목적을 보여준다. 이는 장시간 세션이나 모호한 엔터프라이즈 작업 전반의 일반 성능을 입증하지는 않는다.

모델 업데이트 이후의 오탐 허용, 오탐 거부, 평가자 지연 시간 또는 정책 동작에 대한 공개 증거도 아직 없다. 이러한 측정치가 이 접근이 설득력 있는 사례를 넘어설 수 있는지를 결정할 것이다.

공격자 역시 적응할 것이다. 선언된 작업과 연결된 것처럼 들리는 주입 지침을 만들 수 있다. 예를 들어 지침은 검토 중인 동일한 테이블을 검증하려면 액세스 권한 부여가 필요하다고 주장할 수 있다.

공개된 시연은 이미 외부 수신자를 감사자로 설명하는 방식으로 이 전략을 사용한다. 승인된 의도가 여전히 좁기 때문에 정책은 권한 부여를 차단하지만, 더 복잡한 작업에서는 경계가 덜 명확해질 것이다.

악성 지침은 허용된 도구 안의 인수를 노릴 수도 있다. 세션이 대시보드 업데이트를 허용한다면 공격자는 대시보드 본문에 기밀 필드를 삽입하려 할 수 있다. 도구 수준의 목적 정렬만으로는 그러한 변형을 반드시 감지하지 못할 수 있다.

따라서 databricks permission 제어를 평가하는 팀은 여러 수준에서 정책 결정을 시험해야 한다. 일반 요청, 모호한 요청, 주입된 콘텐츠, 오해를 부르는 비즈니스 정당화, 허용된 작업 내의 악성 인수를 모두 포함해야 한다.

또한 각 결정이 발생한 이유를 기록해야 한다. 로그에 관련 의도와 제안된 행동 없이 ALLOW, ASK 또는 DENY만 포함되어 있다면 보안팀은 일관되지 않은 집행을 조사할 수 없다.

가장 유용한 비교 대상은 의도 제어와 완벽한 안전의 대결이 아니다. 이는 계층형 시스템 안에서 의도 제어와 신원 기반 권한 부여만의 비교다.

이 비교에서 Omnigent는 실제 공백을 메운다. 남은 질문은 팀이 모든 유용한 에이전트 행동을 수동 검토로 바꾸지 않으면서 보호를 얻을 만큼 목적을 정확하게 정의할 수 있느냐다.

Omnigent의 모델이 유지되는지를 보여줄 세 가지 신호

다음 단계는 초기 시연의 명확성이 아니라 측정 가능한 집행 품질로 평가해야 한다.

첫 번째 신호는 재현 가능한 평가 스위트다. Omnigent에는 서로 다른 모델, 하니스, 도구 및 간접 인젝션 전략을 아우르는 테스트가 필요하다.

유용한 결과는 공격 성공, 정당한 작업 완료, 오탐 허용, 오탐 거부 및 사람에게 이관되는 비율을 구분해 제시할 것이다. 또한 표현의 작은 변화가 실질적으로 다른 결정을 만드는지도 보여줘야 한다.

적대적 테스트 전반에서 강한 성능을 보인다면 목적이 신뢰할 수 있는 권한 부여 입력이 될 수 있다는 Databricks의 주장이 강화될 것이다. 모델이나 프롬프트에 따라 높은 변동성이 나타난다면 모델 지원 의도 검사를 집행 경계로 삼는 근거는 약화될 것이다.

두 번째 신호는 배포에 안전한 실패 동작이다. Omnigent의 문서는 사용할 수 있는 LLM 구성이 없을 때 내장 정책이 fail-open 방식으로 동작한다고 말한다.

사용자는 시작 시 검증, 관리 알림, fail-closed 옵션, 그리고 평가자가 실행되지 못할 때의 명확한 감사 기록을 확인해야 한다. 구성 드리프트가 조용히 이를 제거할 수 있다면 컨텍스트 정책은 거의 보호를 제공하지 못한다.

평가자 장애를 가시적으로 처리한다면 설계는 강화될 것이다. 눈에 띄는 경고 없이 허용적 동작이 계속된다면 심각한 운영 공백이 남게 된다.

세 번째 신호는 작성자들이 제시한 사례를 넘어선 도입이다. 실제 팀은 코딩, 지원, 데이터 운영, 이메일, 캘린더 및 다중 에이전트 위임을 위한 정책을 공개해야 한다.

이러한 사례는 조직이 정당하게 변화하는 과제의 의도를 어떻게 정의하는지 드러내야 한다. 또한 사용자가 ASK 프롬프트를 얼마나 자주 받는지, 그리고 그 프롬프트가 의사결정을 개선하는지도 보여줘야 한다.

더 폭넓은 사용은 설계의 핵심 약속을 시험하게 된다. 하나의 에이전트가 유용한 기능을 유지하면서도 현재 작업에 필요한 부분만 행사할 수 있다는 약속이다. 반복되는 정책 우회나 감당하기 어려운 승인 피로는 이 약속을 약화시킬 것이다.

이 때문에 Omnigent 출시는 하나의 오픈소스 프레임워크를 넘어 의미가 있다. 에이전트 개발자들은 신뢰할 수 없는 정보를 읽고 유효한 엔터프라이즈 자격 증명을 통해 행동하는 시스템을 만들고 있다. 그 결과로 생기는 위험은 기존 접근 제어와 모델 안전성 사이에 놓여 있다.

Databricks permission은 두 부분으로 이루어진 결정이 되고 있다. 이 신원이 행동할 수 있는가, 그리고 이 행동이 승인된 목적에 부합하는가?

두 번째 질문이 프롬프트 인젝션을 제거하지는 않을 것이다. 하지만 주입된 지침이 모델에 영향을 준 뒤 중요한 도구에 도달하기 전에 이를 차단할 자리를 만든다.

개발자는 작업 컨텍스트에 따라 권한 부여가 달라지는 행동을 식별하는 것부터 시작해야 한다. 이후 보안팀은 의도 정책이 관련 없는 작업을 거부하고, 모호한 작업을 이관하며, 정당한 업무를 보존하는지 테스트할 수 있다.

엔터프라이즈 구매자는 공급업체에 이 세 가지 결과에 대한 증거를 요구해야 한다. 모든 것을 차단하는 제어는 유용한 권한 부여가 아니다. 모든 워크플로를 보존하면서 적대적 요청을 놓치는 제어 역시 의미 있는 보호가 아니다.

이제 실무적 질문은 피할 수 없다. AI 에이전트가 어떤 행동을 수행할 권한을 가지고 있다면, 그 행동이 사용자의 현재 목적에 부합한다는 사실을 독립적으로 집행하는 증거는 무엇인가?