에이전트 스택에는 1998년 문제가 있습니다

2026년 6월 마지막 주, AI 에이전트 도구를 겨냥한 작은 CVE 묶음이 떨어졌습니다. 그중 두 건은 같은 데스크톱 에이전트 클라이언트에서 나왔고, 둘 다 인가 결함이며, 한 건은 MCP OAuth 콜백 한복판에 자리 잡고 있습니다. 따로 읽으면 각각은 유지보수자가 주말이면 고칠 중간 심각도 버그입니다. 함께 읽으면 이 묶음은 신호이고, 그 신호는 구조적입니다. AI 에이전트 생태계는 스스로를 지킬 보안 문화를 쌓는 속도보다 빠르게 공격 표면을 쌓고 있습니다. 이는 특정 프로젝트의 도덕적 실패가 아닙니다. 안전하지 않은 기본값을 가진 언어가 주류가 되고, 자격 증명이 사방에 놓이고, 아무도 따라잡을 수 없는 속도로 설치 기반이 불어나던 1998년 무렵 웹이 놓였던 바로 그 상태입니다. 여러분의 키를 쥐고 여러분의 셸을 실행하는 도구들이 1998년의 보안 성숙도 그대로 2026년의 위협 모델 속으로 출시되고 있습니다.

TL;DR

• 인기 데스크톱 AI 에이전트 클라이언트인 Cherry Studio는 2026년 6월 29일 두 건의 CVE를 받았습니다. MCP OAuth 콜백 서버의 부적절한 인가 결함(CVE-2026-13524)과 preload API의 인가 우회(CVE-2026-13534)입니다.¹²
• 이 패턴은 앱 하나에 국한되지 않습니다. MCP 레퍼런스 도구 자체가 2025년에 심각한 원격 코드 실행 결함을 출시했습니다. CVSS 9.6의 mcp-remote(CVE-2025-6514), 그리고 CVSS 9.4의 Anthropic MCP Inspector(CVE-2025-49596)입니다.³⁴
• 에이전트 도구는 과거의 어떤 웹 앱보다 구조적으로 더 노출되어 있습니다. 자격 증명을 쥐고, 설계상 코드를 실행하며, 신뢰 경계(IDE, 셸, 브라우저) 뒤가 아니라 그 안에 앉아 있기 때문입니다.
• 이런 버그를 막을 지식은 이미 존재합니다. MCP 명세는 혼동된 대리인(confused deputy)과 OAuth 흐름이라는 공격 유형을 상세히 문서화하고 있습니다. 다만 빠르게 늘어나는 모든 통합에 그 지식을 적용하는 문화는 아직 퍼지지 않았습니다.⁵
• 1998년의 웹은 웜이 보안 부실의 대가를 비싸게 만든 뒤에야 성숙했습니다. 에이전트 생태계에는 아직 그에 상응하는 강제력이 없고, 지금 이런 버그를 찾아내는 바로 그 모델이 그 강제력이 될 물건을 쓸 수 있습니다.

클러스터를 구체적으로 보기

Cherry Studio는 “스마트 채팅, 자율 에이전트, 300개 이상의 어시스턴트를 갖춘 AI 생산성 스튜디오”를 표방하는 크로스 플랫폼 데스크톱 클라이언트로, Model Context Protocol 서버를 명시적으로 지원합니다. 이 글이 다루는 바로 그런 종류의 도구입니다. 여러분의 API 키를 중개하고, 로컬 통합을 실행하며, 여러분을 대신해 네트워크로 나가는 일반 사용자용 에이전트입니다.

2026년 6월 29일 VulDB는 이 클라이언트를 대상으로 두 건의 권고를 공개했습니다. CVE-2026-13524는 1.9.0부터 1.9.6까지의 버전에 걸쳐 MCP OAuth Local Callback Server, 파일 src/main/services/mcp/oauth/callback.ts에 존재하는 부적절한 인가 결함(CWE-285)입니다. 표현은 단순합니다. “The manipulation of the argument code leads to improper authorization.”(인자 code의 조작이 부적절한 인가로 이어진다) CVSS 3.1 점수는 5.6, 중간입니다.¹ CVE-2026-13534는 1.9.7 버전까지의 CherryIN preload API에 존재하는 인가 우회(CWE-639)로, 점수는 5.0입니다.² 어느 쪽도 헤드라인감은 아닙니다. 둘 다 모두에게 낯선 영역을 빠르게 지나가는 팀이 저지르는 조용한 인가 실수입니다.

결정적인 단서는 첫 번째입니다. MCP 클라이언트의 OAuth 콜백은 교과서적인 신뢰 경계입니다. 외부 인가 서버가 code를 여러분의 머신으로 돌려주고, 여러분의 머신이 그것을 신뢰할지 결정하는 지점이기 때문입니다. 이를 잘못 다루는 것은 낯설고 새로운 버그 유형이 아닙니다. MCP 명세의 보안 문서가 가장 많은 분량을 할애한 바로 그 문제입니다.

같은 기간의 인접한 CVE 두 건은 제외했습니다. 클러스터는 진짜여야 하기 때문입니다. CVE-2026-13533은 에이전트 프레임워크가 아니라 PHP 콘텐츠 관리 도구인 agentejo Cockpit CMS이고, CVE-2026-13543은 아예 검증되지 않았습니다. 부풀린 목록보다 확실한 사례 몇 개가 낫습니다.

에이전트 도구가 구조적으로 더 불리한 이유

1998년 무렵의 전형적인 웹 앱은 안전하지 않았지만 경계 뒤에서 살았습니다. 여러분이 그 안에 앉아 있지 않은 서버에서 돌았고, 피해 반경은 데이터베이스와 세션에 그쳤으며, 침해가 나면 공격자가 얻는 것은 그 앱의 데이터였습니다.

에이전트 도구는 이 기하 구조를 뒤집습니다. 여러분의 머신 위나 IDE 안에서 돌고, 클라우드와 저장소에 대한 장기 자격 증명을 쥐며, 익스플로잇이 아니라 핵심 기능으로서 코드를 실행합니다. 뒤에 숨을 경계가 없습니다. 도구 자체가 경계이고, 그 경계는 설계상 성기기 때문입니다.

Simon Willison은 2025년 6월 “lethal trifecta(치명적 삼요소)”라는 말로 이 위험을 정확히 짚었습니다. 에이전트는 “여러분의 비공개 데이터에 대한 접근”, “신뢰할 수 없는 콘텐츠에 대한 노출”, “외부와 통신할 수 있는 능력”이 그 데이터를 훔칠 수 있는 방식으로 결합될 때 악용 가능해집니다.⁷ 유능한 에이전트는 모두 기본적으로 세 가지를 다 갖추고 있습니다. 여러분의 비밀을 읽는 것도, 공격자의 영향을 받은 콘텐츠를 받아들이는 것도, 외부로 요청을 보내는 것도 버그가 아니라 기능이기 때문입니다. 이 삼요소는 예외적인 경우가 아닙니다. 기본 구성 그 자체입니다.

그것이 구조적 차이입니다. 1998년의 웹 앱은 경계 하나만큼의 데이터를 흘리도록 속아야 했습니다. 2026년의 에이전트는 유출 사슬에 필요한 모든 능력이 미리 배선된 채로 도착합니다. 악의적인 입력과 여러분의 자격 증명 사이에 남은 것은, 그 도구가 내부 신뢰 경계를 제대로 그었는지 여부뿐입니다. Cherry Studio의 콜백 버그는 그 경계 하나가 조금 잘못 그어졌을 때의 모습입니다.

MCP의 증폭

Model Context Protocol은 2026년 에이전트 스택의 결합 조직이며, 특정한 방식으로 공격 표면을 곱해 놓습니다. 모든 MCP 서버는 대개 빠르게 작성된 새로운 특권 통합이고, 모델이 그것을 호출할 수 있습니다. 하나 추가하는 데는 마찰이 없습니다. 하나 감사하는 데는 그렇지 않습니다. 통합의 설치 기반이 그 코드를 읽는 사람의 수를 앞지르고 있습니다.

레퍼런스 도구를 보면 이것이 취미 프로젝트만의 문제가 아님을 알 수 있습니다. 2025년 7월 JFrog는 CVE-2025-6514를 공개했습니다. Claude Desktop, Cursor, Windsurf가 사용하는 커넥터인 mcp-remote의 OS 명령 주입으로, 악성 서버가 OAuth 흐름 중에 조작된 authorization_endpoint URL로 발동시킵니다. 심각도는 크리티컬, CVSS 9.6입니다.³ 같은 달 Tenable은 CVE-2025-49596을 공개했습니다. Anthropic 자체 MCP Inspector의 9.4짜리 원격 코드 실행 결함으로, 인증 검사가 빠져 있어 악성 웹사이트가 로컬 포트에 닿고 DNS 리바인딩을 거쳐 임의의 명령을 실행할 수 있었습니다.⁴

이 글에 등장하는 네 건의 CVE 중 두 건은 MCP 도구의 OAuth 흐름 결함입니다. 하나는 콜백 서버, 다른 하나는 엔드포인트 탐색에 있습니다. 우연이 아닙니다. 에이전트 클라이언트의 OAuth는 반복해서 놓치는 경계이고, 명세도 그 점을 소리 내어 말합니다. 2025년 6월 18일자 MCP 보안 모범 사례 문서는 가장 긴 절을 “confused deputy problem(혼동된 대리인 문제)”에 할애하고, 프록시 서버가 클라이언트별 동의를 구현하고 OAuth state 파라미터를 검증하며 리디렉션 URI를 정확히 일치시켜야 한다고 규정합니다.⁵ Cherry Studio가 콜백 버그를 출시하기 1년 전에 나온 문서입니다. 간극은 지식이 아닙니다. 명세의 보안 부록과 지난 화요일에 작성된 평범한 통합 사이의 거리입니다.

프롬프트 인젝션은 이 증폭을 옛 웹이 겪은 그 무엇보다 질적으로 나쁘게 만듭니다. Willison은 2022년 9월 이 용어를 만들며 “I propose that the obvious name for this should be prompt injection”(이것의 명백한 이름은 프롬프트 인젝션이어야 한다고 제안합니다)이라고 썼습니다. SQL 인젝션에 빗댄 것으로, 신뢰된 지시와 신뢰할 수 없는 입력이 하나의 문자열로 이어 붙여지고 엔진이 그것을 해석하는 구조입니다.⁶ 에이전트에게는 코드뿐 아니라 데이터가 곧 벡터입니다. 오염된 웹 페이지, 함정이 설치된 파일, 적대적인 도구 설명. 모델이 읽는 모든 바이트가 지시를 실어 나를 수 있습니다. MCP 명세는 이 점을 직설적으로 밝히며, 악성 서버가 클라이언트를 데이터 유출의 프록시로 바꿔 놓을 수 있다고 경고합니다.⁵ 입력 이스케이프로는 이를 막을 수 없습니다. 입력은 자연어이고 해석기는 모델이기 때문입니다.

1998년 비유를 정확하게

비유는 팩트체크를 견디지 못하면 그저 분위기에 그칩니다. 그래서 그 시절을 정확하게 짚어 보겠습니다.

PHP 3는 1998년 6월에 출시되어 동적 웹 언어를 수백만 명의 손에 쥐여 주었습니다. 그 기본값은 지금 읽으면 무모하기 짝이 없습니다. 쿼리 문자열, 쿠키, 서버에서 온 외부 입력이 전역 스코프에 곧바로 등록되었습니다. register_globals가 켜져 있었고, 공격자가 통제하는 변수가 코드가 신뢰하는 변수로 조용히 바뀔 수 있었습니다. 고치는 데 4년이 걸렸습니다. 2002년 4월에 나온 PHP 4.2.0이 기본값을 바꾸었고, 릴리스 공지는 이를 담백하게 밝힙니다. “External variables (from the environment, the HTTP request, cookies or the web server) are no longer registered in the global scope by default.”(환경, HTTP 요청, 쿠키, 웹 서버에서 온 외부 변수는 더 이상 기본적으로 전역 스코프에 등록되지 않습니다)⁸ 그 시대를 규정한 또 하나의 목발인 magic quotes는 addslashes를 돌려 실체 없는 SQL 인젝션 안전성을 흉내 냈고, register_globals보다 몇 해를 더 살아남은 뒤에야 프로젝트에 의해 폐기되었습니다. 안전하지 않은 기본값, 안전하다는 착각, 그리고 문화가 따라잡기까지의 몇 년에 걸친 지연. 그것이 어린 웹의 애플리케이션 계층이었습니다.

문화는 저절로 오지 않았습니다. 강제된 것입니다. 2001년 7월 19일 Code Red 웜은 마이크로소프트 IIS 웹 서버의 버퍼 오버플로를 악용했고, CAIDA의 집계에 따르면 “more than 359,000 computers were infected with the Code-Red (CRv2) worm in less than 14 hours”(14시간이 채 되지 않아 35만 9,000대가 넘는 컴퓨터가 Code-Red(CRv2) 웜에 감염되었다)였습니다.⁹ 2003년 1월 25일 Sapphire/Slammer 웜은 Microsoft SQL Server의 버퍼 오버플로를 때렸고, 자신을 376바이트 패킷에 담았으며, “infected most of the vulnerable hosts that could be found within ten minutes”(10분 안에 찾을 수 있는 취약 호스트 대부분을 감염시켰다), 당시까지 역사상 가장 빠르게 퍼진 웜이었습니다.¹⁰ 이들은 PHP 버그가 아니라 인프라 웜이고, 저는 둘을 뒤섞지 않겠습니다. 요점은 그 10년의 형태입니다. 모든 계층에 걸친 안전하지 않은 기본값, 그리고 보안 부실이 피부에 와닿게, 또 공개적으로 비싸진 뒤에야 성숙한 보안 문화. 시큐어 바이 디폴트는 업계가 웜으로 값을 치르고 배운 교훈이었습니다.

이를 2026년에 겹쳐 보면 대응 관계가 불편할 만큼 잘 맞습니다. 안전하지 않은 기본값: 콜백 code를 신뢰하고 동의 확인을 건너뛰는 에이전트 클라이언트. 안전하다는 착각: admin:* 범위의 토큰 위에 얹은 권한 프롬프트. 폭발하는 설치 기반: 무엇에든 대응하는 MCP 서버가 클릭 한 번으로 추가되고 아무도 감사하지 않는 상황. 생태계에 아직 없는 것은 웜뿐입니다. 1998년의 기본값과 2001년의 표적 프로필을 갖춘 채, 강제력을 기다리고 있습니다.

운영자의 자세

문화를 기다릴 여유는 없습니다. 지금 이 도구들을 돌리는 사람은 여러분이므로, 생태계가 아직 그어 주지 않은 경계는 여러분이 긋게 됩니다. 제가 쓰는 틀은 삼요소를 운영 체크리스트로 바꾼 것입니다. 어떤 에이전트든 무엇을 읽을 수 있고, 무엇을 실행할 수 있으며, 무엇을 밖으로 내보낼 수 있는지 묻고, 각각에 결정론적 가드를 두십시오.

가드 열은 희망 사항이 아닙니다. 결정론적이고, 그 결정론이 핵심입니다. 훅은 라이프사이클 이벤트에서 발동하며 모델이 반박할 수 없는 종료 코드를 냅니다. 권한 규칙은 도구가 실행된 뒤가 아니라 실행되기 전에 평가됩니다. “에이전트는 X를 하면 안 된다”가 “에이전트는 X를 할 수 없다”로 바뀌는 계층이 바로 여기이고, 프롬프트 인젝션 페이로드가 말로 통과할 수 없는 유일한 계층이기도 합니다. 입력을 믿을 수 없고, 그 입력에 대해 모델이 스스로를 단속하리라고도 믿을 수 없다면, 모델이 통제하지 않는 경계에서 강제하는 수밖에 없습니다.

두 번째 통제는 생산성 기능처럼 읽히지만 실제로는 보안 기능입니다. 에이전트가 실행 전에 작업을 검토 가능한 계획으로 컴파일할 때, 그 계획을 검토하는 일은 보안 검토가 됩니다. 호출할 모든 도구와 건드릴 모든 파일을 적어 둔 40줄짜리 워크플로우 스크립트는 1분이면 읽는 위협 모델입니다. 만 번의 실시간 결정은 감사할 수 없지만, 그것들을 만들어 낼 계획은 아무것도 쓰이기 전에 감사할 수 있습니다.

그리고 비대칭성을 놓치지 마십시오. 이런 CVE를 만들어 내는 바로 그 능력이 그것을 찾아내기도 합니다. 어느 Anthropic 연구자는 코딩 에이전트와 열 줄짜리 스크립트로 23년 묵은 리눅스 커널 취약점과 22건의 Firefox CVE를 드러냈습니다. 여러분의 책상 위 도구는, 겨누기만 하면 자기 스택을 향하는 취약점 스캐너입니다. 방어자는 오늘 이미 발견을 자동화할 수 있고 지금 트리아지 계층을 만들고 있습니다. 그것이 1998년의 웹에는 없던 유일한 이점입니다.

8월 24일 업데이트: 발행 이후의 기록

이 글은 6월의 클러스터가 불운이 아니라 구조적 신호라고 주장했습니다. 그 뒤 7주간의 기록은 다음과 같습니다.

MCP의 롱테일은 꾸준한 CVE 흐름을 만들어 내고 있습니다. 8월 중순의 어느 한 주에 커뮤니티 MCP 서버 세 곳이 CVE를 받았습니다. Jij-MCP-Server의 Python REPL 코드 주입(CVE-2026-19964), android-mcp-server의 인자 조작을 통한 명령 실행(CVE-2026-19978), 그리고 mcp-florence2의 서버 사이드 요청 위조(CVE-2026-19984)입니다.¹¹¹²¹³ 모두 중간 심각도이며, 둘은 원격에서 발동 가능하고 나머지 하나는 에이전트가 도는 호스트 로컬에 한정됩니다. 그리고 전부 고전적인 유형인 인젝션, 정화되지 않은 실행, SSRF로, 에이전트의 권한으로 도는 도구에 떨어졌습니다. “MCP의 증폭” 절이 구조적이라고 주장했던 시나리오, 즉 저마다 잠재적 mcp-remote인 작은 통합들의 롱테일이 예정대로 도착한 것입니다.

커뮤니티 꼬리만의 문제가 아닙니다. 마이크로소프트의 자체 운영 에이전트인 Azure SRE Agent는 8월 7일 CVE-2026-62830을 받았습니다. 인가 누락으로 네트워크를 통한 권한 상승이 가능해지는 결함으로, 점수는 9.9 크리티컬입니다.¹⁴ 구조적 주장은 애초에 아마추어 유지보수자에 관한 것이 아니었습니다. 에이전트 도구가 무엇인가에 관한 것입니다.

공격 연구가 공급망을 따라잡았습니다. ElasticBack은 단 하나의 에이전트 스킬 문서에 심어진 조건부 백도어를 시연하며, 스킬을 “an emerging supply chain where a single poisoned skill can persistently compromise every agent that installs it”(오염된 단 하나의 스킬이 그것을 설치하는 모든 에이전트를 지속적으로 침해할 수 있는 신흥 공급망)이라고 규정했습니다.¹⁵ 그리고 배포에 대한 생태계의 답인 Agent Plugins 1.0은 권한과 출처를 클라이언트 관리에 맡긴 채 서명 계층은 아예 없이 출시되었습니다. 패키징 계층이 보안 계층보다 먼저 도착한 것이고, 이는 이 글이 스택 전체를 규정한다고 주장한 바로 그 순서입니다. 능력이 먼저 출시되고, 보안 문화가 뒤따릅니다.

아래의 전망은 손대지 않고 그대로 둡니다.

나의 입장

제가 생각하는 전개를, 틀릴 수 있을 만큼 구체적으로 적겠습니다. 에이전트 생태계는 보안 문화를 갖기 전에 Code Red의 순간을 맞이합니다. 웹이 그 순서로 겪었기 때문입니다. 강제력은 아마도 공유된 MCP 서버를 통해 에이전트 사이를 옮겨 다니는 자기 증식형 프롬프트 인젝션 페이로드이거나, 인기는 많지만 감사가 부족한 통합 하나로 거슬러 올라가는 대규모 자격 증명 유출 사건일 것입니다. 만드는 비용은 쌉니다. 커널 버그를 찾아내는 바로 그 모델이 그것을 쓸 수 있기 때문이고, “큰 물결이 온다”는 경고는 애초에 방어만의 이야기가 아니었습니다.

그것이 떨어진 뒤에는 시큐어 바이 디폴트가 선택 사항이 아니게 됩니다. MCP 클라이언트는 동의 대화상자를 기본으로 켜고, 토큰 대상을 검증하고, 일치하지 않는 리디렉션 URI를 거부하는 콜백을 갖춘 채 출시될 것입니다. PHP가 결국 register_globals를 끈 채로 출시한 것과 같은 방식입니다. 권한 계층은 옵트인에서 기본 거부로 옮겨 갑니다. 살아남는 통합은 명세의 보안 부록을 곧 명세로 대한 쪽입니다.

불편한 부분은 시간표입니다. 웹이 시큐어 바이 디폴트를 체화하는 데는 대략 1998년부터 2005년까지가 걸렸고, 웜과 웜 사이에는 생각할 시간이 몇 년씩 있었습니다. 에이전트 스택은 더 빠르게 누적됩니다. 개발자 한 명 한 명의 머신에 더 값진 표적이 놓여 있고, 공격자의 툴체인은 모델 세대마다 나아지기 때문입니다. 1998년 문제는 실재합니다. 남은 질문은 웜이 결말을 쓰기 전에 이 비유에 따라 움직일 것인가, 아니면 그 뒤일 것인가뿐입니다.

핵심 정리

• 모든 에이전트에 삼요소 감사를 실시하십시오. 각 도구가 무엇을 읽고, 실행하고, 밖으로 내보낼 수 있는지 적어 둔 다음, 각 행마다 결정론적 가드가 있는지 확인하십시오. 가드 없는 능력이 곧 여러분의 노출이며, 다음 페이로드가 떨어질 자리입니다.
• MCP 서버는 허용 목록으로 관리하고, 모든 명령 파라미터를 신뢰할 수 없는 실행으로 다루십시오. 통합을 추가하는 것은 클릭 한 번이지만 감사하는 것은 그렇지 않으므로, 등록은 검토된 목록으로 제한하십시오. 여기 나온 네 건의 CVE 중 두 건은 MCP 클라이언트의 OAuth 흐름 버그였습니다. 핸드셰이크는 형식이 아니라 경계입니다.
• 계획 시점을 검토 관문으로 만드십시오. 에이전트가 의도를 검토 가능한 계획으로 컴파일하게 하고, 실행 전에 그것을 위협 모델처럼 읽으십시오. 도구와 파일을 적어 둔 스크립트는 1분이면 감사할 수 있지만, 만 번의 실시간 도구 호출은 그렇지 않습니다.
• 스캐너는 먼저 자신에게 겨누십시오. 이런 CVE를 만들어 내는 능력이 그것을 찾아내기도 합니다. 다른 누군가가 여러분을 향해 돌리기 전에, 자신의 코드와 의존성에 에이전트 지원 보안 점검을 돌리십시오.

자주 묻는 질문

MCP 서버는 안전한가요?

기본적으로는 안전하지 않고, 일률적이지도 않습니다. MCP는 프로토콜이며 그 보안은 각 서버와 클라이언트가 어떻게 구현하느냐에 달려 있습니다. mcp-remote(CVSS 9.6)와 Anthropic MCP Inspector(CVSS 9.4)에 대한 2025년의 공개는 레퍼런스 도구조차 심각한 RCE 결함을 출시했음을 보여 줍니다.³⁴ 명세는 혼동된 대리인, 토큰 통과, SSRF, 로컬 서버 침해 같은 주요 공격 유형을 문서화하고 구체적인 완화책을 제시합니다.⁵ 각 서버를 특권 통합으로 다루십시오. 신뢰하거나 감사한 것만 돌리고, 명시적으로 허용 목록에 넣고, 연결하는 어떤 서버든 여러분의 에이전트에 영향을 줄 수 있다고 가정하십시오.

프롬프트 인젝션이란 무엇인가요?

프롬프트 인젝션은 공격자가 AI 시스템이 읽는 신뢰할 수 없는 입력에 지시를 몰래 끼워 넣고, 모델이 그것을 여러분에게서 온 것처럼 따르는 상황을 말합니다. Simon Willison은 2022년 9월 SQL 인젝션에 빗대어 이 용어를 만들었습니다. 신뢰된 지시와 신뢰할 수 없는 입력이 하나의 프롬프트로 이어 붙여지고 모델이 그것을 해석하는데, 어느 쪽이 공격자의 것인지 확실히 가려낼 방법이 없습니다.⁶ 에이전트에게 특히 위험한 이유는 데이터가 곧 벡터가 되기 때문이고, 해석기가 언어 모델인 이상 이스케이프로는 고칠 수 없기 때문입니다.

치명적 삼요소란 무엇인가요?

2025년 6월 Simon Willison이 붙인 이름으로, 함께 모이면 에이전트를 악용 가능하게 만드는 세 가지 능력을 가리킵니다. 여러분의 비공개 데이터에 대한 접근, 신뢰할 수 없는 콘텐츠에 대한 노출, 그리고 외부와 통신할 수 있는 능력입니다.⁷ 세 가지를 모두 갖춘 에이전트는 주입된 콘텐츠에 조종당해 여러분의 비밀을 읽고 공격자에게 실어 보낼 수 있습니다. 유능한 에이전트 대부분이 기본적으로 세 가지를 갖추고 있으므로, 모델이 버텨 주기를 바라기보다 능력마다 가드를 두는 것이 정석입니다.

제 머신에서 도는 에이전트는 어떻게 보호하나요?

모델이 통제하지 않는 경계에서 시작하십시오. 도구가 실행되기 전에 평가되는 권한 규칙과 훅을 사용하면, 침해된 프롬프트가 아무리 말을 붙여도 여러분이 금지한 동작에는 이르지 못합니다. 도구와 MCP 서버를 허용 목록으로 관리하고, 새 로컬 서버가 실행되기 전에 동의를 요구하고, 모든 자격 증명의 범위를 최소 권한으로 좁혀 탈취된 토큰의 피해 반경을 작게 유지하십시오. 유출 경로를 닫기 위해 사설 및 링크 로컬 IP 대역으로 나가는 요청을 차단하십시오. 그런 다음 큰 작업 전에는 에이전트의 계획을 검토하십시오. 읽기 경계를 통과한 인젝션이 거기서 잡힙니다.

출처