아무도 듣고 싶어 하지 않는 사실이 하나 있습니다. 우리는 구성 요소들이 서로의 출력을 맹목적으로 신뢰하는 시스템을 어떻게 망가뜨리는지 이미 알고 있습니다. 우리는 25년 동안 그것을 알고 있었습니다. 단지 새로운 이름을 붙였을 뿐이며, 교훈은 잊어버렸습니다.

문맥 (Context)

"AI 하네스 (AI harness)"는 오케스트레이션 접착제 (orchestration glue)입니다. LLM을 가져와서, 실제로 무언가를 수행할 수 있도록(데이터베이스 쿼리, API 호출, 파일 쓰기 등) 다양한 커넥터(connectors), 플러그인(plugins), 도구 호출 스캐폴딩(tool-calling scaffolding)으로 감싸면 그것이 바로 하네스가 됩니다. Dark Reading의 기사는 이를 소리 내어 말하면 구조적으로 명백한 점을 지적합니다. 이러한 구성 요소들은 신뢰 경계 (trust boundaries)의 체인을 형성하며, 그중 상당수는 바로 옆의 구성 요소가 전달하는 내용을 검증하지 않습니다.

이 문장이 데자뷔를 느끼게 한다면, 당연한 것입니다. 역직렬화 버그 (Deserialization bugs), 내부 서비스 호출을 통한 SSRF, "신뢰할 수 있는" 업스트림 파서 (upstream parser)를 통한 XML 엔티티 주입 (XML entity injection) — 애플리케이션 보안 (appsec)의 역사는 구성 요소 A가 구성 요소 B가 이미 검증을 마쳤을 것이라고 가정해 온 역사입니다. 우리는 새로운 아키텍처 패턴이 위협 모델링 (threat-modeling)이 되기도 전에 실제 운영 트래픽을 끌어들일 만큼 뜨거워질 때마다 이 패턴을 계속해서 재발견하고 있습니다.

새로운 점은 신뢰 경계 문제가 아닙니다. 새로운 점은 체인의 중간에 앉아 있는 것이 자신의 입력값에 의해 이상한 일을 하도록 유도될 수 있는 확률적 텍스트 생성기 (probabilistic text generator)이며, 이제 이것이 도구 실행 (tool execution)에 직접 연결되어 있다는 것입니다.

하이프 체크 (Hype check)

과장된 부분: 이것이 AI 전용 방어 체계를 필요로 하는 어떤 새로운 AI 특화 공격 클래스(exploit class)라는 프레임입니다. 그렇지 않습니다. 이것은 LLM의 탈을 쓴 통합 보안 (integration security) 문제입니다. 검증 없이 구성 요소 간에 데이터를 전달하는 플러그인과 커넥터가 존재하는 순간, 암묵적 신뢰 (implicit trust)를 가진 임의의 마이크로서비스 (microservices) 세트를 결합할 때 발생하는 것과 동일한 문제에 직면하게 됩니다. 공격 표면 (attack surface)은 오래된 뉴스이며, 새로운 것은 페이로드 전달 메커니즘 (payload delivery mechanism, 프롬프트 기반 도구 호출)입니다.

과소평가되고 있는 점은, 기본적인 구성 요소 경계 위협 모델링 (component-boundary threat modeling)을 수행하는 사람 없이 얼마나 빠르게 하네스(harnesses)가 배포되고 있는가 하는 점입니다. 왜냐하면 모두가 에이전트(agent) 주변의 배관(plumbing)이 아니라 에이전트 자체를 출시하기 위해 경주하고 있기 때문입니다. 경쟁사가 화려한 데모를 출시하는 동안, 도구 호출 (tool calls) 사이의 스키마 검증 (schema validation)에 3번의 스프린트(sprint)를 소비한 팀이 되고 싶은 사람은 아무도 없습니다. 그러한 압박은 실재하며 사라지지 않을 것입니다.

이것을 완전히 새로운 AI 위협 카테고리라고 부르는 것에서 누가 이득을 얻을까요? 솔직히 말해서, 무언가를 판매하는 모든 이들입니다. 벤더(Vendors)들은 새로운 긴급성 서사를 얻고, "2015년에 말씀드린 대로 인터페이스를 그냥 검증하세요"라고 말하는 대신 새로운 도구를 제안할 명분을 얻습니다. 보안 팀은 "SDLC 위생을 개선하십시오"라는 말보다 정당화하기 쉬운 예산 항목을 얻게 됩니다. 지루하지만 진실된 답변, 즉 "다른 다중 구성 요소 분산 시스템 (multi-component distributed system)에 적용하는 것과 동일한 엄격함을 적용하고, LLM의 출력이 경계를 넘을 때마다 그것을 신뢰할 수 없는 입력 (untrusted input)으로 취급하라. 왜냐하면 그것은 실제로 그렇기 때문이다"라는 답변으로부터는 아무도 이득을 얻지 못합니다.

시사점 (Implications)

만약 당신이 하네스를 구축하거나 배포하고 있다면, 실질적인 교훈은 결코 화려하지 않습니다. 오케스트레이터 (orchestrator), 커넥터 (connector), 그리고 플러그인 (plugin) 사이의 모든 단계는 인터페이스이며, 인터페이스에는 계약 (contracts)이 필요합니다: 스키마 검증 (schema validation), 출력 정화 (output sanitization), 그리고 각 도구 호출이 실제로 수행할 수 있도록 허용된 최소 권한 범위 지정 (least-privilege scoping) 등이 그것입니다. LLM이 그렇게 말했다는 이유만으로 플러그인의 출력이 다른 도구의 실행 컨텍스트 (execution context)로 직접 전달되게 두지 마십시오. 그것은 AI 안전 (AI-safety) 문제가 아니라, 신뢰할 수 없는 입력의 출처가 양식 필드 (form field) 대신 LLM인 입력 검증 (input-validation) 문제입니다.

보안 팀에게 이것은 "모델이 정렬(aligned)되었다"와 "파이프라인이 안전하다"는 완전히 다른 두 가지 주장이며, 현재 많은 조직이 첫 번째 것만을 확인하고 있다는 점을 상기시켜 줍니다. 모델의 출력을 레드팀 (red-teaming) 하는 것보다, 모델이 무언가를 생성하여 다음 순서의 구성 요소로 전달한 이후에 어떤 일이 발생하는지를 레드팀 하는 것이 더 중요합니다.

산업 전반적으로 보자면: 하네스(Harness) 아키텍처는 구성 요소들이 서로를 어떻게 인증(Authenticate)하거나 검증(Validate)해야 하는지에 대한 공유된 표준이 생겨나는 속도보다 더 빠르게 확산되고 있습니다. 그것이 실제적인 격차(Gap)입니다. 신뢰 경계(Trust boundaries)가 존재한다는 인식이 부족한 것이 아니라, 이 특정 스택에서 이를 검증하는 것이 구체적으로 어떤 모습이어야 하는지에 대한 합의가 부족한 것입니다.

미결 과제 (Open question)

소프트웨어 구성 요소 간의 암묵적 신뢰(Implicit trust)에 대해 지난 20년 동안 혹독한 교훈을 얻었음에도 불구하고, 왜 모든 새로운 아키텍처 패턴은 누군가가 이를 적용하기 전까지 5년의 유예 기간을 거쳐야만 합니까?

— Cor, Skyblue Soft

출처 (Sources)

• AI Harnesses Burst With Potential Exploit Opps