에이전트에게 오류를 고치라고 했는데, 그중 하나는 공격자가 쓴 것이었어요

개발자가 AI 코딩 에이전트를 열고 세상에서 가장 평범한 요청을 입력해요: "확인되지 않은 Sentry 오류를 살펴보고 고쳐줘." 에이전트는 Sentry 커넥터를 통해 오류 목록을 가져오고, 맨 위 이슈를 읽고, 보고서에 바로 적혀 있는 복구 절차를 따라 실행해요. 30초 뒤 에이전트는 개발자의 기계에서 개발자의 전체 권한으로 공격자의 코드를 실행했어요. 그런데 아무도 잘못한 게 없어요.

이것이 Agentjacking이에요. 이번 달 Tenet Security가 공개한 이 방법은 시장에서 가장 널리 쓰이는 세 가지 코딩 에이전트, Claude Code, Cursor, Codex를 상대로 85%의 확률로 성공했어요 [1][2].

실제로 무슨 일이 있었나

먼저 Sentry가 무엇인지부터요. Sentry는 소프트웨어에서 가장 널리 쓰이는 오류 모니터링 서비스 중 하나예요. 앱이 오류를 던지거나 크래시하면 Sentry가 이를 포착하고 개발자가 분류할 보고서를 만들어요. 여러분이 매일 쓰는 앱의 상당수가 여기에 들어 있어요. 보고서를 보내기 위해 모든 앱은 DSN을 심어 둡니다. 브라우저가 오류를 본사로 보낼 수 있도록 의도적으로 웹사이트 소스에 실리는 클라이언트 측 키예요. 누구나 읽을 수 있고, 이 키를 가진 누구나 여러분의 Sentry 프로젝트로 오류 이벤트를 POST할 수 있어요.

공격의 핵심이 바로 이거예요. Tenet은 메시지 필드가 Sentry 자체의 복구 안내문과 똑같아 보이도록 형식을 맞춘 가짜 오류 이벤트를 만들었어요. 깔끔한 마크다운, "권장 수정 사항", 실행할 명령어가 들어 있었죠. 공개된 DSN으로 이것을 제출했어요. 그리고 개발자가 가장 자연스럽게 하는 행동, 즉 에이전트에게 오류 큐를 비워달라고 요청하기를 기다렸어요.

에이전트는 MCP 커넥터를 통해 Sentry를 조회해요. 커넥터는 오류를 신뢰할 수 있는 시스템 출력으로 돌려주고요. 에이전트는 진짜 Sentry 보고서와 위조된 것을 구분하지 못해요. 두 가지는 바이트 단위로 똑같은 형태거든요. 그래서 지시대로 "수정"을 실행하는데, 보통 공격자의 패키지를 호출하는 npx 명령이에요. 그 시점부터 개발자가 가진 모든 것을 가져가요. 환경 변수, Git 자격 증명, 비공개 저장소 URL, ~/.aws/ 안의 클라우드 키까지요.

Tenet은 독립 개발자부터 Fortune 100 기업까지, 주입 가능한 DSN을 쓰는 2,388개 조직을 찾아냈어요. 통제된 테스트에서 에이전트는 실제 기업에서 주입된 지시를 실제로 실행했어요. Tenet의 설명에 따르면 시가총액 2,500억 달러 규모의 Fortune 100 기술 기업도 포함됐는데, 이 기업의 AI 에이전트가 가짜 버그 보고서를 읽고 사내 기계 두 대에서 Tenet의 코드를 실행했어요 [1][3]. 6월 3일 Sentry에 공개되었고, Sentry는 같은 날 이를 인정하면서도 근본적인 수정을 거부했어요. 이 문제를 "기술적으로 방어할 수 없는 수준"이라고 부르면서요. 대신 특정 페이로드 문자열 하나를 차단하는 콘텐츠 필터를 내놓았어요 [4].

Sentry가 부주의했던 게 아니에요

불편한 진실은 이거예요. 그 체인 어디에도 버그가 없었다는 점이에요. DSN은 원래 공개되어야 해요. MCP 서버는 원래 여러분의 오류 데이터를 돌려줘야 해요. 에이전트는 원래 여러분이 고치라고 요청한 진단 정보에 따라 행동해야 해요. 모든 단계가 허용된 동작이었고, 그래서 방화벽도 EDR도 시스템 프롬프트도 이것을 잡아내지 못했어요.

결함은 구조적인 것이고, Sentry만의 문제도 아니에요. 외부인이 영향을 줄 수 있는 텍스트를 에이전트에 넣어주는 도구는 모두 주입 경로예요. 오류 추적기, 이슈 큐, 스크래핑한 웹 페이지, 공유 문서가 모두 해당되고, 에이전트는 이 모든 것을 구분 없이 하나의 지시 스트림으로 받아들여요. 에이전트 시대가 시작된 지 2년이 지났는데도 프롬프트 주입은 여전히 해결되지 않았어요. 적대적인 텍스트를 모델의 추론에서 확실하게 막을 수는 없어요. 막을 수 없다고 가정하세요.

재난은 주입 자체가 아니에요

곰곰이 생각해볼 부분은 여기예요. Agentjacking이 비상 경보를 울려야 할 사안인 이유는 에이전트가 속았기 때문이 아니에요. 속은 에이전트가 무엇에 닿을 수 있었는가가 문제예요. 이것은 개발자의 상시 권한 전체를 가지고 실행됐어요. 환경의 모든 키, 디스크의 모든 자격 증명 파일, 명령 하나로 열 수 있는 키링 전체까지요.

그 피해 범위는 자연 법칙이 아니에요. 설정일 뿐이죠. 에이전트가 이 모든 것에 상시 접근할 수 있었던 이유는 오늘날 자격 증명이 그렇게 저장되기 때문이에요. 기계 안에 널려 있고, 그곳에서 실행되는 무엇이든 읽을 수 있는 방식으로요. 이것을 걷어내면 같은 탈취가 벽에 부딪히게 돼요.

일부러 이런 상황에 맞춰 만들었어요

Clavitor의 자격 증명은 에이전트가 실행되는 환경에 절대 놓이지 않아요. 읽을 ~/.aws/credentials도, 유출할 환경 변수 속 API 키도 없어요. 비밀 값이 코드가 실행되는 곳에 도달하지 않기 때문이에요. 에이전트는 자격 증명 자체가 아니라 자격 증명을 사용한 결과를 받아요. 이름이 붙여진 그 대상 하나에만 닿을 수 있으므로, 저장소를 열거하면서 다른 무엇이 있는지 찾아낼 수 없어요. 그리고 권한 부여는 범위가 한정되고 취소할 수 있어서, 공격자처럼 행동하기 시작한 세션은 작업 도중에 끊을 수 있어요.

솔직하게 말씀드리면, 이것은 주입을 막지 못하고, 탈취된 에이전트가 명령을 실행하는 것도 막지 못해요. 프롬프트 주입은 해결되지 않았고, 저희가 해결했다고 주장하지 않아요. 달라지는 것은 수확이에요. 공격자의 코드는 여전히 실행되지만, 그 안에 훔칠 만한 상시 자산이 없는 환경을 만나게 되죠. 탈취는 성공하고 도난은 실패해요.

에이전트 자체가 당신에게 쓰이는 무기가 될 수 있는 순간, 자격 증명 시스템이 지켜야 할 규칙을 정리해 두었어요. 비밀이 코드가 실행되는 곳에 살지 않을 것, 에이전트가 이름 붙여진 대상에만 닿을 것에서 시작해요. 여러분의 시스템을 이 기준에 비춰보세요: clavitor.ai/rules.

교훈은 "Sentry를 패치하라"가 아니에요

Sentry는 이것을 고칠 수 없고, 그렇다고 밝혔어요. 그리고 다음에 오염되는 도구는 Sentry가 아닐 거예요. 에이전트가 널려 있는 상시 자격 증명을 가지고 있는 한, 그들이 읽는 신뢰할 수 있는 모든 도구는 장전된 총이고, 프롬프트 주입은 잠글 수 없는 방아쇠예요.

악성 텍스트를 막아내기는 어려워요. 그러니 그 텍스트를 읽는 에이전트의 손이 닿는 곳에 자격 증명을 두지 마세요.

Clavitor(@clavitorai)는 AI 에이전트를 위해, 그리고 에이전트에 대비해 만들어진 자격 증명 금고예요. clavitor.ai

출처

[1] Tenet Security — "Agentjacking: hijacking coding agents with fake Sentry errors" (85% 성공률; 2,388개 조직; 작동 방식): https://tenetsecurity.ai/blog/agentjacking-coding-agents-with-fake-sentry-errors/

[2] The Hacker News — "Agentjacking Attack Tricks AI Coding Agents Into Running Malicious Code": https://thehackernews.com/2026/06/agentjacking-attack-tricks-ai-coding.html

[3] The New Stack — "A public Sentry key is all it takes to hijack Claude Code, Cursor, and Codex": https://thenewstack.io/agentjacking-sentry-mcp-attack/

[4] Infosecurity Magazine — "New 'Agentjacking' Attacks Could Hijack AI Coding Agents" (Sentry의 대응): https://www.infosecurity-magazine.com/news/agentjacking-attacks-hijack-ai/