AI 에이전트의 보안은 호출하는 도구 및 에이전트의 보안 수준과 동일합니다

우리는 에이전트 자체를 강화하는 데 많은 노력을 기울입니다. 권한 범위를 설정하고, 코드 실행을 샌드박싱(sandboxing)하며, 출력을 모니터링합니다. 그러다 에이전트가 제3자 MCP 서버를 로드하면, 우리가 구축한 잠금 장치들을 우회하여 대부분의 작업이 이루어집니다.

이것은 아무도 자동화로 해결하지 못하는 에이전트 보안의 불편한 진실입니다: 당신의 에이전트는 그것이 호출하는 에이전트 및 도구만큼만 안전합니다. 에이전트는 제3자 도구를 로드하고, MCP 서버와 통신하며, 하위 에이전트(sub-agents)를 생성하고, 시스템 내의 다른 모든 에이전트와 기질(substrate) — 레지스트리(registry), ID 평면(identity plane), 게이트웨이(gateway), 킬 스위치 버스(kill-switch bus) — 을 공유합니다. 이 중 어느 하나라도 실패하면 그 실패는 그 자리에 머물지 않습니다. 공유된 기질을 통해 연쇄적으로 확산됩니다.

여기서 유용한 프레임워크를 제시하자면: 당신이 구축하는 모든 제어 장치는 두 가지 측면을 가집니다. 에이전트 범위(agent-scoped) 측면(이 에이전트가 무엇을 할 수 있는가)과 생태계 범위(ecosystem-scoped) 측면(모든 에이전트가 의존하는 공유 인프라)입니다. 대부분의 팀은 첫 번째 측면을 구축하고 두 번째 측면은 당연하다고 가정합니다. 구체적으로 살펴볼 가치가 있는 여섯 가지 사항은 다음과 같습니다.

1. 검증했던 도구가 나중에 적대적으로 변할 수 있습니다

MCP에 관한 가장 무서운 공급망(supply-chain) 사실은 승인이 영구적인 상태가 아니라는 점입니다. 2025년 9월, postmark-mcp npm 패키지는 평범해 보이는 업데이트를 배포했습니다. 무해한 버전과 악성 버전 사이의 유일하고 의미 있는 차이점은 단 한 줄의 추가된 코드였습니다: send-email 함수에 Bcc 필드가 추가되어, 모든 메시지를 공격자의 도메인으로 조용히 복사하는 것이었습니다. 자동 업데이트를 사용하는 모든 사용자는 행동의 가시적인 변화 없이 이메일이 유출되기 시작했습니다.

이것이 바로 **러그 풀(rug pull)**입니다: 월요일에는 검증되었지만, 목요일에는 적대적으로 변합니다. 버전을 고정(pinning)하고 서명하는 것이 도움이 되긴 하지만, 그것은 _무엇이 변했는지_를 알려주지는 않습니다. 이를 위해서는 승인 시점에 기록하고 로드할 때마다 재확인하는 지문(fingerprint) — 도구의 설명과 스키마(schema)의 해시(hash) 값 — 이 필요합니다. 지문이 변경되면 사람이 확인할 때까지 해당 도구의 작동이 중단됩니다. 계산 비용은 저렴하며, 조용한 러그 풀을 요란한 것으로 바꿔줍니다.

2. 도구 설명과 스키마는 신뢰할 수 없는 입력값입니다

사람들을 혼란에 빠뜨리는 세부 사항은 다음과 같습니다. 도구의 설명(description)과 파라미터 스키마(parameter schema)가 에이전트의 프롬프트(prompt)에 직접 주입된다는 점입니다. 이는 그것들이 단순한 문서가 아니라 하나의 지시 채널(instruction channel)이 된다는 것을 의미합니다. Invariant Labs는 작년에 이를 입증했습니다. 겉보기에는 무해해 보이는 도구의 설명에 데이터를 유출하라는 숨겨진 지시사항이 포함되어 있었습니다. 여기서 사용된 용어는 **도구 포이즈닝 (tool poisoning)**이며, 이는 단지 도구의 옷을 입은 프롬프트 인젝션 (prompt injection)일 뿐입니다.

따라서 도구 메타데이터를 다른 모든 적대적인 입력값과 동일하게 취급하십시오. 설명이 모델에 도달하기 전에 보이지 않는 유니코드(Unicode), 오른쪽에서 왼쪽으로 쓰는 오버라이드 문자 (right-to-left override characters), HTML 주석, base64/hex 블록, 그리고 역할 오버라이드 문구 ("이전 지시사항을 무시하십시오", "당신은 이제..." 등)가 있는지 스캔하십시오. 제어 문자(control characters)를 제거하십시오. 웹 양식에서 오는 문자열을 신뢰하지 않는다면, 도구 레지스트리(tool registry)에서 오는 문자열도 신뢰하지 마십시오.

3. 유사한 이름을 주의하십시오

악의적인 서버는 귀하의 실제 도구를 이길 필요가 없습니다. 그저 혼란스러울 정도로 유사한 이름을 가진 채 옆에 자리 잡기만 하면 됩니다. send_email 대 send_emai1과 같은 식입니다. 타이포스쿼팅 (Typosquatting)과 서버 간 이름 혼동을 통해 악성 도구가 신뢰할 수 있는 도구로 향하는 호출을 가로챌 수 있습니다. 거의 중복되는 도구 이름을 플래그(flag)로 표시하고, 모든 도구의 네임스페이스 (namespace)를 해당 도구를 게시한 서버의 검증된 ID로 지정하여, search라는 이름을 가진 두 도구가 결코 모호하지 않도록 하십시오.

4. MCP 경계에 페일 클로즈 (fail-closed) 게이트웨이를 배치하십시오

여기서 하나의 아키텍처 아이디어만 가져간다면, 바로 이것입니다. 모든 MCP 트래픽을 단일한 감사 가능한 초크 포인트 (choke point)를 통해 라우팅하십시오. 호출자를 인증하고, 호출과 응답을 스캔하며, 속도 제한 (rate-limits)을 적용하고, 감사 추적 (audit trail)을 기록하는 하나의 게이트웨이를 만드십시오. 그리고 어떠한 오류가 발생하더라도, **거부 (denies)**하십시오. "로그를 남기고 계속 진행"하는 것이 아닙니다. 거부하십시오. 페일 오픈 (fail open) 방식의 게이트웨이는 그저 지연 시간 (latency)을 늘릴 뿐입니다.

직접 규격을 발명할 필요는 없습니다. Microsoft의 공개된 MCP Security Gateway 규격은 정확히 이 패턴을 준수하도록 테스트된 구현체 중 하나이며, 직접 구축하더라도 합리적인 참조점이 될 수 있습니다.

5. 킬 스위치 (kill switch)는 하위 에이전트(sub-agents)까지 도달해야 합니다

대부분의 킬 스위치 (kill switch)는 부모 에이전트 (parent agent)를 중단시키고 종료를 호출합니다. 하지만 부모 에이전트가 하위 에이전트 (sub-agents)를 생성하고 도구 세션 (tool sessions)을 열어두었다면, 부모가 사라진 후에도 이들은 계속 실행됩니다. 즉, 자격 증명 (credentials)을 여전히 보유한 채 호출을 수행하는 고아 프로세스 (orphaned processes)가 남게 됩니다. 진정한 중단 신호는 모든 하위 에이전트와 도구 세션으로 전파 (propagates) 되어야 하며, 각 세션을 안전한 상태로 남겨두어야 합니다.

그리고 모든 안전 시스템과 마찬가지로, 실제로 작동하는지 테스트하지 않았다면 그것을 보유하고 있다고 할 수 없습니다. 훈련 시에 스위치를 당겨보고 하위 에이전트들이 실제로 중단되는지 확인하십시오.

적용 위치

검증 (vetting), 오염 (poisoning), 유사 모델 (lookalikes), 게이트웨이 (the gateway), 킬 스위치 (the kill switch)라는 이 다섯 가지 우려 사항은 에이전트 보안을 위한 오픈 프레임워크인 BRACE의 E (Ecosystem, 생태계) 계층에 해당합니다. 더 긴 버전을 원하신다면, 해당 가이드에서 기질 모델 (substrate model)과 에이전트 범위 (agent-scoped)/생태계 범위 (ecosystem-scoped)의 분리에 대해 더 심도 있게 다룹니다.

이 중 어느 것도 생소한 것이 아닙니다. 이는 우리가 이미 의존성 (dependencies)에 적용하고 있는 공급망 위생 (supply-chain hygiene) — 고정 (pin), 서명 (sign), 지문 인식 (fingerprint), 로드 시 검증 (verify on load) — 과 동일하며, 다만 그 대상이 모델과 대화할 수도 있는 새로운 종류의 의존성으로 향할 뿐입니다.

따라서 마지막으로 던질 질문은 이것입니다: 현재 여러분의 에이전트가 로드하는 MCP 서버와 도구들을 어떻게 검증하고 있습니까? — 그리고 만약 승인 후에 그중 하나가 변경된다면 이를 감지할 수 있습니까?