#CaMeL
2개의 포스트
![[특집] 읽는 순간 조종당한다 — 프롬프트 인젝션, 55년 된 버그는 왜 AI에서 되살아났나](/_next/image?url=https%3A%2F%2Ffiles.core.today%2Fstorage%2Fcoredot%2Fpublic%2Fblog%2Fpi-cover.webp&w=3840&q=75)
[특집] 읽는 순간 조종당한다 — 프롬프트 인젝션, 55년 된 버그는 왜 AI에서 되살아났나
2026년 2월, 누군가 깃허브 이슈의 제목 칸에 문장 하나를 적었습니다. 그 문장을 읽은 AI 봇이 배포 자격 증명을 노출했고, 변조된 패키지가 8시간 동안 약 4,000번 설치됐습니다. 해킹 도구도 악성코드도 없었습니다. 글을 읽게 했을 뿐입니다. 이것이 프롬프트 인젝션입니다. 이 글은 이 문제의 뿌리를 1971년 휘파람으로 전화 교환기를 조종하던 '블루박스'와 1998년의 SQL 인젝션에서 찾고, 2022년 9월 이름이 붙던 순간부터 2026년까지의 공격과 방어를 따라갑니다. 전화망과 데이터베이스는 '명령과 데이터의 통로를 나누는' 것으로 문제를 끝냈는데, 왜 언어 모델에서는 그 해법이 통하지 않는지. 세 연구소가 함께 쓴 논문이 최신 방어 12종을 어떻게 90% 이상 뚫었는지. 그리고 '고칠 수 없다면 속았을 때 할 수 있는 일을 줄인다'는 설계 원칙이 무엇인지 정리합니다.
에이전트에게 열쇠를 줬더니 — AI 에이전트 보안과 '치명적 삼중주'의 시대
2025년 6월 EchoLeak은 이메일 한 통으로 마이크로소프트 365 Copilot에서 데이터를 빼냈다. 클릭도 필요 없었다. 그해 여름 Comet 브라우저는 레딧 댓글에 속아 계정을 넘겼고, npm 공급망 공격은 개발자의 Claude·Gemini·Amazon Q를 시켜 비밀 파일을 훔쳤다. 2026년 2월엔 개인 AI 에이전트 마켓에서 악성 스킬 수백 개가 발견됐고, 11월엔 국가 배후 조직이 AI에게 공격의 80~90%를 맡긴 첫 사례가 공개됐다. 왜 프롬프트 인젝션은 '패치'로 끝나지 않는가. Simon Willison의 '치명적 삼중주'로 원리를 설명하고, EchoLeak부터 GTG-1002까지 실제 사고를 짚고, CaMeL·계획-실행 분리 같은 방어 설계와 실무 체크리스트를 정리한다.