도입부 (The hook)

한 AI 네이티브 기업이 자율형 AI 에이전트(autonomous AI agent)의 공격을 받았습니다. 조사를 위해 미국의 최전선 모델(frontline American models)에 도움을 요청했지만, 해당 모델들은 거절했습니다. 결국 그들은 대신 중국의 오픈 소스 모델(open-source model)을 찾았습니다. 이 상황을 잠시 생각해보십시오. 우리를 보호하기 위해 구축된 안전 기능(safety features)이, 방어자가 다른 곳을 찾아야만 했던 이유가 되어버린 것입니다.

맥락 (Where this fits)

이것은 클릭을 유도하기 위한 프레임인 '중국 대 미국 AI' 이야기가 아닙니다. 이것은 새로운 옷을 입은 훨씬 오래된 이야기입니다. 즉, 데모(demo)를 위해서는 과하게 튜닝되었지만, 사고 대응(incident response)의 복잡한 현실을 위해서는 미흡하게 튜닝된 보안 도구(security tooling)에 관한 이야기입니다. 우리는 안티바이러스(antivirus)의 오탐(false positives), SIEM의 알람 피로(alert fatigue), 그리고 정당한 비즈니스 워크플로우를 차단하는 DLP 도구들을 통해 이 영화를 전에도 본 적이 있습니다. 패턴은 항상 동일합니다. 좋은 의도로 설계된 방어 계층이 결국 방어를 수행하려는 사람들의 길을 가로막게 된다는 것입니다.

여기서 진정으로 새로운 점은 자율성(autonomy) 측면입니다. 에이전트가 독립적으로 파이프라인에 침투하고, 일회용 샌드박스(sandboxes)를 통해 수만 건의 악성 동작을 수행하는 것은 적대적 도구(adversary tooling)의 실질적인 에스컬레이션입니다. 이 부분은 그 자체로 주목할 가치가 있습니다. 분석 도구에서 다음에 어떤 일이 일어났는지와 상관없이, 그 정도 수준의 공격 규모와 자동화는 의미 있는 변화입니다.

과장된 부분 점검 (The hype check)

과장되고 있는 부분은 바로 지정학적(geopolitical) 관점입니다. "해커와 싸우기 위해 중국 AI를 사용할 수밖에 없었던 기업"은 훌륭한 헤드라인이지만, 근본적인 문제는 가드레일 보정(guardrail calibration) 문제이지, 중국 모델이 보안 작업에 어떤 식으로든 우월하다는 증거가 아닙니다. 특정 거부 동작(refusal behaviors)이 내장되지 않은 모델이라면 무엇이든 그 역할을 수행했을 것입니다. 모델의 국적은 보도에서 서사의 핵심 역할을 하고 있음에도 불구하고, 이 이야기에서 부차적인 요소일 뿐입니다.

과소평가되고 있는 점은 이것이 기업용 프런티어 모델 (frontier models)을 구축하거나 구매하려는 모든 이들에게 경종을 울리는 사건이라는 사실입니다. 만약 모델이 공격 로그(attack logs) — 정의상 방어적 유물 (defensive artifacts)인 로그 — 를 분석하기를 거부한다면, 그 이유가 콘텐츠가 "악의적 (malicious)"인 패턴과 일치하기 때문일 때, 이는 가드레일 (guardrail)의 성공이 아니라 가드레일의 실패입니다. 보안 분석가들은 하루 종일 익스플로잇 코드 (exploit code), 멀웨어 샘플 (malware samples), 그리고 공격자의 TTPs (Tactics, Techniques, and Procedures)를 읽습니다. 그것이 그들의 업무입니다. "나를 공격한 것이 무엇인지 이해하도록 도와줘"와 "누군가를 공격하도록 도와줘"를 구분하지 못하는 모델은 캘리브레이션 (calibration) 문제를 가지고 있는 것이며, 이는 특히 사고 대응 (incident response) 시나리오에서 계속해서 나타날 것입니다. 왜냐하면 사고 대응은 본질적으로 악의적인 자료를 다루는 일이기 때문입니다.

현재의 서사로부터 누가 이득을 얻고 있을까요? 솔직히 말해서, 방어자를 제외한 모두입니다. 거부 반응을 보이는 모델의 벤더 (vendors)들은 자신들의 가드레일을 책임감 있는 AI (responsible AI)의 증거로 지목할 수 있습니다. 논평가들은 자극적인 지정학적 헤드라인을 얻습니다. 오픈 모델 (open-model) 옹호자들은 제한적인 라이선싱과 안전 연극 (safety theater)에 대한 논거를 얻습니다. 여기서 깨끗한 승리를 거두지 못한 유일한 집단은 사고 도중에 주요 도구를 우회해서 사용해야 했던 보안 팀입니다.

시사점

만약 당신이 현재 프런티어 모델을 기반으로 보안 워크플로우 (security workflows)를 구축하고 있다면, 실제 사고가 발생한 새벽 2시에 모델이 필요해지기 전에 당신의 자체 사고 대응 (IR) 플레이북 (playbooks)을 통해 모델을 실제로 테스트하라는 신호입니다. "안전 정렬 (safety-aligned)"이 "방어를 위해 사용하기에 안전함"으로 깔끔하게 번역된다고 가정하지 마십시오. 당신이 의존하려는 모델에 공격 로그, 멀웨어 샘플, 의심스러운 코드 스니펫 (code snippets)을 통과시켜 보고 모델이 어디에서 주춤하는지 확인하십시오. 실제 침해 사고 중에 발견하는 것보다 테이블탑 연습 (tabletop exercise) 중에 거부 경계 (refusal boundary)를 찾는 것이 훨씬 낫습니다.

모델 제공업체들에게 이것은 해결할 가치가 있는 진정한 설계 문제입니다. 방어 의도를 이해하는 문맥적 거부 (contextual refusal)는 있으면 좋은 기능 (nice-to-have)이 아니라, 보안 사용 사례를 대상으로 마케팅되는 모든 모델의 핵심 기능입니다. 그리고 업계 전반적으로, 이는 보안 도구링을 위한 멀티 모델 전략 (multi-model strategies)을 선택 사항이 아닌 기본값으로 추진하도록 우리를 독려해야 합니다. 사고 대응 (incident response)을 위해 하나의 모델 제품군에만 의존하는 것은 이제 단일 장애점 (single point of failure)임이 입증되었습니다.

미결 과제

모델 제공업체를 교체함으로써 안전 가드레일 (safety guardrails)을 안정적으로 우회할 수 있다면, 그것들이 정확히 무엇으로부터 보호하고 있는 것일까요? 그리고 "공격자가 벤더를 바꾸게 만드는 것"이 정말 우리가 구축하고자 하는 보안 경계 (security boundary)일까요?

— Cor E, Skyblue Soft

출처

• Hugging Face says it resorted to a Chinese AI model