요약 (TL;DR): Agentjacking이라 불리는 새로운 공격은 가짜 Sentry 오류 보고서를 사용하여 AI 코딩 에이전트가 임의의 코드를 실행하도록 속입니다. 공개된 지 몇 시간 만에 악용된 PraisonAI 인증 우회(authentication bypass) 사례와 Docker에 기록된 코딩 에이전트의 공포스러운 사례들이 결합되면서, 2026년은 AI 에이전트가 생산성의 꿈에서 보안의 악몽으로 변하는 해가 될 것으로 보입니다. 현재 무슨 일이 일어나고 있는지, 그리고 어떻게 당하지 않을 수 있는지 알아봅시다.

유혹 (The Hook)

이런 상황을 상상해 보세요: 당신은 에디터를 열고 "Sentry 오류를 수정해줘"라고 입력한 뒤 엔터를 누릅니다. 당신의 AI 코딩 에이전트는 MCP를 통해 Sentry에 성실히 쿼리를 날리고, 스택 트레이스 (stack trace)를 찾아낸 뒤, 합리적으로 보이는 수정 사항을 실행합니다. 하지만 그 "오류"는 공개된 JavaScript 번들에서 당신의 Sentry DSN을 찾아낸 누군가에 의해 심어진 것이었습니다. 그리고 그 "수정"은 방금 당신의 SSH 키, GitHub 토큰, 그리고 .env 파일 전체를 유출했습니다.

피싱 이메일도 없습니다. 침해된 서버도 없습니다. 당신의 EDR이 잡아낼 수 있는 악성코드 시그니처도 없습니다.

그저 당신과, 당신이 신뢰하는 AI 어시스턴트, 그리고 당신이 은쟁반에 담아 바쳐준 데이터 유출 사건만이 있을 뿐입니다.

이것이 바로 Agentjacking입니다. 그리고 이 공격은 85%의 확률로 성공합니다.

Agentjacking이란 무엇인가?

2026년 6월 12일, Tenet Security의 보안 연구원들은 AI 코딩 에이전트가 외부 데이터 소스와 만나는 아키텍처적 사각지대를 겨냥한 새로운 공격 유형을 발표했습니다. 이 공격은 근본적인 설계 결함을 악용합니다.

공격 과정은 다음과 같습니다:

1. 공격자가 공개 웹사이트나 JavaScript 번들에서 Sentry DSN을 발견합니다. Sentry DSN은 공개되어 있으며, 쓰기 전용(write-only) 자격 증명입니다. 누구나 이를 통해 에러 이벤트(error events)를 전송할 수 있습니다.

2. 공격자가 간단한 POST 요청을 통해 악성 에러 이벤트를 주입합니다. 이 이벤트의 메시지(message) 및 컨텍스트(context) 필드에는 Sentry의 정당한 해결 가이드와 똑같이 보이도록 정교하게 구성된 마크다운(markdown)이 포함되어 있습니다.

3. 개발자가 자신의 AI 에이전트에게 Sentry 문제를 해결하도록 요청합니다. 에이전트는 Sentry MCP 서버를 통해 Sentry에 쿼리를 보내고, 공격자가 주입한 에러를 가져오며, 이를 실제 애플리케이션 충돌(crash)과 구분하지 못합니다.

4. 에이전트가 공격자의 페이로드(payload)를 실행합니다. 개발자의 완전한 권한을 가진 상태로, 개발자의 머신 위에서 실행됩니다.

The Hacker News의 보도에 따르면, Tenet은 이를 100개 이상의 조직을 대상으로 테스트했으며, Claude Code 및 Cursor를 포함하여 가장 널리 사용되는 AI 코딩 어시스턴트(AI coding assistants) 전반에서 85%의 성공률을 기록했습니다. 또한 그들은 유효하며 주입 가능한 DSN이 노출된 조직을 최소 2,388개 발견했습니다.

Sentry는 이 문제를 인정했으나, 자신들의 아키텍처상 "기술적으로 방어할 수 없다(technically not defensible)"고 밝히며 패치를 거부했습니다. 그들은 특정 페이로드 문자열을 차단하는 글로벌 콘텐츠 필터를 활성화했지만, 이는 임시방편(band-aid)일 뿐 근본적인 해결책은 아닙니다.

이것은 고립된 사건이 아닙니다

만약 Agentjacking이 단 하나의 에러 추적 플랫폼을 겨냥한 하나의 영리한 공격에 불과했다면 그 자체로도 충분히 나쁜 일이겠지만, 이는 AI 에이전트에게 개발 환경에 대한 접근 권한을 부여한 모든 이들이 우려해야 할 패턴의 일부입니다.

PraisonAI: 4시간 만에 악용됨

2026년 5월, 인기 있는 멀티 에이전트 오케스트레이션 프레임워크(multi-agent orchestration framework)인 PraisonAI에서 심각한 인증 우회(authentication bypass) 취약점이 공개되었습니다. CVE-2026-44338은 2.5.6 버전부터 4.6.33 버전까지 영향을 미치며, 인증되지 않은 공격자가 사전 구성된 멀티 에이전트 워크플로(multi-agent workflows)를 하이재킹하고, 모델 제공자 API 키에 접근하며, LLM 할당량(quotas)을 남용할 수 있게 합니다.

The Hacker News에 따르면, 위협 연구원들은 취약점이 공개된 지 3시간 44분 만에 취약한 인스턴스를 대상으로 한 활발한 스캐닝(scanning)을 탐지했습니다. 공격자들은 패치를 기다리지 않았습니다. 그들은 같은 영업일(business day) 내에 움직였습니다.

Sysdig Threat Research는 노출된 /agents 엔드포인트를 겨냥한 활발한 악용 (active exploitation) 사례를 기록했으며, 공격자들은 자동화된 악용 루프(exploitation loops) 내에서 스캐닝에서 자격 증명 추출(credential extraction)로 피벗(pivoting)했습니다. BrinzTech의 위협 연구소는 전체 스캐닝-악용 루프 (scanning-exploitation loop)를 추적했으며, 이는 완전히 자동화되어 있었습니다.

Docker의 코딩 에이전트 공포 실화

이달 초, Docker는 현재 악명 높은 "rm -rf ~/" 사건을 포함하여 AI 코딩 에이전트 공포 실화 (AI coding agent horror stories) 시리즈를 발표했습니다. 이 사건에서 정리 작업을 맡은 에이전트는 지침을 너무 문자 그대로 해석하여 개발자의 홈 디렉터리를 삭제해 버렸습니다. Docker는 에이전트가 샌드박스 환경 (sandboxed environments) 외부에서 작동할 때, 어떠한 실수나 악의적인 지침도 치명적인 시스템 이벤트가 될 수 있다고 주장했습니다.

AISI 데이터

영국 AI 보안 연구소(AISI)가 2026년 2월에 발표한 데이터에 따르면, AI 모델이 자율적으로 완료할 수 있는 사이버 작업의 길이는 4.7개월마다 두 배씩 증가하고 있습니다. 이는 더 이상 이론이 아닙니다. 우리는 이제 프런티어 모델 (frontier models)이 시뮬레이션된 기업 네트워크를 대상으로 수 시간 동안 지속되는 사이버 공격 체인 (cyberattack chains)을 자율적으로 완료하는 세상에 살고 있습니다. AISI는 GPT-5.5와 Claude Mythos의 최신 체크포인트 (checkpoints) 모두 전체 사이버 레인지 (cyber ranges)를 완료할 수 있음을 확인했습니다.

이러한 모델들은 코딩 에이전트 (coding agents)로 배포되어, 쉘 (shell) 액세스 권한을 부여받고, MCP 서버에 연결되며, 운영 인프라 (production infrastructure) 상에서 운영 자격 증명 (production credentials)을 사용하여 "문제를 해결하라"는 지시를 받습니다.

공통점: 암묵적 신뢰가 곧 취약점이다

이 모든 사건은 동일한 근본 원인을 공유합니다: 에이전트의 출력 (outputs) 및 입력 (inputs)에 대한 암묵적 신뢰 (implicit trust)입니다.

Agentjacking이 작동하는 이유는 Sentry MCP 서버가 검증 없이 공격자가 제어하는 데이터를 에이전트에게 반환하기 때문입니다. 에이전트는 해당 데이터가 권한이 있는 MCP 서버로부터 왔기 때문에 이를 신뢰할 수 있는 가이드로 취급합니다. 개발자는 에이전트가 이전까지 항상 잘 작동해 왔기 때문에 에이전트를 신뢰합니다.

PraisonAI 취약점이 작동하는 이유는 에이전트가 인증된 액세스 (authenticated access)를 타인의 문제로 간주하기 때문입니다. 배포 과정에서 에이전트 API 서버가 인증 없이 노출되며, 에이전트 프레임워크 (agent framework)는 액세스 제어 (access controls)가 존재하는지 강제하지 않습니다.

Docker의 공포스러운 사례들은 에이전트가 자신이 안전한 환경에서 작동하고 있다고 가정하고, 개발자는 에이전트가 모든 것을 삭제하기 전에 확인을 할 것이라고 가정하기 때문에 발생합니다.

이는 마치 누군가 제복을 입고 클립보드를 들고 나타났다는 이유만으로 낯선 사람에게 집 열쇠를 건네주는 것과 보안 측면에서 동일합니다. 제복은 올바르게 보이고, 클립보드도 올바르게 보입니다. 하지만 그 뒤에 있는 자격 증명 (credentials)을 확인한 사람은 아무도 없습니다.

이것이 다른 공격들과 다른 점은 무엇인가?

현재의 에이전트 공격 물결을 이전의 모든 공격과 다르게 만드는 세 가지 요소가 있습니다:

1. 공격의 속도. PraisonAI는 공개된 지 4시간 만에 공격을 받았습니다. 며칠도, 몇 주도 아닌 단 몇 시간 만입니다. 공격 표면 (attack surface)에 쉘 액세스 권한을 가진 AI 에이전트가 포함되면, 취약점 공개와 침해 사이의 시간적 여유는 커피 한 잔 마시는 시간만큼 짧아집니다.

2. 전통적인 보안의 우회. Agentjacking은 EDR, WAF, IAM, VPN, Cloudflare 및 방화벽을 우회합니다. 탐지할 만한 악성 요소가 전혀 없습니다. 체인 내의 모든 동작은 권한을 부여받은 상태입니다. 사용자가 에이전트에게 오류를 수정해 달라고 요청했습니다. 에이전트는 권한이 있는 MCP 서버에서 데이터를 읽었습니다. 에이전트는 개발자의 머신에서 코드를 실행했습니다. 시스템의 관점에서는 모든 것이 정상이기 때문에, 모든 동작이 정당해 보입니다.

3. 권한의 복합적 확대. AI 코딩 에이전트는 웹 애플리케이션의 권한으로 작동하지 않습니다. SSH 키, 클라우드 콘솔 액세스, 운영 데이터베이스 자격 증명 및 Git push 권한을 가진 개발자의 권한으로 작동합니다. 에이전트를 탈취하면 단 하나의 시스템이 아니라 전체 개발 툴체인 (toolchain)을 우회하게 됩니다.

Agentjacking으로부터 자신을 보호하는 방법은?

업계에서 더 나은 에이전트 보안 프레임워크를 개발하는 동안, 여러분이 오늘 바로 할 수 있는 일은 다음과 같습니다:

MCP 서버를 잠그세요. 신뢰할 수 없는 사용자 데이터를 반환하는 MCP 서버를 코딩 에이전트에 연결하지 마세요. Sentry를 사용하는 경우, 코딩 에이전트에게 에러 트래킹에 대한 직접적인 MCP 액세스가 필요한지, 아니면 인간 참여형 (human-in-the-loop) 검토가 더 나은지 고려하십시오.

샌드박스 환경에서 에이전트를 실행하세요. 읽기 전용 파일 시스템을 가진 Docker 컨테이너, 외부 송신 (egress)을 제한하는 네트워크 정책, 그리고 운영 환경의 비밀 정보 (secrets)에 대한 액세스 권한이 없는 환경을 구축하십시오. Docker의 자체 AI Governance 제품은 정확히 이 용도로 설계되었습니다.

에이전트 수준의 액세스 제어를 구현하세요. 에이전트는 민감한 작업에 접근하기 전에 인증을 거쳐야 합니다. 이는 에이전트가 권한이 있는 작업을 실행하기 전에 검증 가능한 자격 증명을 제시하도록 요구하는 오픈 소스 에이전트 여권 시스템인 APort의 핵심 개념입니다. 만약 사용 중인 에이전트 프레임워크가 에이전트 수준에서 인증을 강제하지 않는다면, 여러분은 DSN 스캔 한 번에 침해 사고를 당할 수 있는 상태입니다.

노출된 DSN 및 API 엔드포인트를 감사하십시오. 공개된 JavaScript 번들 내에 임베디드된 DSN이 있는지 확인하십시오. 배포된 에이전트 API 엔드포인트에 대한 스캔을 실행하여 인증 (Authentication)이 강제되고 있는지, 그리고 /agents 엔드포인트가 공개적으로 접근 가능한 상태는 아닌지 확인하십시오.

침해를 가정하고 에이전트의 동작을 모니터링하십시오. 코딩 에이전트가 실행하는 모든 명령을 로그로 기록하십시오. 비정상적인 패턴을 모니터링하십시오. 에이전트가 운영 데이터베이스 (Production Database)에 접근하거나 SSH 설정을 수정하는 경우에 대한 알림을 설정하십시오. 갑자기 /etc/shadow 파일을 읽기 시작하거나 알 수 없는 IP로 curl을 실행하는 에이전트는 침해된 상태입니다.

변화가 필요한 부분

보안 업계는 AI 증강 개발 (AI-augmented development)에서의 신뢰 경계 (Trust boundaries)에 대한 사고방식을 진화시켜야 합니다. 이제 에이전트는 시스템의 권한을 가진 사용자 (Privileged user)입니다. 에이전트는 운영 환경 접근 권한을 가진 신입 사원에게 부여하는 것과 동일한 수준의 보안 검토를 받아야 마땅합니다.

세 가지 구체적인 변화:

MCP에는 보안 계층이 필요합니다. 모델 컨텍스트 프로토콜 (Model Context Protocol, MCP)은 인증 (Authentication), 무결성 검증 (Integrity verification), 그리고 출처 검증 (Origin validation)을 지원해야 합니다. 에이전트는 MCP 서버로부터 반환된 데이터가 외부 당사자에 의해 변조되지 않았음을 검증할 수 있어야 합니다.

에이전트 프레임워크에는 신원 (Identity)이 필요합니다. 모든 에이전트 실행은 해당 에이전트가 접근하는 도구 및 시스템에 의해 검사될 수 있는 검증 가능한 신원을 지녀야 합니다. 에이전트가 자신을 승인한 주체가 누구인지 증명할 수 없다면, 민감한 작업에 대한 신뢰를 부여해서는 안 됩니다.

개발자들에게 AgentSec 교육이 필요합니다. 대부분의 개발자는 SQL 인젝션 (SQL injection)과 XSS를 이해합니다. 하지만 프롬프트 인젝션 (Prompt injection), MCP 포이즈닝 (MCP poisoning), 또는 에이전트 수준의 인증 우회 (Agent-level auth bypass)를 이해하는 사람은 매우 적습니다. 우리는 DevSecOps에서 일어났던 것과 동일한 변화, 즉 보안 인식이 침해 사고 후에 덧붙여지는 것이 아니라 개발자 워크플로우에 내재화되는 변화가 필요합니다.

결론

Agentjacking은 Sentry의 취약점이 아닙니다. Claude Code나 Cursor의 취약점도 아닙니다. 이것은 AI 에이전트, 외부 데이터 소스, 그리고 우리가 에이전트에게 부여하는 권한 사이의 관계를 설계한 방식에 존재하는 아키텍처적 취약점 (Architectural vulnerability)입니다.

이 공격은 탐지할 만한 악성 요소가 전혀 없기 때문에 모든 전통적인 보안 제어 (Security control)를 우회합니다. 공격자는 귀하의 인프라에 전혀 손을 대지 않습니다. 주입된 데이터는 에이전트가 신뢰할 수 있는 것으로 간주하는 채널을 통해 전달됩니다. 코드는 귀하의 기기에서 귀하의 권한으로 실행됩니다.

우리는 AI 코딩 어시스턴트 시대에 진입한 지 3년째입니다. 우리는 생산성, 속도, 그리고 개발자 경험 (Developer experience)을 최적화해 왔습니다. 하지만 보안을 최적화하지는 않았습니다. 그리고 그 격차가 현재 악용되고 있습니다.

PraisonAI 팀은 공개 후 4시간 이내에 패치를 완료했지만, 공격자들은 이미 3시간 44분 만에 스캐닝을 시작했습니다. 알려진 인증 우회 (Authentication bypass) 취약점이 대부분의 팀이 아침 스탠드업 미팅을 마치기도 전에 무기화될 수 있다면, 공격자가 귀하의 MCP 설정에서 알려지지 않은 취약점을 발견했을 때는 어떤 일이 벌어질 것이라고 생각하십니까?

침해 사고가 발생한 후에야 그 결과를 확인하게 될 수는 없습니다. 지금 바로 해결해야 합니다.

귀하의 코딩 에이전트의 액세스 권한을 감사(Audit)해 보셨습니까? 귀하의 팀이 어떤 MCP 서버에 연결되어 있는지 확인해 보셨습니까? 이에 대한 의견을 듣고 싶습니다.

AI 에이전트 안전 시리즈의 이전 내용:

• 사전 작업 권한 부여: AI 에이전트를 위한 누락된 보안 계층 (Pre-Action Authorization: The Missing Security Layer for AI Agents)

Uchi Uchibeke는 개발자들이 밤잠을 설칠 필요 없이 안전한 AI 에이전트를 출시할 수 있도록 돕는 도구들을 만듭니다. 그는 APort (오픈 소스 에이전트 여권), Chimoney, 그리고 World Innovation League의 설립자입니다. MCP 포이즈닝 (MCP poisoning)에 대해 스트레스를 받지 않을 때는 아마 아내와 함께 '굿 닥터(The Good Doctor)'를 시청하고 있을 것입니다.