AI 오케스트레이션 프레임워크는 이제 기업 보안의 핵심 의사결정 사항이다

Google News는 8월 6일 기업에 분명한 경고를 제시했다. 이제 AI 오케스트레이션 프레임워크를 선택한다는 것은 공격자가 시스템에 접근할 수 있는 지점을 선택한다는 뜻이다.

CSO Online의 헤드라인은 이 선택을 중대한 보안 의사결정으로 규정한다. 이는 오케스트레이션 소프트웨어가 더 이상 언어 모델 간 요청을 단순히 라우팅하는 역할에 그치지 않기 때문에 중요하다. 이제는 에이전트를 데이터베이스, 브라우저, 코드 저장소, 고객 기록, 프로덕션 도구에 연결할 수 있다.

갈등은 명확하다. 개발자는 에이전트의 역량을 높이고 배포를 쉽게 해 주는 프레임워크를 원한다. 보안팀은 모델이 지시를 오해하거나, 적대적 콘텐츠를 수집하거나, 잘못된 도구를 호출하더라도 계속 강제할 수 있는 경계를 필요로 한다.

이러한 긴장은 가상의 위협 모델을 넘어섰다. NIST는 다수의 에이전트가 에이전트 하이재킹이라고도 불리는 간접 프롬프트 인젝션에 여전히 취약하다고 말한다. 이 공격에서는 악성 지시가 에이전트가 정상적인 작업을 수행하는 과정에서 읽는 콘텐츠 안에 숨겨진다.

에이전트가 행동할 수 있게 되면, 오염된 지시는 시스템 이벤트로 이어질 수 있다. 그 결과는 승인되지 않은 메시지, 노출된 파일, 변경된 기록 또는 위험한 인프라 명령일 수 있다.

이에 따라 Google 연구진과 학계 파트너들은 조직이 에이전트를 단순히 기반 모델을 개선하는 대상으로 보지 말고 시스템으로서 보호해야 한다고 주장해 왔다. 이들의 분석은 최소 권한, 완전 매개, 정보 흐름 통제, 그리고 모델 외부의 변조 방지형 강제를 강조한다.

이 입장은 현재 다수의 AI 프로젝트가 구매되는 방식을 문제 삼는다. 팀은 흔히 모델 지원, 워크플로 템플릿, 메모리 기능, 개발 속도를 기준으로 프레임워크를 비교한다. 이러한 요소는 중요하지만, 누가 각각의 행동을 승인하는지 또는 침해된 워크플로가 어떻게 격리되는지는 보여주지 않는다.

오케스트레이션 프레임워크가 이러한 질문에 답한다. 이는 확률적인 모델 출력과 결정론적인 기업 시스템 사이에 위치한다. 이 위치는 아키텍처 선호를 보안 경계로 바꾼다.

Google News의 경고가 실제로 바꾸는 것

벤더가 이를 일반적인 개발자 인프라로 제시하더라도, 오케스트레이션 계층은 특권을 가진 제어 플레인이 되었다.

AI 오케스트레이션 프레임워크는 모델, 에이전트, 도구, 데이터 소스, 메모리, 워크플로 상태를 조율한다. 어떤 구성 요소가 요청을 처리하고 어떤 컨텍스트가 구성 요소 사이에서 이동하는지 결정한다.

이 정의는 운영적인 설명처럼 들린다. 그러나 프레임워크가 자격 증명을 저장하고, 도구를 호출하며, 작업을 위임하거나, 후속 행동을 승인할 때 보안상 결과가 드러난다.

기존 챗봇은 사람이 검토할 텍스트를 반환한다. 오케스트레이션된 에이전트는 받은편지함을 확인하고, 계약서를 검색하며, 고객 기록을 업데이트하고, 다른 직원에게 알림을 보낼 수 있다. 각각의 추가 행동은 실수하거나 조작된 지시가 미칠 수 있는 영향을 확대한다.

따라서 핵심 변화는 단일 제품 출시가 아니다. 행동을 권고하는 AI에서 연결된 워크플로를 실행하는 AI로의 이동이다.

NIST의 하이재킹 분석은 근본적인 약점을 명확히 설명한다. 모델은 동일한 언어 인터페이스를 통해 신뢰할 수 있는 지시와 신뢰할 수 없는 데이터를 받는다. 모델은 명령과 명령처럼 보일 뿐인 콘텐츠를 구분하는 데 어려움을 겪을 수 있다.

수신 지원 티켓을 요약하도록 요청받은 에이전트를 생각해 보자. 한 티켓에는 에이전트에게 내부 파일을 검색해 응답에 포함하라고 지시하는 숨은 텍스트가 들어 있을 수 있다. 역량 있는 모델은 해당 텍스트를 작업의 일부로 취급할 수 있다.

그다음에 일어나는 일은 오케스트레이터가 결정한다. 제약된 프레임워크는 파일 요청을 거부하거나, 사용자의 권한을 확인하거나, 사람의 승인을 요구할 수 있다. 관대한 프레임워크는 주입된 텍스트를 성공적인 도구 호출로 전환할 수 있다.

이 때문에 프레임워크 평가는 모델 평가와 실질적으로 다르다. 모델 벤치마크는 시험 조건에서 모델이 어떻게 행동하는지 추정한다. 오케스트레이션 검토는 모델이 잘못 행동할 때 주변 시스템이 무엇을 허용하는지 살핀다.

이 구분은 책임의 소유도 바꾼다. 애플리케이션 팀은 모델 제공업체가 모든 보안 통제를 처리한다고 가정할 수 없다. 모델 벤더는 자신들이 운영하지 않는 데이터베이스, 티켓팅 플랫폼, 클라우드 계정 또는 내부 API 내 권한을 강제할 수 없다.

오케스트레이션 계층을 배포하는 기업은 이러한 연결을 통제한다. 따라서 그 기업은 그에 따른 아이덴티티 설계, 권한 경계, 로깅 요구사항 및 사고 대응 프로세스를 책임진다.

Google News는 새롭게 발명된 취약점 범주를 발견한 것이 아니다. 보안 연구 전반에서 이미 나타나고 있던 변화를 부각했다. 이제 에이전트 보안은 단순히 모델의 악성 프롬프트 저항성에 달린 것이 아니라 모델을 둘러싼 아키텍처에 달려 있다.

이 점은 조달 설문지를 즉시 바꿔야 한다. 구매자는 프레임워크가 에이전트를 어떻게 인증하고, 자격 증명을 어떻게 제한하며, 워크플로를 어떻게 검증하고, 결과를 초래하는 모든 행동을 어떻게 기록하는지 물어야 한다.

또한 증거가 필요하다. 역할 기반 접근 제어를 지원한다는 체크박스만으로는 통제가 도구, 메모리, 위임된 에이전트 및 백그라운드 작업까지 포괄하는지 알 수 없다.

가장 중요한 기능은 더 이상 프레임워크가 데모를 얼마나 빨리 완성하는지가 아니다. 데모가 프로덕션 워크플로가 되었을 때도 프레임워크가 정책을 유지하는지 여부다.

AI 오케스트레이션 프레임워크 보안이 다른 이유

에이전틱 시스템은 불확실한 추론과 실제 권한을 결합하며, 이는 기존 애플리케이션 보안이나 모델 가드레일만으로는 완전히 다룰 수 없는 위험을 만든다.

기존 소프트웨어는 엔지니어가 검사할 수 있는 코드 경로를 따른다. 입력은 여전히 취약점을 유발할 수 있지만, 의도된 실행 로직은 일반적으로 소스 코드나 컴파일된 구성 요소에 존재한다.

에이전트는 다르게 행동한다. 모델은 런타임 중 계획을 수립하고, 컨텍스트에 따라 도구를 선택하며, 결과를 관찰한 뒤 다음 단계를 조정한다. 유사한 두 요청도 서로 다른 실행 경로를 만들 수 있다.

이러한 가변성은 테스트를 복잡하게 한다. 보안 검토는 하나의 고정된 워크플로를 검사한 뒤 모든 미래 경로가 이를 따를 것이라고 가정할 수 없다. 오케스트레이터는 애플리케이션 팀이 명시적으로 작성하지 않은 경로 전반에서 규칙을 강제해야 한다.

프롬프트 필터만으로는 이러한 보장을 제공할 수 없다. 필터는 악성 언어를 식별하려 하지만, 공격자는 표현, 인코딩, 문서 구조 또는 컨텍스트를 바꿀 수 있다. 정상 콘텐츠도 지시처럼 보일 수 있다.

NIST의 2026년 레드팀 결과는 이 어려움을 보여준다. 연구진은 400명 이상의 참가자로부터 25만 건이 넘는 공격 시도를 보고했다. 테스트된 모든 프론티어 모델에 대해 최소 한 건의 공격이 성공했다.

레드팀 조사 결과는 모든 에이전트가 필연적으로 침해된다는 뜻은 아니다. 이는 기업이 모델 수준의 저항성을 완전한 보안 경계로 간주해서는 안 되는 이유를 보여준다.

안전한 오케스트레이션 설계는 모델이 때때로 잘못된 결정을 내릴 것이라고 가정한다. 그런 다음 외부 통제를 통해 피해를 제한한다.

최소 권한은 그러한 통제 중 하나다. 에이전트에는 사용자나 개발자가 보유한 모든 권한이 아니라 현재 작업에 필요한 권한만 부여해야 한다.

이는 오랫동안 이어져 온 보안 원칙이기 때문에 익숙하게 들린다. 작업이 동적으로 변하고 자격 증명이 위임된 워크플로 전반으로 이동할 때 이를 에이전트에 적용하는 일은 어려워진다.

고객 불만을 조사하는 에이전트는 하나의 지원 사례에 대한 읽기 권한이 필요할 수 있다. 모든 고객 기록에 대한 무제한 접근 권한은 필요하지 않다. 또한 전체 데이터베이스를 내보낼 수 있는 능력도 필요하지 않다.

완전 매개도 또 다른 필수 원칙이다. 상위 에이전트가 더 광범위한 워크플로를 이전에 승인했더라도, 민감한 모든 행동은 정책 검사를 거쳐야 한다.

매개가 없다면 하위 도구는 과도한 신뢰를 상속받을 수 있다. 침해된 오케스트레이터는 연결된 에이전트가 독립적인 검증 없이 받아들이는 명령을 발행할 수 있다.

OWASP의 에이전틱 보안 자료는 중앙집중식 오케스트레이션을 잠재적인 단일 장애 지점으로 지목한다. 이 지침은 엄격한 인증, 서명된 워크플로 정의, 그리고 하위 에이전트의 독립적인 범위 검증을 권고한다.

이 오케스트레이션 지침은 개별 프롬프트에서 위임된 권한의 연쇄로 관심을 옮긴다. 약한 연결 고리 하나가 이를 신뢰하는 모든 에이전트에 영향을 줄 수 있다.

정보 흐름은 또 다른 과제를 만든다. 프레임워크는 기밀 정보를 읽도록 에이전트에 올바르게 권한을 부여하면서도, 그 정보가 이후 어디로 이동하는지는 통제하지 못할 수 있다.

예를 들어, 리서치 에이전트는 권한을 가진 직원을 위해 내부 로드맵을 검색할 수 있다. 이후의 도구 호출은 그 로드맵 일부를 외부 검색, 분석 서비스 또는 공개 메시지에 실수로 포함할 수 있다.

프레임워크는 접근과 이동을 모두 추적해야 한다. 정보를 읽을 권한이 있다고 해서 연결된 모든 채널을 통해 이를 공개할 권한이 자동으로 부여되는 것은 아니다.

메모리는 이 경계를 더욱 복잡하게 만든다. 에이전트 메모리는 상호작용 사이에서 유용한 컨텍스트를 보존할 수 있지만, 오염된 지시, 비밀 정보 또는 부정확한 결론도 유지할 수 있다.

오늘 접한 악성 문서는 며칠 뒤 워크플로에 영향을 미칠 수 있다. 따라서 보안팀에는 메모리 출처, 보존, 격리 및 삭제를 위한 통제가 필요하다.

이러한 요구사항은 프레임워크 선택이 장기적인 결과를 초래하는 이유를 설명한다. 팀이 공유 자격 증명과 불투명한 메모리를 중심으로 수백 개의 워크플로를 구축한 뒤에는 정책 강제를 개조하기 어렵다.

파일럿에서 가장 빠른 프레임워크는 프로덕션에서 보안을 확보하기 가장 느린 프레임워크가 될 수 있다. 이후 모든 도구 및 위임 경로에 보안 통제를 추가해야 할 때 개발자 편의성은 부채가 된다.

진짜 경쟁은 역량 대 격리다

주된 경쟁은 한 프레임워크와 다른 프레임워크 사이의 대결이 아니다. 에이전트 역량을 확장하는 것과 에이전트가 실패했을 때 격리를 유지하는 것의 대결이다.

프레임워크 벤더는 더 많은 시스템을 에이전트가 사용할 수 있게 하며 경쟁한다. 이들은 커넥터, 브라우저 제어, 코드 실행, 영속적 메모리, 멀티 에이전트 위임, 자동 재시도를 추가한다.

각 기능은 작업 완료를 개선할 수 있다. 동시에 각 기능은 아이덴티티, 권한 부여 및 데이터 처리 규칙이 유지되어야 하는 새로운 지점을 만든다.

이는 불편한 역전을 낳는다. 오케스트레이션 프레임워크를 매력적으로 만드는 기능은 침해의 결과도 키울 수 있다.

브라우저 도구는 이 문제를 잘 보여준다. 에이전트가 최신 정보를 조사하고 웹 애플리케이션을 운영할 수 있게 한다. 동시에 자동화된 리더를 조작하도록 설계된 신뢰할 수 없는 페이지에 에이전트를 노출한다.

코드 실행도 또 다른 사례다. 에이전트가 데이터를 분석하거나 프로젝트를 수정할 수 있게 한다. 또한 모델 오류를 파일 변경, 자격 증명 노출 또는 파괴적인 명령으로 전환할 수 있다.

멀티 에이전트 위임은 전문화된 에이전트 사이에 작업을 나눠 처리량을 높인다. 그러나 어떤 아이덴티티가 행동을 승인했는지, 어떤 구성 요소가 유해한 지시를 제공했는지를 불분명하게 만들 수 있다.

오케스트레이션 프레임워크는 그 연쇄를 유지해야 한다. 보안팀은 원래 요청, 중간 결정, 도구 인수, 반환된 데이터 및 최종 부수 효과를 재구성할 수 있어야 한다.

일반적인 애플리케이션 로그는 흔히 일부 단편만 포착한다. 도구는 이를 유발한 모델 컨텍스트를 보존하지 않은 채 API 호출을 기록할 수 있다. 모델 트레이스는 추론 과정을 보여줄 수 있지만 외부 시스템에서 무엇이 변경됐는지는 확인하지 못할 수 있다.

Google과 대학 연구자들은 계획, 메모리, 외부 도구, 실행을 결합한다는 점에서 에이전트를 운영 환경에 비유해 왔다. 이들의 주장은 집행을 모델 외부에 둔다.

한 시스템 보안 분석은 실제 환경의 에이전트 공격 11건을 검토했다. 모든 공격은 안전한 정보 흐름 원칙을 위반했으며, 대부분은 최소 권한 원칙도 위반했다.

여기서 얻을 수 있는 교훈은 모델이 중요하지 않다는 뜻이 아니다. 더 나은 모델은 실수를 줄이고 더 많은 악의적 요청을 거부할 수 있다. 그러나 모든 엔터프라이즈 시스템의 접근 정책을 정의할 수는 없다.

따라서 프레임워크는 계획과 실행을 분리해야 한다. 모델은 작업을 제안하고, 결정론적 정책 계층은 그 작업의 허용 여부를 판단할 수 있다.

고위험 작업에는 더 엄격한 처리가 필요하다. 송금, 콘텐츠 게시, 데이터 삭제, 권한 변경, 코드 배포는 자연어 지시문 외부의 명시적 통제를 요구해야 한다.

일부 작업에는 사람의 승인이 필요해야 한다. 다른 작업은 좁은 범위 내에서 자동으로 진행될 수 있다. 적절한 기준은 되돌릴 수 있는지 여부, 데이터 민감도, 잠재적 영향에 따라 달라진다.

이러한 계층형 접근 방식은 유용한 자동화를 보존한다. 모든 검색 질의나 문서 요약에 사람이 승인하도록 강제하지 않는다.

대신 공개 웹페이지를 읽는 행위와 고객 데이터를 내보내는 행위가 다르다는 점을 인식한다. 안전한 프레임워크는 집행 가능한 정책을 통해 그 차이를 표현해야 한다.

신중하게 구현된 모델 비종속 아키텍처는 격리를 지원할 수 있다. 조직은 모든 권한 규칙과 도구 통합을 다시 구축하지 않고도 모델을 교체할 수 있다.

그러나 모델 이식성이 자동으로 보안을 제공하지는 않는다. 여러 모델을 지원하는 프레임워크라도 자격 증명을 중앙화하거나, 실행 추적을 숨기거나, 광범위한 도구 접근 권한을 부여할 수 있다.

오픈 소스 역시 완전한 대리 지표가 되지 못한다. 소스 공개는 검토와 맞춤화를 개선할 수 있지만, 안전한 배포는 여전히 구성, 유지보수, 운영 규율에 달려 있다.

독점 서비스는 더 강력한 관리형 격리를 제공할 수 있다. 동시에 집행 동작에 대한 가시성을 제한할 수도 있다. 구매자는 아키텍처, 테스트, 계약상 약속에 기반한 증거가 필요하다.

실질적인 비교는 실패 시의 동작에 초점을 맞춰야 한다. 팀은 에이전트가 적대적 지시를 따르거나, 토큰을 유출하거나, 권한 범위를 넘어 위임한 뒤 어떤 일이 일어나는지 물어야 한다.

프레임워크는 실행 전에 작업을 중단시키는가? 영향을 받은 워크플로를 식별할 수 있는가? 관리자는 모든 에이전트를 비활성화하지 않고도 자격 증명을 폐기하고 메모리를 격리할 수 있는가?

더 많은 작업을 완료하지만 이러한 질문에 답하지 못하는 프레임워크는 신뢰할 수 있는 격리 없이 기능만 제공한다. 이 상충관계는 개발자 선택 과정뿐 아니라 보안 검토에 포함돼야 한다.

구매자가 Google News 헤드라인만으로 확인할 수 없는 것

헤드라인은 올바른 위험을 짚어내지만, 어떤 프레임워크가 마케팅에서 약속한 통제를 실제로 집행하는지 입증할 수는 없다.

AI 오케스트레이션을 둘러싼 보안 주장은 여전히 비교하기 어렵다. 공급업체들은 일관된 기술적 정의 없이 거버넌스, 가드레일, 관측 가능성, 엔터프라이즈 통제와 같은 용어를 사용한다.

한 제품은 가드레일을 프롬프트 필터로 정의할 수 있다. 다른 제품은 모든 도구 호출 전에 결정론적 인가를 적용할 수 있다. 이 두 통제는 동등한 보호를 제공하지 않는다.

관측 가능성 역시 마찬가지로 모호할 수 있다. 프레임워크는 토큰 사용량과 지연 시간을 표시하면서 자격 증명 전달, 메모리 쓰기, 정책 결정, 하위 시스템 변경은 누락할 수 있다.

구매자는 실패 사례를 중심으로 구성된 시연을 요청해야 한다. 매끄럽게 성공한 워크플로는 격리에 대해 거의 알려주지 못한다.

유용한 테스트는 신뢰할 수 없는 콘텐츠에서 시작된다. 팀은 권한을 가진 에이전트가 처리해야 하는 문서, 이메일, 지원 티켓 또는 웹페이지 안에 적대적 지시를 넣을 수 있다.

검토자는 이후 시스템이 해당 콘텐츠를 신뢰할 수 있는 지시와 분리하는지 관찰해야 한다. 금지된 도구 호출이 실행 전에 차단되는지도 확인해야 한다.

테스트는 위임도 살펴봐야 한다. 주 에이전트는 악의적 요청을 다른 권한을 보유한 전문 에이전트에 전달할 수 있다.

하위 에이전트가 모든 오케스트레이터 명령을 신뢰한다면 아키텍처는 취약점을 옮겨 놓는 데 그친다. 각 에이전트에는 독립적으로 집행 가능한 범위가 필요하다.

자격 증명 처리도 비슷한 수준의 검토가 필요하다. 장기간 유지되는 공유 비밀 정보는 하나의 손상된 워크플로가 관련 없는 작업에도 영향을 미칠 수 있기 때문에 광범위한 노출을 만든다.

범위가 좁은 단기 자격 증명은 이러한 노출을 줄인다. 프레임워크는 이를 특정 신원, 리소스, 작업, 시간 창에 연결해야 한다.

보안팀은 재시도 동작도 점검해야 한다. 자동 재시도는 워크플로가 일시적 장애에서 복구하도록 돕지만, 안전하지 않은 작업을 반복하거나 부실하게 설계된 승인 절차를 우회할 수 있다.

실패한 거래가 정책 집행을 빠져나갈 때까지 변형된 요청을 계속 유발해서는 안 된다. 재시도 역시 동일한 인가 및 멱등성 통제를 적용받아야 한다.

감사 기록에는 무결성 보호가 필요하다. 오케스트레이션 계층을 통제하는 공격자는 조사에 필요한 증거를 삭제하거나 다시 작성할 수 없어야 한다.

로그는 에이전트의 권한 밖에 있는 시스템으로 전송돼야 한다. 또한 안정적인 식별자를 통해 프롬프트, 도구 호출, 승인, 신원 변경, 외부 결과를 연결해야 한다.

인벤토리도 해결되지 않은 또 다른 문제다. 기업은 존재조차 알지 못하는 에이전트를 거버넌스할 수 없다.

사업 부서는 중앙 조달 절차를 거치지 않고 로컬 프레임워크, 브라우저 에이전트, 자동화 서비스, 소프트웨어 플러그인을 배포할 수 있다. 이러한 섀도 배포는 정책을 분산시키고 데이터 이동을 숨긴다.

NIST는 간접 프롬프트 인젝션, 오염된 모델, 적대적 입력 없이 발생하는 유해한 작업을 포함해 에이전트 시스템 보안에 관한 정보를 업계와 연구자들에게 요청했다.

이 에이전트 보안 이니셔티브는 아직 정립되지 않은 분야를 반영한다. 조직들은 이미 에이전트를 운영 시스템에 연결하고 있는 가운데 표준은 발전 중이다.

보안 리더는 확실성을 과도하게 주장하지 말아야 한다. 어떤 프레임워크도 프롬프트 인젝션이 절대 성공하지 않거나 모든 자율적 결정이 항상 정확하게 유지된다고 약속할 수 없다.

방어 가능한 주장은 더 좁다. 외부 집행, 범위가 제한된 신원, 격리, 감사 가능한 실행은 실패의 가능성과 영향을 줄일 수 있다.

팀은 자체 구현도 평가해야 한다. 건전한 기본 요소를 갖춘 프레임워크도 개발자가 승인을 비활성화하거나, 관리자 자격 증명을 재사용하거나, 제한 없는 도구를 노출하면 안전하지 않게 될 수 있다.

여기서 문서화 품질이 중요하다. 개발자에게는 안전한 커넥터, 정책 테스트, 자격 증명 교체, 메모리 격리, 사고 대응을 위한 명확한 패턴이 필요하다.

조직 지식도 중요하다. 에이전트 워크플로는 내부 정책, 기술 문서, 과거 결정에 의존하며, 이들은 흔히 서로 분리된 시스템에 흩어져 있다.

거버넌스가 적용된 엔지니어링 지식 기반은 검색 규율을 개선할 수 있지만, 검색이 인가를 대체하지는 않는다. 관련 정보 역시 승인된 경계 내에 남아 있어야 한다.

따라서 회의적인 결론이 중요하다. 올바른 프레임워크를 선택한다고 에이전트 보안 문제가 해결되는 것은 아니다. 다만 팀이 이를 해결하는 데 필요한 통제를 갖추게 되는지를 결정한다.

보안팀이 다음으로 주시해야 할 세 가지 신호

다음 단계는 집행 가능한 에이전트 신원, 독립적으로 테스트된 오케스트레이션 통제, 측정 가능한 운영 환경 도입으로 정의될 것이다.

첫 번째 신호는 소프트웨어 및 AI 에이전트를 위한 신원과 인가 표준의 진전이다.

인간 신원 시스템은 사람이 인증한 뒤 승인된 애플리케이션을 사용한다고 가정한다. 에이전트 시스템은 하위 에이전트를 생성하고, 서비스를 호출하며, 사용자가 부재한 상태에서도 행동할 수 있는 위임 신원을 도입한다.

보안팀은 각 에이전트, 그 소유자, 현재 작업, 허용된 위임 깊이를 식별할 수 있는 신뢰할 만한 방법이 필요하다. 또한 인간 요청자가 보유한 모든 권한을 조용히 상속하지 않는 자격 증명도 필요하다.

기계가 읽을 수 있는 에이전트 신원과 작업 범위 기반 인가를 정의하는 표준을 주시해야 한다. 주요 클라우드 플랫폼과 엔터프라이즈 소프트웨어 제공업체의 도입 여부는 표준 발표 자체보다 더 중요하다.

프레임워크가 검증 가능한 위임 체인을 갖춘 상호운용 가능한 단기 자격 증명을 구현하기 시작하면 이 신호는 핵심 주장을 강화할 것이다. 신원이 애플리케이션별 패치워크로 남는다면 이를 약화할 것이다.

두 번째 신호는 개별 모델이 아니라 전체 에이전트 시스템을 측정하는 독립적 보안 테스트다.

현재 평가는 흔히 모델이 악의적 프롬프트를 따르는지를 시험한다. 운영 환경의 위험은 도구 권한, 메모리, 워크플로 라우팅, 격리, 정책 집행에도 좌우된다.

향후 벤치마크는 공격이 실제 미인가 효과를 초래했는지 보고해야 한다. 모델이 안전하지 않은 텍스트를 생성한 경우와 오케스트레이션된 시스템이 금지된 작업을 완료한 경우를 구분해야 한다.

NIST의 대규모 테스트는 초기 기반을 제공한다. OWASP의 검증 작업 역시 오케스트레이션과 자율적 작업 전반의 에이전트 위험을 테스트 가능한 통제로 전환한다.

새롭게 등장하는 검증 표준은 조직에 감사와 침투 테스트를 위한 보다 구체적인 기반을 제공한다. 프레임워크 공급업체는 구매자가 검증할 수 있는 요구사항에 자사의 통제를 매핑해야 한다.

독립 테스트가 프레임워크 간 의미 있는 차이를 드러낸다면 이 신호는 이 글의 판단을 강화할 것이다. 대부분의 제품이 현실적인 공격 조건에서 구별되지 않는다면 이를 약화할 것이다.

세 번째 신호는 기업이 파일럿 프로그램 이후 에이전트를 어떻게 확장하는지다.

프레임워크는 개발자 5명이 워크플로 10개를 운영할 때는 안전해 보일 수 있다. 수천 명의 직원이 도구, 데이터, 메모리를 공유하는 에이전트를 만들면 거버넌스 부담은 커진다.

보안팀은 운영 환경의 에이전트 수, 활성 도구 연결 수, 차단된 정책 위반, 사람의 승인, 자격 증명 노출, 사고 대응 훈련을 추적해야 한다.

또한 에이전트를 얼마나 신속하게 격리할 수 있는지도 측정해야 한다. 평균 격리 시간은 프롬프트 필터 경고 수를 세는 것보다 더 유용해질 것이다.

인벤토리 적용 범위도 또 다른 실용적 척도를 제공한다. 중앙화된 거버넌스를 주장하는 기업은 어떤 에이전트가 존재하고, 누가 소유하며, 어떤 시스템을 변경할 수 있는지 알아야 한다.

에이전트 도입이 확대됨에 따라 Google News는 제품 발표와 보안 경고를 계속 노출할 것이다. 독자는 모델 아래에 있는 통제 평면을 통해 이러한 보도를 판단해야 한다.

결정적인 질문은 운영상의 문제다. 프레임워크는 모든 도구에서 최소 권한을 집행할 수 있는가? 위임 과정에서도 신원을 보존할 수 있는가? 조사자는 손상된 에이전트를 신뢰하지 않고도 작업을 재구성할 수 있는가?

오케스트레이션 프레임워크를 선택하는 조직은 자율성을 확대하기 전에 이러한 테스트를 실행해야 한다. 적대적 문서, 위임된 작업, 금지된 도구 호출부터 시작하라.

그다음 프레임워크에 작업이 정확히 어디에서 멈췄는지 보여 달라고 요구하라. 명확한 답을 제공하지 못한다면 그 아키텍처는 중대한 업무를 처리할 준비가 되지 않았다.

조달 문서에서 이를 워크플로 인프라로 설명하더라도 보안 결정은 이미 그 안에 존재한다. 오케스트레이터를 권한 있는 통제 평면으로 다루고, 실패 시의 동작을 테스트하며, 영향이 큰 실행은 검증 가능한 정책 뒤에 두어야 한다.