# AI 시스템은 결코 완전히 안전하지 않다 — 대응해야 할 ‘치명적 삼중 위협’

> Clean Markdown view of GeekNews topic #23343. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=23343](https://news.hada.io/topic?id=23343)
- GeekNews Markdown: [https://news.hada.io/topic/23343.md](https://news.hada.io/topic/23343.md)
- Type: news
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-09-29T10:33:01+09:00
- Updated: 2025-09-29T10:33:01+09:00
- Original source: [economist.com](https://www.economist.com/science-and-technology/2025/09/22/why-ai-systems-may-never-be-secure-and-what-to-do-about-it)
- Points: 18
- Comments: 0

## Summary

대형 **LLM 에이전트**의 구조적 특성 때문에, **외부 콘텐츠 노출**, **사적 데이터 접근**, **외부 통신 가능**의 세 요소가 결합될 때, 소규모 실수도 치명적 **보안 사고**로 이어질 수 있는 **'치명적 삼합(lethal trifecta)'** 문제가 대두되고 있습니다. 최신 사례로 **Microsoft Copilot, DPD 챗봇, Notion AI** 등에서 실제 취약점이 확인되어, **분리 아키텍처**, **불신 모델 격리**, **통신 통제** 설계가 업계 표준으로 부상하고 있습니다. 업계에서는 기능 일부를 포기하고, 확률적 **안전 여유**를 내재한 소프트웨어 **아키텍처 변화**가 불가피할 수 있습니다.

## Topic Body

- 사용자의 어뷰징을 가능케 하는 “**치명적 삼합(lethal trifecta)**”에 대한 대응 방법  
- 자연어 지시를 그대로 따르는 **LLM 에이전트**는 **데이터·명령 분리 부재**로 인해 외부 텍스트 속 악성 지시까지 실행할 수 있는 구조적 취약성을 가짐  
- 외부 콘텐츠 노출, 사적 데이터 접근, 외부 통신 능력이 결합되는 **“치명적 삼합”** 이 형성되면 사소한 실수도 치명적 보안 사고로 비화할 위험이 증폭됨  
- 실제 사례로 **Microsoft Copilot의 취약점 패치(6월)**, **DPD 고객지원 봇의 오남용(2024년 1월)**, **Notion AI 에이전트의 PDF 기반 데이터 탈취 시연(9월 19일)** 등이 발생  
- 방어 원칙은 **삼합의 해체**와 **불신 모델 격리**, **통신 통제**이며, Google의 **CaMeL 이중 LLM 아키텍처**처럼 기능 제약을 감수한 안전 설계등을 제안  
- 업계는 학습 강화만으로 충분히 막기 어렵고, **MCP 플러그인 조합 위험**과 **제품 출시 지연(예: Apple의 AI 기능 연기)** 이 시사하듯 **확률적 안전 여유**를 전제로 한 설계 전환이 필요함  
  
---  
  
### 핵심 문제 정의: 데이터·명령 불분리와 “치명적 삼합”  
- LLM은 입력 텍스트를 연속 단어 예측으로 처리해 **질문에는 답변**, **명령에는 실행 시도**를 하는 **통합 해석 모델**임  
  - 외부 문서에 “하드디스크 복사 후 공격자 이메일로 전송” 같은 **악성 지시 삽입** 시 요약 작업 중 **부수 실행 위험** 발생임  
- **외부 콘텐츠 노출** + **사적 데이터 접근** + **외부로의 발신 경로**가 한 시스템에 공존하면 **치명적 삼합(lethal trifecta)** 이 성립함  
  - 치명적 삼합은 보안 연구자 **Simon Willison**이 제시한 개념으로, 세 요소 동시 개방 시 **남용 불가피성**이 커짐  
  
### 초기 징후와 현실 사례  
- 2022년 여름 **프롬프트 인젝션** 용어가 독립적으로 등장하며 **순치된 순응성**의 위험이 조명됨  
- 2024년 1월 **DPD**의 고객지원 봇이 **욕설 응답**을 따르는 문제가 확인되어 서비스 중단 사례 발생임  
- 2025년 6월 **Microsoft Copilot**에서 **삼합 취약점**이 발견되어 **조용한 패치**가 배포되었고, **실제 악용은 미보고**였다고 설명됨  
- 2025년 9월 19일 **Notion AI 에이전트**가 문서·DB·웹 접근을 갖춘 상태에서 **조작된 PDF로 데이터 탈취**가 연구자 **Abi Raghuram**에 의해 시연됨  
  
### 왜 차단이 어려운가: 확률적 실패와 우회 채널  
  
- 시스템 프롬프트로 **우선순위 규칙**을 부여해도 **100번 중 1번 실패**처럼 **확률적 미끄러짐**이 상존  
  - **“유해 신호 인지”** 등 안전 지침을 넣어도 **언젠가 통과**될 가능성 지속  
- 외부 통신 차단이 핵심이지만, **이메일 전송 금지**만으로는 부족하며 **URL 경로에 비밀값 인코딩** 등 **웹 요청 로그 유출**이 가능  
  - **웹 접근 허용 자체**가 **데이터 유출 경로**로 전환될 수 있음  
  
### 방어 전략 1: 삼합을 구성하지 않기  
- **한 요소라도 제거**하면 위험이 급감함  
  - 입력을 **내부 생성·검증된 소스**로 제한하면 **외부 노출** 제거 가능  
  - **코딩 보조**가 **신뢰 코드베이스**만 다루거나, **스마트 스피커**가 **음성 명령**만 처리하는 식의 **범위 축소** 전략 유효함  
- 그러나 이메일 관리 등 **본질적으로 외부 데이터**를 다루는 과제에서는 **완전 제거가 곤란**함  
  
### 방어 전략 2: 불신 모델 격리와 최소 권한  
- Google의 3월 논문은 외부 데이터에 닿은 모델을 **“불신 모델”로 분류**하고 **민감 정보 격리**를 권고함  
  - 이메일처럼 **사적이면서 외부 유입**이 있는 리소스는 **두 요소를 이미 충족**하여 **고위험 상태**가 됨  
- **권한 최소화**, **샌드박스**, **컨텍스트 경계**로 **사내 비밀·자격증명** 접근을 분리 관리함  
  
### 방어 전략 3: 모델 제약·아키텍처 분리  
- **훈련 데이터로 거부 패턴 강화**는 필요하지만 **충분 조건 아님**임  
- Google의 **CaMeL**은 **두 개의 LLM**을 사용해 역할을 분리함  
  - **신뢰 모델**이 사용자 자연어를 **제약된 코드**로 변환하고  
  - **불신 모델**은 **빈칸 채움**만 수행하는 **엄격 제약 흐름**을 통해 **보안 성질**을 확보함  
  - 대가로 **가능 작업 범위 축소**라는 **기능적 제약**을 수용함  
  
### 소비자·플러그인 생태계의 위험: MCP 사례  
- **Model Context Protocol(MCP)** 로 보조 앱을 추가하면 **능력 합성**으로 **우발적 삼합**이 형성될 수 있음  
  - 개별 MCP가 안전해도 **조합 안전성**이 깨질 수 있어 **설치 최소화·출처 검증**이 필요함  
  
### 산업계 신호: 출시 지연과 보수화  
- 2024년 **Apple**은 “**Jamie가 추천한 팟캐스트 재생**” 같은 기능을 예고했지만, **삼합 유발** 우려 속에 **출시 지연** 선택임  
- 2025년 9월 **iOS 최신판**에서도 **대형 AI 기능은 부재**, **번역·UI 개선** 위주로 선회했다는 점이 **현실적 난제**를 반영함  
  
### 실무 체크리스트: 무엇을 할 것인가  
- **위험 모델링**: 외부 입력, 민감 데이터, 외부 발신 중 **열린 요소를 명시**하고 **삼합 여부**를 지도화함  
- **경계 설계**: **불신 모델**은 **읽기 전용 버퍼**로 제한, **비밀·토큰은 별도 중계 서비스**로 우회, **직접 접근 차단**  
- **출구 봉쇄**: **이메일·웹 요청·파일 업로드** 등 **데이터 유출 채널**을 **허용 목록 기반**으로 제한함  
- **정책 엔진**: **허용된 도구 호출만** 실행, **자연어→정형 정책**으로 **명령 컴파일** 후 실행  
- **감사·가드레일**: **프롬프트 인젝션 테스트 세트**, **레드팀 자동화**, **세션 로깅·거부율 모니터링**으로 **확률적 실패**를 관리함  
- **기능 트레이드오프 수용**: **성능·자율성** 일부를 포기하고 **확률적 안전 여유**를 확보하는 **엔지니어링 문화 전환** 수용 필요성 제기  
  
### 결론  
- **삼합을 모두 연 상태**에서는 **취약점이 필연적으로 발견**된다는 경고가 축적됨  
  - **삼합 해체**, **불신 모델 격리**, **출구 통제**, **역할 분리 아키텍처**가 현재 가능한 **가장 현실적 처방**임  
  - 장기적으로는 **결정론 집착을 내려놓고 확률적 안전 여유를 설계에 내장**하는 **소프트웨어 공학적 전환**이 요구됨

## Comments



_No public comments on this page._