도구 설명(Tool Descriptions)이 이제 위협 벡터(Threat Vector)가 되었습니다. 이에 따라 행동하십시오.

Microsoft의 자체 사고 대응(Incident Response) 팀은 무언가를 파괴하거나 경고를 발생시키지 않고도, 에이전트가 행동하기 전에 읽는 도구의 _설명(description)_을 오염시킴으로써 AI 에이전트가 민감한 데이터를 유출하도록 조작할 수 있음을 방금 입증했습니다. 만약 이 사실이 당신의 에이전트 파이프라인(Agentic Pipeline)의 모든 계층을 재고하게 만들지 못한다면, 무엇이 그럴 수 있을지 모르겠습니다.

문맥: 알려진 문제 유형, 진정으로 새로운 공격 표면

프롬프트 인젝션(Prompt Injection)이라는 개념은 새로운 것이 아닙니다. 보안 연구원들은 신뢰할 수 없는 입력이 LLM의 컨텍스트 윈도우(Context Window)에 도달하는 위험성에 대해 몇 년 동안 외쳐왔습니다. 여기서 새로운 점은 구체적인 공격 표면(Attack Surface)입니다. 바로 MCP 도구 설명(MCP tool descriptions) — 에이전트에게 _도구가 무엇을 하는지, 어떻게 사용하는지_를 알려주는 메타데이터(Metadata)입니다.

Model Context Protocol (MCP)은 에이전트 시스템(Agentic Systems)이 조립되는 방식에서 점점 더 비중을 차지하고 있습니다. 도구들은 에이전트가 어떤 도구를 언제 호출할지 추론할 수 있도록 설명과 함께 등록됩니다. 해당 메타데이터는 설계상 신뢰할 수 있는 것으로 간주됩니다. 이는 사용자 제어가 아닌 인프라 수준의, 시스템의 "안전한" 부분이어야 합니다. 하지만 분명히, 안전하지 않습니다. 공격자가 도구 설명에 들어가는 내용을 영향을 미칠 수 있다면, 이후의 모든 에이전트 결정 과정에 조용히 실려 가는 지침을 심을 수 있습니다.

이는 AI 오케스트레이션(AI Orchestration)에 적용된 공급망(Supply Chain) 사고방식이며, 현재 에이전트 시스템을 구축하는 대부분의 팀은 이에 대해 전혀 고려하지 않고 있습니다.

하이프 체크(Hype Check): 과장된 것과 묻혀 있는 것

이러한 내러티브로부터 누가 이득을 얻는지 솔직하게 말해봅시다. 이런 종류의 발견을 발표하는 연구원들은 관심과 신뢰성, 그리고 컨퍼런스 강연 기회를 얻습니다. 그것이 발견 자체를 틀리게 만드는 것은 아닙니다. 이는 분명히 실재하며 입증되었습니다. 하지만 프레임(Framing)이 "우리가 또다시 신뢰 경계(Trust Boundaries)를 고려하지 않고 복잡한 시스템을 구축했다"라기보다는 "AI는 독보적으로 위험하다"라는 방향으로 흐르는 경향이 있다는 점은 주목할 가치가 있습니다.

과장되고 있는 부분: 참신함(novelty)입니다. 신뢰할 수 있는 메타데이터에 악의적인 지침을 주입하는 것은 우리가 수십 년 동안 소프트웨어 시스템에 해왔던 방식의 변형일 뿐입니다. 이는 새로운 기질(substrate)이지, 새로운 범주가 아닙니다.

과소평가되고 있는 부분 — 그리고 이 부분이 당신을 걱정시켜야 할 부분입니다 — 은 이것이 기본적으로 얼마나 탐지 불가능한가 하는 점입니다. Microsoft 연구진은 에이전트가 취하는 각각의 개별 행동이 일상적이고 규칙을 준수하는 것처럼 보인다고 명시적으로 밝히고 있습니다. 데이터 유출(exfiltration)은 유출처럼 보이지 않습니다. 그것은 일반적인 에이전트의 행동처럼 보입니다. 이것은 단순히 탐지 범위의 이론적인 공백이 아니라, 현재의 모니터링이 구축된 방식과 에이전트 시스템(agentic systems)이 실제로 작동하는 방식 사이의 근본적인 불일치입니다.

당신의 SIEM(Security Information and Event Management)은 인간이나 스크립트가 나쁜 짓을 하는 것을 포착하도록 설계되었습니다. 개별적으로는 합리적인 47가지 행동을 수행하여 집합적으로 당신의 민감한 데이터를 외부로 유출하는 AI 에이전트를 포착하도록 설계되지 않았습니다.

시사점: 개발자와 보안 팀이 실제로 들어야 할 내용

만약 당신이 오늘날 에이전트 파이프라인(agentic pipelines)을 구축하고 있다면 — 실제로 많은 이들이 그러하고 있습니다 — 여기서 얻는 교훈은 불편합니다: 오케스트레이션 계층(orchestration layer) 자체를 포함하여 스택의 어떤 계층도 암묵적으로 신뢰하지 마십시오.

도구 레지스트리(tool registries), 도구 설명(tool descriptions), 도구 메타데이터(tool metadata) — 이것들은 사용자 입력(user input)에 적용하는 것과 동일한 회의론으로 다뤄져야 합니다. 누가 여기에 쓸 수 있습니까? 누가 변경 사항을 감사(audit)합니까? 에이전트가 이를 소비하기 전에 무결성 검증(integrity verification)이 이루어집니까?

보안 팀의 경우, 모니터링의 공백이 진짜 비상사태입니다. 개별 행동 수준에서의 행동 분석(behavioral analysis)으로는 이러한 종류의 공격을 포착할 수 없습니다. 단순히 행동별 규칙 매칭(per-action rule matching)이 아니라, *에이전트 세션 전반의 패턴(patterns across agent sessions)*에 대한 가시성이 필요합니다. 이는 대부분의 기업이 현재 AI 관측성(AI observability)에 대해 생각하는 방식의 중대한 재편을 요구합니다.

개발자의 경우, 빠르게 움직이고 도구를 신속하게 연결하려는 본능 — 이는 MCP가 편의성 우선 설계로 적극 권장하는 것이기도 합니다 — 이 이제 보안 위생(security hygiene)과 직접적인 긴장 관계에 놓이게 되었습니다. 통합의 속도가 곧 공격 표면(attack surface)입니다.

그리고 모두에게 전합니다: 에이전트가 "규칙을 따르고 있다"는 이유만으로 안전하게 행동할 것이라는 가정은 이제 공식적으로 깨졌습니다. 공격자가 규칙 자체를 다시 쓸 수 있는 상황에서, 정의된 규칙에 대한 준수(Compliance)와 실제 안전(Safety)은 동일한 것이 아닙니다.

미결 과제 (The Open Question)

만약 각 개별 에이전트의 행동이 정당해 보이기 때문에 공격이 성공하는 것이라면, 의미 있는 탐지(detection)란 과연 어떤 모습이어야 할까요? 그리고 에이전트 기반 배포(agentic deployments) 속도가 보안 팀의 모니터링 능력을 앞지르기 전에, 보안 팀이 이를 구축해낼 것이라고 기대하는 것이 현실적일까요?

— Cor, Skyblue Soft

출처 (Sources)

• Microsoft Warns Poisoned MCP Tool Descriptions Can Make AI Agents Leak Data