AI 레드팀 해설: 레드팀이 테스트하는 것과 그 후에 남는 것

대부분의 AI 레드팀 프로젝트는 잘못된 산출물로 평가됩니다. 일주일의 작업은 슬라이드 덱을 만들어 내고, 그 덱은 어시스턴트가 설득당해 피싱 이메일을 작성할 수 있다고 말하지만, 이후에 그 행동이 재현 가능했는지, 얼마나 심각했는지, 어떤 통제가 그것을 막을 수 있었는지는 아무도 말할 수 없습니다. 이 분야에는 실제 산출물이 있으며, 그것은 덱이 아닙니다. 바로 재실행을 견디는 발견 사항들의 집합이며, 각각은 침범된 경계와 그 경계를 넘게 한 증거에 연결되어 있습니다. 그것은 또한 그 기록의 형태이기도 합니다. 즉, AI 인시던트 아카이브가 보관하는 기록 — 2024년 12월부터 2026년 10월까지를 포괄하는 400개 항목으로, 743개의 서로 다른 출처에서 가져왔으며, 각 항목마다 실제로 누군가가 피해를 입었는지에 대한 판정이 포함되어 있습니다.

혼란은 이해할 만합니다. "red teaming"이 어휘만 공유하고 그 외에는 거의 공통점이 없는 두 가지 작업에 쓰이기 때문입니다. 이 글은 두 작업 모두와 각 작업이 산출해야 하는 증거, 그리고 AI red teaming이 대부분의 보안 팀이 이미 수행할 줄 아는 네트워크 버전과 진정으로 달라지는 네 가지 지점을 다루는 안내서입니다.

프레임워크 질문: 테스트는 누가 소유하는가

범위를 정하기에 앞서, 누가 이 실습을 운영하고 무엇을 대상으로 하는가라는 질문이 있습니다. Microsoft는 이에 관해 비교적 완전한 공개 입장 중 하나를 내놓았으며, 이는 제품 페이지라기보다 지도처럼 읽을 가치가 있습니다. Microsoft의 AI Red Team 허브는 AI 레드 팀의 개념을 실행 방법과 분리하고, 그다음 이 실무를 그 자체로 하나의 논증이 되는 순서로 정리합니다: 개요, LLM 레드 팀 구축 가이드, 그다음 참고 자료 — 머신러닝 시스템에 대한 공격을 선별 분류하기 위한 버그 바, 머신러닝 실패에 대한 분류 체계, 공동 책임 모델, 개발자 위협 모델링 지침.

순서를 읽어 보면 방법론이 따라 나온다. 분류 체계는 무엇이 실패로 간주되는지를 정한다. 버그 바는 그 실패 중 어느 것이 고칠 가치가 있는지를 정한다. 공동 책임 모델은 그것이 발견된 후 누가 책임을 질지를 정한다. 위협 모델링은 다음에 어디를 살펴볼지를 정한다. 이 네 가지가 없으면 레드 팀은 심각도 열을 억지로 붙여 만든 일화를 양산하는 셈이고, 그 심각도 열이란 테스터가 그날 오후에 느낀 대로일 뿐이다.

마이크로소프트의 오픈 자동화 프레임워크인 PyRIT은 같은 선반에 꽂혀 있으며, 바로 그 배치가 유용한 부분이다. 오케스트레이션 키트는 방법론이 아니다. 그것은 택소노미와 버그 기준이 마련된 뒤에 목표물을 겨냥하는 도구일 뿐이다. 프레임워크부터 시작하는 팀은 결국 방대한 프롬프트 코퍼스만 남고 결과의 순위를 매길 방법이 없는 상태로 끝나기 쉽다.

두 개의 레드 팀, 두 가지 다른 질문

이 분야에서 가장 유용한 구분은 거의 아무도 글로 적어 두지 않는다는 점입니다: 모델을 테스트하는 레드팀과 시스템을 테스트하는 레드팀은 서로 다른 질문에 답하고 있으며, 테스트 대상 단위도, 산출물도, 책임자도 다릅니다. 이 둘을 뒤섞는 것이 바로 탈옥(jailbreak)이 보안 취약점으로 보고되고, 진짜 권한 상승 버그가 모델 품질 문제로 접수되는 이유입니다.

모델 수준의 안전성 평가는 측정 문제입니다. 어떤 모델이 특정 범주의 콘텐츠를 생성할지 묻는 것이며, 이에 정직하게 답하는 방법은 비율에 대해 말할 수 있을 만큼 충분히 큰 표본을 사용하는 것입니다. 테스트 대상 단위는 얇은 API 뒤에 있는 모델이고, 방법은 적대적 프롬프트 — 탈옥, 페르소나 공격, 다중 턴 압박 — 이며, 결과물은 대화 기록과 유해성 판단입니다. 가중치가 바뀌거나 공급업체의 안전 계층이 달라지면 전체 결과는 더 이상 유효하지 않습니다. 그래서 이런 종류의 테스트는 보통 모델 개발자나 독립 평가자가 수행하며, 그 결과가 애플리케이션의 특정 수정 사항에 거의 직접적으로 대응되지 않는 것입니다.

시스템 수준의 적대자 에뮬레이션은 엔지니어링 문제입니다. 공격자가 배포된 대상이 행동하도록 만들 수 있는지, 즉 해서는 안 되는 파일을 읽거나, 해서는 안 되는 도구를 호출하거나, 해서는 안 되는 비용을 지출하게 할 수 있는지를 묻는 것입니다. 테스트 대상 단위는 도구, 검색, 자격 증명이 연결된 에이전트입니다. 방법은 익숙한 것들을 목표만 바꾼 것입니다. 사용자의 발화가 아니라 검색된 콘텐츠를 통한 주입, 도구 남용, 개별적으로는 합리적인 권한들로 조립된 권한 사슬, 테넌트 경계를 넘어 유출되는 데이터 경로가 그것입니다. 출력은 재현, 넘어선 경계, 그리고 내일 구성 변경이 가능한 소유자를 포함한 발견 사항입니다.

둘은 서로 호환되지 않는 산출물을 만들어 내며, 그 비호환성은 짜증나는 문제라기보다 진단적이다. 모델 수준의 결과는 모델을 바꾸는 것 외에는 여러분의 팀이 "고칠" 수 없다. 시스템 수준의 결과는 공급업체가 전혀 고칠 수 없다. 보고서가 둘 중 어느 것인지 말하지 않는다면, 그 항목 중 어느 것도 배정할 수 없다.

모델에 도구가 주어지면 공격 표면이 어떻게 변하는가

대부분의 팀이 여전히 테스트하는 표면은 프롬프트입니다. 이는 가장 흥미롭지 않은 표면이기도 한데, 모델 공급업체가 경화에 가장 많은 노력을 쏟은 곳이자 공격자가 가장 적은 영향력을 행사할 수 있는 곳이기 때문입니다. 실제로 성과를 내는 표면은 애플리케이션이 추가한 것들입니다. 즉 에이전트가 호출할 수 있는 도구, 에이전트가 읽는 검색 인덱스, 턴 사이에 유지하는 메모리, 그리고 출력 채널 자체입니다.

도구는 언어 모델이 행위자가 되는 지점이며, 흥미로운 질문은 결코 "이 도구를 호출할 수 있는가"가 아니라 "이 도구가 가질 수 있었던 최소 권한은 무엇인가"입니다. 자유 텍스트 쿼리를 받는 티켓 조회 도구는 대개 다른 고객의 식별자를 받아들이도록 설득될 수 있습니다. 검색은 모델의 컨텍스트로 들어가는 콘텐츠 채널이므로, 코퍼스에 쓸 수 있는 사람은 누구든 — 공유 드라이브, 지원 매크로, 페처가 도달하는 웹 페이지 — 프롬프트에 쓰고 있는 것입니다. 메모리는 단일 턴을 지속성으로 바꿉니다. 두 번째 턴에 심어진 지시가 마흔 번째 턴에도 여전히 남아 있기 때문입니다. 출력은 모델의 텍스트가 이를 해석하는 어딘가에 도착하는 지점이며, 렌더링, 마크다운, 링크 미리보기, 셸 인접 파이프라인은 모두 텍스트를 해석합니다.

프롬프트만 테스트하는 진단은 깨끗한 결과를 보고하면서, 정작 틀린 것에 대해 옳은 결론을 내리게 된다.

왜 녹취록은 발견 사항이 아닌가

발견 사항에는 채팅 창 스크린샷에는 없는 세 가지 속성이 필요합니다. 첫 번째는 재현성입니다: 깨끗한 상태에서 다시 실행하면 같은 일이 다시 발생합니다. 모델은 비결정적이므로 재현성은 불리언이 아니라 비율입니다 — "10번 중 9번"은 발견 사항이고, "한 번 발생했다"는 소문입니다. 두 번째는 경계 침범입니다: 일어나지 말아야 했던 일을 모델의 용어가 아니라 애플리케이션 자체의 용어로 명명하십시오. "모델이 무례했다"가 아니라 "에이전트가 테넌트 B에 속한 문서를 읽었다"입니다. 세 번째는 영향에 근거한 심각도이지 테스터의 직관에 따른 것이 아니며, 이것이 바로 버그 바의 목적입니다.

그 밖의 모든 것 — 대화 기록, 프롬프트, 모델의 추론 — 은 그 세 가지를 뒷받침하는 증거다. 그것은 발견 자체가 아니며, 이것이 바로 2,000개의 탈옥 프롬프트로 이루어진 코퍼스가 이름이 붙은 통제가 첨부된 재현 가능한 시스템 발견 다섯 건보다 가치가 낮은 이유다.

AI 레드 팀 활동이 네트워크 레드 팀 활동과 달라지는 네 가지 지점

네트워크 또는 애플리케이션 보안 분야에서 넘어오는 팀들은 좋은 직관과 네 가지 잘못된 가정을 가지고 옵니다.

• 유지해야 할 경계선이란 없습니다. 네트워크 기반 작업에는 대상 목록이 있지만, 에이전트 기반 작업에는 요청 시점에 여러분이 미처 파악하지 못했을 수 있는 소스들로부터 구성되는 컨텍스트 윈도우가 있습니다. 범위는 호스트 이름이 아니라 데이터 소스와 도구 권한으로 표현되어야 합니다.

• 타깃은 비결정적입니다. 동일한 입력이 화요일에는 성공하고 수요일에는 실패할 수 있습니다. 이는 "한 번의 깔끔한 재현"이라는 증거 기준을 무너뜨리고 비율을 보고하도록 강제합니다.

• 익스플로잇은 언어이며, 언어에는 패치가 없습니다. 누락된 권한 부여 검사는 고칠 수 있습니다. 그러나 "모델이 설득될 수 있다"는 점은 패치할 수 없습니다. 언어 수준의 약점에 대한 완화책은 다른 곳에 있는 통제 — 필터, 범위 제한, 권한 경계 — 이며, 이것이 발견 사항이 단순한 동작이 아니라 그 통제를 지목해야 하는 이유입니다.

• 공급업체가 루프 안에 있습니다. 다른 누군가가 버전을 출시하면 목표가 바뀝니다. 모델 수준의 결과는 테스트한 빌드에 대해서만 유효하며, 버전과 날짜를 기록하지 않았다면 결과가 없는 것입니다.

첫 프로젝트의 범위를 설정하는 방법

일이 잘 풀리지 않는 엔게이지먼트는 거의 항상 "AI를 테스트한다"로 범위가 잡힌다. 일정과 맞닥뜨려도 살아남는 범위는 대략 이렇게 생겼다: 하나의 에이전트, 스테이징 환경에서, 프로덕션 형태의 데이터와 프로덕션 형태의 권한을 갖추고; 중요한 다섯 가지 경계 목록(테넌트 격리, 자격 증명 접근, 지출, 데이터 이그레스, 도구 범위); 경계를 벗어난 것이 무엇인지 명시하는 교전 규칙; 누가 실행을 중단할 수 있는지 명시하는 중지 조건; 그리고 정의된 증거 형식에 합의( 전에보고서가 기억에서 재구성되는 대신 아티팩트로부터 조립되도록, 첫 시도

권한 부여는 그 자체로 한 문장을 할애할 가치가 있습니다. 대상이 팀 자신의 제품이고 도구는 다른 누군가의 것일 때 팀이 건너뛰는 유일한 항목이기 때문입니다. 운영하지 않는 모델을, 소유하지 않은 인프라에서, 안전 계층을 무력화하도록 설계된 프롬프트로 테스트하는 것은 자체 배포를 테스트하는 것과는 다른 활동이며, 이 둘을 구분하는 것은 문서화된 범위입니다. 우리 자체 사이버 계층이 운영하는 검증 게이트도 같은 이유로 존재합니다. 모델 수준의 승인된 보안 작업에는 양측 모두에 이름이 지정된 책임 주체가 필요합니다.

인시던트 기록이 추가하는 내용

레드팀 실행은 대상이 무엇을 하는지 알려준다. 하지만 현장에서 무슨 일이 일어나는지는 알려줄 수 없으며, 통제에 대한 논거가 실제로 만들어지는 곳은 바로 현장이다. 그것이 인시던트 원장이 메우는 격차다. 그리고 그것이 부과하는 규율이 유용한 부분이다. 최소한 하나의 출처가 없는 기록은 존재하지 않는 것이고, 피해 판정이 없는 기록은 인시던트가 아니다.

두 산출물을 함께 읽으면 순환이 완성된다. 레드 팀은 재현 가능한 발견을 내놓고, 그것을 막았을 통제를 지목한다. 기록은 현장에서 누군가 이미 그 경계에 부딪힌 적이 있는지, 피해가 무엇이었는지, 그리고 그 통제가 다른 곳에서도 유지되었는지를 알려준다. 현장 선례가 없는 발견은 고칠 가치가 있는 가설이고, 재현 가능한 발견이 없는 현장 사고는 아직 닫을 수 없는 버그다. 이걸 제대로 하는 팀은 "우리가 모델을 레드팀했다"를 결과물로 취급하는 것을 멈추고, 그것을 자기들만의 원장에 들어가는 하나의 입력으로 취급하기 시작한다.

정직한 마무리 말이 남습니다. AI 레드 팀팅은 보안 보장을 만들어내지 않으며, 보안 보장인 것처럼 판매되는 계약은 잘못된 것을 팔고 있는 것입니다. AI 레드 팀팅은 이제 침범된다는 것을 알게 된 경계들의 집합을, 다시 실행할 수 있는 증거와 함께, 경계가 침범될 때 벌어지는 일을 기준으로 정렬해 제시합니다. 그것만으로 의사 결정을 내리기에 충분하며, 발표 자료 한 부보다 훨씬 더 많은 것입니다.