Search

AI 에이전트가 도구를 잘못 불러놓고 아닌 척 하고 있다… ‘툴 포이즈닝’ 보안 취약점 공식 제기

AI 에이전트가 도구를 잘못 부르고 있다… '툴 포이즈닝' 보안 취약점 공식 제기
AI 에이전트가 도구를 잘못 부르고 있다… '툴 포이즈닝' 보안 취약점 공식 제기

AI 에이전트가 외부 도구를 골라 쓸 때 ‘도구가 자기 설명대로 동작하는지’를 검증하는 절차가 사실상 존재하지 않는다는 사실이 드러났다. 벤처비트(VentureBeat)가 5월 10일 보도한 ‘AI 툴 포이즈닝(tool poisoning)’ 분석에서 지적된 내용이다.

문제의 출발은 단순하다. 오늘날 에이전트형 LLM은 작업을 수행하기 위해 공유 레지스트리에서 외부 툴을 검색하고 호출한다. 어떤 툴을 부를지 결정할 때 모델이 참조하는 것은 자연어 설명이다. ‘깃허브(GitHub) PR을 자동으로 리뷰합니다’, ‘재무 데이터를 안전하게 조회합니다’ 같은 한 줄짜리 메타데이터다. 문제는 그 설명이 실제 동작과 일치하는지 누구도 확인하지 않는다는 점이다.

벤처비트는 코사이(CoSAI) 시큐어 AI 툴링 저장소에 제출된 이슈 141번을 인용한다. 제보자는 ‘툴 레지스트리 포이즈닝’이 하나의 취약점이 아니라 도구 생애주기 단계별로 여러 개의 결함을 만든다고 지적했다. 이슈는 두 갈래로 나뉘어 다뤄지고 있다. 하나는 ‘선택 시점(selection-time)’ 위협으로 다른 도구로 위장하기, 메타데이터 조작 등이다. 다른 하나는 ‘실행 시점(execution-time)’ 위협으로 약속한 동작에서 벗어나기, 런타임 계약 위반 등이다.

기존 공급망 보안 통제는 이 문제를 못 잡는다. 코드 서명, SLSA, SBOM은 ‘아티팩트(코드 산출물)가 선언된 그대로인지’는 검증하지만, ‘행동(behavior)이 선언된 그대로인지’는 검증하지 않는다. AI 에이전트 시대 보안에 필요한 것은 후자, 즉 ‘행동 무결성’이다. 그러나 시장의 어떤 통제 수단도 행동 무결성을 표준 항목으로 다루지 않는다.

기사는 두 가지 1차 방어선을 제안한다. 첫째, 배포 시점에 엔드포인트 허용 목록(allowlist)을 강제하는 방식이다. 모든 툴이 외부에서 통신할 접점을 사전 선언하고, 프록시가 이 선언과 다른 요청을 차단한다. 둘째, 출력 스키마 검증이다. 툴이 반환하는 값이 선언한 형식과 일치하는지 자동으로 비교한다. 둘 다 새로운 인프라 없이 네트워크 사이드카로 구현이 가능하다는 점이 강조됐다.

이 이슈는 한국 기업에도 직접적인 영향이 있다. 클로드 코드, 커서(Cursor), 코파일럿(Copilot), 제미나이 코드 어시스트 등 한국 개발 조직이 도입을 검토하는 AI 에이전트는 모두 외부 MCP 서버나 툴 레지스트리를 호출한다. 사내 보안팀이 ‘AI 에이전트 행동 검증’을 정식 보안 체크리스트에 포함시킬 시점이 왔다.

자세한 내용은 VentureBeat에서 확인할 수 있다.

이미지 출처: 이디오그램 생성