AI 블루 팀링 해설: 통제가 실제로 자리할 수 있는 세 가지 계층

보안팀에 AI 가드레일이 어디에 있는지 물으면, 답은 보통 정책 문서, 시스템 프롬프트 또는 벤더 기능을 꼽는다. 그중 어느 것도 통제가 아니다. 통제란 행동이 일어나는 순간 그 행동이 실제로 일어날지를 결정하는 것이며, AI 에이전트의 경우 결정할 수 있는 곳은 세 곳뿐이다: 모델, 그 앞에 있는 게이트웨이, 그리고 그 주변 환경. 블루팀이 정직하게 약속할 수 있는 모든 것은 그중 두 번째와 세 번째에서 나온다. 이것이 레이어 질문이며, 무엇을 로그로 남길지와 누구에게 연락할지를 포함한 다른 모든 블루팀 결정보다 앞선다. 현장 증거가 중요한 이유도 여기에 있다: AI 사고 아카이브는 2024-12부터 2026-10-17까지의 에이전트 사고 400건을 보관하고 있으며, 그중 대부분은 모델이 잘못 행동한 이야기가 아니다. 그것들은 '아니오'라고 말할 수 있는 계층이 없는 배포에 관한 이야기다.

AI 맥락에서 블루팀 활동은 그러한 계층들을 구축하고, 그것들이 무엇을 감지하는지 조정하며, 그중 하나가 작동하는 날을 위해 미리 연습해 둔 대응책을 마련하는 일이다. 이는 화려하지 않고 점수를 만들어 내지도 않지만, 레드팀/블루팀 쌍에서 위험 수치를 바꾸는 유일한 절반이다.

블루 팀이 이어받는 것과 그렇지 않은 것

전통적인 블루 팀 활동은 AI 배포가 조용히 깨뜨리는 일련의 가정 위에 서 있습니다. 로그는 네트워크가 모든 패킷을 보았기 때문에 완전하다고 가정되었습니다. 자산은 누군가가 프로비저닝해야 했기 때문에 열거 가능하다고 가정되었습니다. 행동은 프로그램이 동일한 입력에 동일한 작업을 수행하기 때문에 결정론적이라고 가정되었습니다. 이 세 가지 가정 중 어느 것도 에이전트와 맞닥뜨리면 살아남지 못합니다.

블루 팀이 대신 물려받는 것은 가장 중대한 결정들이 네트워크 계층이 하나의 호스트 이름으로 향하는 평범한 HTTPS 트래픽으로 취급하는 요청 내부에서 일어나는 시스템입니다. 프롬프트, 검색된 컨텍스트, 도구 호출, 완성 결과 — 이 모든 것이 요청 본문 안에 있으며, 아무도 그 본문을 캡처하고 파싱하지 않는다면 경계가 얼마나 훌륭하든 배포는 사실상 모니터링되지 않는 상태입니다. 따라서 블루 팀의 첫 번째 과제는 탐지가 아니라 센서를 구축하는 것입니다. 요청 수준과 도구 수준의 가시성 없이는 탐지할 대상이 없으며, 모든 하위 통제는 장식에 불과합니다.

누가 실제로 그 통제를 집행할 수 있나요?

센서가 있으면 문제는 각 컨트롤이 어디에 놓일 수 있는지로 바뀐다. 이것을 기술이 아니라 소유권 기준으로 그리는 것이 유용한데, 다음 릴리스에서 컨트롤이 살아남을지를 결정하는 것은 소유권이기 때문이다.

모델 계층은 그것을 학습시킨 사람의 것입니다. 당신은 그것을 구성하지 않으며, 그 내부를 들여다볼 수도 없고, 그 동작은 공급사가 새 버전을 내놓을 때마다 — 어쩌면 어느 화요일일 수도 있는 — 바뀝니다. 당신이 할 수 있는 일은 버전을 고정하고, 버전 변경을 재시험이 필요한 위험 태세의 변경으로 취급하는 것입니다. 여기서 통제 수단을 주장할 수는 없습니다. "모델이 유해한 요청을 거부한다"는 것은 당신이 기대고 있는 속성이지, 당신이 운영하는 메커니즘이 아닙니다.

게이트웨이 계층은 모든 프롬프트와 완성이 여러분이 소유한 컴포넌트를 통과하는 지점입니다. 이곳에 예산 및 속도 한도가 있고, 허용 목록과 도구 권한이 적용되며, 요청 및 응답 로깅이 구조상 완전하게 이루어지고, 토큰이 과금되기 전에 요청을 재작성하거나 차단하거나 경로를 바꿀 수 있습니다. 게이트웨이 제어는 모델을 바꿔도 계속 유지되는 유일한 제어이기도 하며, 이는 들리는 것보다 더 중요합니다. 제어를 프롬프트에 넣는 팀은 마이그레이션하는 날 그것을 완전히 잃어버리기 때문입니다.

환경 계층은 전적으로 여러분의 몫인 계층입니다. 자격 증명과 그 범위, 네트워크 이그레스, 파일 접근, 그리고 실제 경과 시간과 비용에 대한 샌드박스 제한이 여기에 해당합니다. 또한 침해된 실행이 피해를 입는 곳이기도 합니다. 악의적으로 행동하도록 설득된 에이전트는 그 환경이 해당 행동에 허용한 범위에 정확히 비례하여 위험합니다. 그리고 환경은 "최소 권한"이 연구 과제가 아니라 구성 변경인 유일한 곳입니다.

제안된 모든 AI 통제에 대한 실질적 시험은 한 가지 질문입니다: 이 세 계층 중 어느 계층이 이를 강제하는가? 답이 모델 계층이라면, 그 통제는 희망에 불과합니다. 답이 "시스템 프롬프트"라면, 그것은 모델 계층 내부의 제안에 불과하며, 그렇지 않다고 주장하는 문서와 함께 제공되기 때문에 희망보다 더 나쁩니다.

감지: 에이전트가 실제로 내보내는 내용

에이전트에 대한 탐지는 사람에 대한 탐지와는 다른 신호 집합을 기반으로 작동합니다. 상관 분석할 로그인 이상 징후는 없습니다. 대신 존재하는 것은 비정상적으로 풍부한 구조를 지닌 요청 스트림이며, 경보를 울릴 가치가 있는 네 가지 신호 계열이 있습니다.

• 도구 호출의 양과 형태. 한 작업에서 갑자기 파일 읽기 도구를 마흔 번씩 호출하거나, 도구 시퀀스가 3단계에서 30단계로 바뀌는 에이전트는 한번 살펴볼 만합니다 — 악의적이어서가 아니라 분포가 움직였기 때문입니다.

• 경계에서의 콘텐츠 출처. 프롬프트의 어떤 텍스트가 사용자로부터 왔고, 어떤 것이 검색에서 왔으며, 어떤 것이 도구 결과에서 왔고, 어떤 것이 메모리에서 왔는지. 대부분의 프롬프트 인젝션 탐지는 "데이터만 전달해야 하는 채널에 지시문 텍스트가 나타났다"로 귀결되며, 게이트웨이가 입력 과정에서 출처를 표시하지 않으면 이를 계산할 수 없습니다.

• 이그레스 및 범위 경계. 허용 목록 외부의 목적지에 대한 요청, 범위를 벗어난 경로 읽기, 의도된 서비스 범위를 벗어난 자격 증명 사용 시도. 이는 정밀도가 높은 신호이며, 환경이 이미 무엇이 허용되었는지 알고 있기 때문에 비용이 거의 들지 않습니다.

• 지출과 지연 시간을 대리 지표로 활용하기. 폭주하는 루프와 침해 사고는 모두 비용 곡선의 기울기가 달라지는 모습으로 나타납니다. 예산 알림은 스택에서 가장 눈에 띄지 않는 탐지 수단이지만, 투자 대비 효과가 가장 빠르게 나타나는 수단 중 하나이기도 합니다.

그 목록에서 의도적으로 빠져 있는 것은 완료 응답이 유해했는지 판단하도록 요청받는 분류기다. 이는 팀들이 가장 먼저 손을 뻗는 탐지 아이디어이자, 시간이 지날수록 가장 빠르게 낡는 아이디어다. 모델을 따라 표류하고, 분석가들이 그것을 무시하도록 길들이는 오탐률을 갖고 있으며, 러너북에 넣을 만한 것은 아무것도 주지 않는다.

통제: 잘못된 실행을 멈추는 세 가지 손잡이

에이전트에 대한 컨테인먼트는 생각보다 단순합니다. 세 가지 손잡이만으로 거의 모든 것을 다룰 수 있기 때문입니다. 예산은 한 번의 실행이 지출할 수 있는 비용을 제한하여 금전적 피해와 루프의 영향 범위를 모두 한정합니다. 범위는 한 번의 실행이 건드릴 수 있는 대상, 즉 해당 작업에 활성화된 도구와 경로, 테넌트를 제한합니다. 샌드박스는 실행할 수 있는 시간과 실행 중 접근할 수 있는 대상을 제한합니다. 이 세 가지는 모두 게이트웨이 또는 환경 설정이며, 이는 곧 강제 적용이 가능하다는 뜻입니다.

중요한 설계 원칙은 에이전트 단위 범위가 아니라 작업 단위 범위입니다. 상시 권한 세트를 가진 에이전트는 누군가 감사할 때까지 권한이 누적되는 에이전트입니다. 작업이 진행되는 동안 작업 범위로 한정된 자격 증명을 받는 에이전트는 스스로 만료되는 경계를 갖습니다. 두 번째 방식은 구축하는 데 더 많은 노력이 들지만 방어하는 데는 훨씬 저렴합니다.

게이트웨이가 이름값을 하는 지점도 바로 여기입니다. 모든 모델 호출 앞단에 위치하는 제어 — 도구 및 MCP 호출은 실행 전에 평가되고, 콘텐츠 정책과 개인정보 마스킹은 요청이 과금되기 전에 적용됩니다 — 는 그 뒤에 있는 모델이 지난 분기에 쓰던 모델이든 지난주에 출시된 모델이든 동일합니다. 그 연속성이야말로 진짜 제품입니다. 더 나은 필터가 아니라, 모델이 바뀌어도 함께 움직이지 않는 필터의 거처인 것입니다.

복구: 재생, 패치, 재테스트

AI 사고 복구에는 네트워크 사고 복구 대비 한 가지 이점이 있습니다. 바로 전체 실행 과정이 대개 기록된다는 점입니다. 프롬프트, 컨텍스트, 도구 호출, 완료, 타이밍까지 — 게이트웨이가 기록해 두었다면 해당 사고를 재현할 수 있으며, 이는 대부분의 포렌식이 얻는 것보다 더 강력한 출발점입니다.

리플레이는 세 가지 목적을 순차적으로 수행합니다. 첫째, 여러 사람이 요약한 뒤 전사본이 시사하는 바가 아니라 실제로 무슨 일이 일어났는지를 규명합니다. 둘째, 작동했어야 할 통제를 식별하는데, 이는 증상을 고치는 것과 경계를 고치는 것의 차이입니다. 셋째, 회귀 사례를 만들어냅니다. 즉, 이제는 차단되어야 하는 기록된 입력을 새 구성에 대해 실행하여 실제로 차단되는지 입증하는 것입니다.

패치 단계는 블루 팀이 가장 자주 목표를 잘못 짚는 단계입니다. 발견 사항이 모델 동작이었다면 사용 가능한 완화 조치는 모두 모델 외부에 있습니다 — 범위 축소, 게이트웨이의 필터, 환경에서 제거된 권한입니다. 발견 사항이 시스템 동작이었다면 수정은 구성에 있고 회귀 테스트는 비용이 적게 듭니다. 어느 쪽이든, 재테스트는 선택 사항이 아닙니다. 수정과 모델 버전이 모두 변경되기 때문이며, 지난달 빌드에 대해 검증된 통제는 지난달에 대한 주장일 뿐입니다.

그것이 발동하는 날을 예행연습하다

압박 속에서 한 번도 읽어본 적 없는 런북은 역량이 아니라 문서일 뿐입니다. 효과가 있는 리허설은 좁고 구체적입니다. 그럴듯한 에이전트 사고 하나를 잡아 처음부터 끝까지 짚어보고 각 단계의 시간을 재는 것입니다. 누가 알아차릴까요? 사람이 올바른 로그 라인을 들여다보기까지 얼마나 걸릴까요? 누가 실행을 멈출 수 있을까요 — 이름이 지정된 한 사람일까요, 아니면 위원회일까요? 누가 자격 증명을 폐기할 수 있고, 폐기가 전파되는 데 얼마나 걸릴까요? 회사 외부에 누군가에게 알릴지 여부는 누가 결정할까요?

그 질문들 중 두 가지는 팀을 확실히 곤란하게 만든다. "누가 실행을 중지할 수 있는가"는 중지에 잠들어 있는 사람이 필요할 때 실패하므로, 답은 사람이 아니라 메커니즘이어야 한다 — 당직 엔지니어 혼자서 당길 수 있는 예산 상한이나 킬 스위치 같은 것. "권한 회수는 얼마나 걸리는가"는 자격 증명이 다이어그램에 없던 구성 요소에 종종 캐시되기 때문에 실패한다.

아카이브를 읽는 것은 이용할 수 있는 가장 저렴한 리허설 형태입니다. 다른 사람들의 인시던트 구조를 물려받아 직접 만들어 내지 않아도 되기 때문입니다. 자신의 배포와 비슷한 항목을 몇 개 골라 각각에 대해 위의 세 가지 질문을 던져 보세요. 그 질문에 답할 수 없는 항목이 바로 런북의 빈틈이며, 인시던트가 발생한 뒤가 아니라 그 전에 발견한 것입니다.

분명히 짚고 넘어갈 만한 비대칭성

레드 팀 활동과 블루 팀 활동은 대칭적인 활동이 아니며, 마치 대칭인 것처럼 예산을 배정해서는 안 된다. 레드 팀 실행은 일정에 의해 제한되며, 표적이 바뀌면 그 효력이 줄어드는 발견 사항들을 산출한다. 블루 팀의 통제 수단은 지속되고 축적되며, 나쁜 입력과 나쁜 결과 사이에 실제로 존재하는 유일한 방어선이다. 한 번의 활동은 경계를 찾아낼 수 있지만, 그 경계를 지켜낼 수 있는 것은 오직 다른 한쪽뿐이다.

그로 인해 블루 팀의 정직한 기준은 화려하지 않고 검증 가능한 것이 된다. 당신이 주장하는 모든 통제에 대해, 이를 강제하는 계층, 작동했음을 증명하는 로그 한 줄, 작동하지 않았을 때 알려주는 경고, 그리고 실행을 중단시킬 수 있는 사람을 밝힐 수 있어야 한다. 네 문장이다. 그중 하나라도 빠지면 그 통제는 정책 문서이며, 정책 문서는 요청 본문을 읽지 않는다.