최근 두 사건이 같은 신호를 보냈습니다.

ChatGPT가 구글 시트를 연동하는 기능을 열자마자, 외부 셀에 숨겨둔 인젝션 명령이 대화 내용을 제3자 URL로 전송했습니다. 같은 시기, 구글은 자사 에이전트 플랫폼 Agent Smith에서 서비스 간 직접 API 호출 범위를 제한했습니다.

두 회사가 택한 방향은 다르지만, 이유는 같습니다. 도구를 연결하는 순간 공격면이 열린다는 사실을 확인했기 때문입니다.

키워드 필터는 이미 뚫렸습니다

에이전트 보안을 “나쁜 단어를 거르는 것”으로 정의하면, 이미 진 싸움입니다.

HEARTBEAT 보안 우회 사례가 그 증거입니다. 차단 목록에 등록된 단어를 파일명 안으로 옮겨 HEARTBEATa.md 형태로 실행하면 키워드 필터는 통과됩니다. 공격자가 파일명을 한 글자 바꿨을 뿐인데, 패턴 매칭 방어가 무력화됩니다.

arXiv에 발표된 SkillHarm 연구는 이 문제를 공급망 단위로 확장합니다. 에이전트에 외부 스킬, 플러그인, MCP 서버를 붙이는 순간 그 스킬 자체가 공격 벡터가 됩니다. 스킬이 어떤 데이터에 접근하고 어디로 콜을 보내는지 추적하지 않으면, 사용자가 모르는 사이에 정보가 외부로 나갑니다.

이건 모델의 문제가 아닙니다. 연결 구조의 문제입니다.

에이전트가 “실행”하는 순간, 보안 책임이 이동합니다

기존 웹 보안에서는 입력 검증이 핵심이었습니다. 사용자가 무엇을 넣는지 제어하면 됐습니다.

에이전트는 구조가 다릅니다. 에이전트는 외부 문서를 읽고, API 응답을 받고, 그 내용을 다음 행동의 입력으로 씁니다. ChatGPT Sheets 사건에서 공격은 사용자가 아니라 문서 안에서 시작됐습니다. 에이전트가 셀 내용을 시스템 명령과 동일한 신뢰 수준으로 처리했기 때문입니다.

이 패턴은 이미 확장되고 있습니다. MCP(Model Context Protocol)를 통해 에이전트가 연결하는 서버가 늘어날수록, 신뢰 경계를 어디서 끊을지 명시하지 않으면 공격 표면도 함께 넓어집니다.

Anthropic의 Dario Amodei가 반복해서 말하는 이유가 있습니다. “사이버는 AI가 만드는 가장 명확하고 현재적인 위험이다.” 이 말은 프런티어 모델의 이야기가 아닙니다. 오늘 배포하는 에이전트의 이야기입니다.

설계로 풀어야 할 세 가지

에이전트 보안은 출시 후 덧붙이는 옵션이 아닙니다. 연결 구조를 설계하는 단계에서 결정해야 합니다.

첫째, 최소 권한을 기본값으로. 에이전트가 실제로 필요한 도구에만 접근하게 합니다. 구글 시트를 연결한다면, 특정 파일 읽기만 허용할지 전체 드라이브를 열어줄지 명시해야 합니다. “일단 전부 연결”은 없습니다.

둘째, 입력 신뢰 레이어를 분리. 사용자 메시지, 도구 응답, 외부 문서는 각각 다른 신뢰 레벨로 처리합니다. 외부 문서의 텍스트가 시스템 프롬프트와 동일한 권한을 갖는 순간 인젝션 경로가 생깁니다.

셋째, 감사 가능한 실행 로그. 에이전트가 어떤 도구를 호출했고, 어떤 데이터를 읽었는지 추적할 수 있어야 합니다. 인시던트가 발생했을 때 “어디서 새어 나갔는지 모른다”는 상황은 운영 단계에서 치명적입니다.

오픈소스 보안 테스트 프레임워크 Crucible은 90개의 적대적 공격 시나리오를 62초 만에 테스트합니다. OWASP Agentic AI Top 10 매핑도 포함돼 있습니다. 기술은 있습니다. 설계 우선순위가 없는 것입니다.

에이전트에 도구를 붙이는 행위는 기능을 추가하는 것이 아닙니다. 신뢰 경계를 확장하는 것입니다.

지금 배포 중인 에이전트가 연결하는 도구들 — 각각 어떤 데이터에 닿고, 어디로 콜을 보내는지 설명할 수 있습니까?