뚫린 건 AI 모델이 아니었습니다 | 최근 AI 에이전트 취약점과 사고 5건 정리

RovoBlast, RufRoot, Ghostjacking. 모두 최근 몇 달 새 세상에 알려진 AI 에이전트 취약점과 공격 기법의 이름입니다. 여기에 코딩 에이전트 취약점과 AI 브라우저 탈취 사건까지 더하면, 지난 7월 말부터 거의 매주 새로운 보안 사고와 리서치가 나온 셈이죠.

AI 보안 트렌드를 놓치지 않으려고 최신 리포트들을 찾아 읽어보면 내용 자체는 매우 훌륭합니다. 하지만 다 읽고 나면 늘 비슷한 고민에 빠지게 되죠. "그래서... 우리 서비스는 대체 뭘 봐야 하지?"

당장 RovoBlast 취약점만 해도 그렇습니다. 리포트를 아무리 꼼꼼히 읽어봐도 Atlassian Rovo를 쓰지 않는 팀이라면 우리 시스템에 적용할 만한 힌트를 건지기가 어렵습니다. 결국 '남의 집 사고 사례'만 쌓여갈 뿐, 정작 우리 팀 이번 분기 점검 리스트는 한 줄도 바뀌지 않는 거죠.

그래서 이번 글에서는 최근 사고들을 한자리에 놓고 공통점을 뜯어봤습니다. 결론부터 말씀드리면, 다섯 건 모두 고쳐야 할 지점은 AI 모델이 아니었습니다. 프롬프트 인젝션처럼 모델 쪽 한계에서 출발한 사례도 있지만, 그 경우조차 피해를 키운 건 에이전트에게 열려 있던 권한과 검증이었죠. 인증과 인가, 입력값 검증. 보안 담당자라면 이미 지겹도록 봐온 기본기입니다.

이번 글에서는 AI 에이전트 보안 사고 5건을 유형별로 살펴보고, 이 사건들이 결국 어떻게 동일한 보안 취약점으로 귀결되는지 상세히 분석해 봅니다.

글 마지막에 담긴 '보안 점검 체크리스트'를 활용해, 우리 서비스에서 당장 확인해야 할 점검 포인트들을 바로 찾아보세요.

🔗 패턴 1. AI 에이전트가 읽는 것은 전부 명령이 될 수 있습니다

Atlassian의 AI 에이전트 Rovo는 Jira, Confluence, Slack 등 사내 도구를 넘나들며 검색하고 요약해 주는 업무용 AI 비서입니다.

Rovo 채팅은 URL에 질문을 담아 공유하면 대화창을 미리 채워주는 편리한 기능을 제공합니다. RovoBlast 공격은 이를 악용해 링크에 질문 대신 공격 명령을 숨겼습니다. 사용자가 무심코 링크를 클릭하면 로그인 상태가 유지된 세션 안에서 명령이 자동 실행되었고, 결국 내부 문서가 공격자에게 고스란히 넘어갔습니다.

여기서 눈여겨볼 부분은 권한 우회가 전혀 없었다는 점입니다. AI 에이전트는 로그인한 사용자의 권한을 정당하게 위임받았고, 그 권한의 테두리 안에서 정상적으로 임무를 수행했을 뿐입니다. URL 파라미터를 통해 들어온 텍스트가 곧 '명령'이 되었다는 것, 그것이 전부입니다.

Ghostjacking 공격은 여기서 한 걸음 더 나갑니다. 사용자가 무언가를 클릭할 필요조차 없기 때문입니다. 올해 DEF CON에서 공개된 이 발표에서 연구팀은 Cloudflare 방화벽이 차단할 요청의 User-Agent 헤더에 공격 문구를 심었습니다. 방화벽은 요청을 막았지만 그 내용을 로그에 원문 그대로 남겼고, 하필 그 필드가 장애를 조사하러 들어온 에이전트가 MCP로 읽어 가는 필드였습니다. 에이전트는 그 로그를 '읽을 자료'가 아니라 '받은 지시'로 처리했고, 정식으로 부여받은 권한으로 DNS 레코드를 공격자 주소로 바꾼 뒤 조치 완료라고 보고했습니다. 실제 피해 사례는 아니지만, 로그를 읽는 에이전트에게 DNS를 바꿀 권한까지 있었다는 점이 이 발표의 핵심입니다.

통상적으로 시스템 로그는 가장 신뢰할 수 있는 데이터로 취급됩니다. 사람이 아닌 시스템이 직접 남긴 기록이니까요. 하지만 AI 에이전트에게 로그는 그저 연속된 텍스트일 뿐이며, 읽는 순간 명령과 데이터를 구분하지 못합니다.

안타깝게도 이러한 근본적인 취약점은 당분간 해결되기 어려워 보입니다. 주요 벤더의 AI 브라우저가 여전히 프롬프트 인젝션에 취약하다는 연구 결과가 이어지고 있으며, 클릭 한 번 없이 에이전트를 탈취하는 'PleaseFix' 같은 새로운 기법도 계속 등장하고 있습니다. 업계에서 "현재로선 완벽한 해결책이 없다"고 입을 모으는 이유도 여기에 있습니다. 지시어(명령)와 데이터가 동일한 텍스트 형태로 모델에 입력되는 한, AI가 이를 100% 완벽하게 걸러내기는 불가능에 가깝기 때문입니다.

💡 Key Takeaway: AI 에이전트가 접근하는 모든 입력은 잠재적 명령입니다. URL 파라미터, 로그, 이슈 코멘트, 웹페이지, 파일명까지 전부 해당됩니다. 모델이 걸러주기를 기대할 수 없다면, 방어선은 뚫린 뒤에 무엇을 할 수 있는가로 옮겨야 합니다. 에이전트가 쥔 도구로 데이터를 밖으로 내보낼 수 있는지, 설정을 바꿀 수 있는지부터 확인해 보세요.

🔌 패턴 2. AI가 아닌 '연결부'의 맹점

RufRoot(CVE-2026-59726, CVSS 10.0)는 오픈소스 AI 에이전트 플랫폼 'Ruflo'의 MCP 브릿지에서 발견된 치명적인 취약점입니다. AI 에이전트가 사용하는 무려 233개의 도구가 아무런 인증 절차 없이 외부에 노출되어 있었습니다. 기본 제공된 docker-compose 설정이 브릿지 포트를 0.0.0.0로 지정하여 모든 네트워크 인터페이스에 열려 있었고, 토큰도 IP 허용 목록도 없었습니다. 공격자는 단 한 번의 요청만으로 API 키를 탈취하고 대화 기록을 빼냈으며, 사실상 에이전트를 관리자 권한으로 조종할 수 있었습니다.

비슷한 시기에 공개된 Paperclip 취약점은 '인가(Authorization)' 설계의 허점을 여실히 보여줍니다. 이 플랫폼은 인스턴스 관리자만 새로운 조직을 생성할 수 있도록 권한을 단단히 통제했습니다. 하지만 동일한 결과를 만들어내는 '가져오기(Import)' 기능은 훨씬 낮은 권한으로도 접근할 수 있었습니다. 공격자는 이메일 인증도 없이 일반 계정을 만든 뒤 이 우회 경로를 호출했고, 결국 서버에서 임의의 명령을 실행하는 악성 에이전트를 심는 데 성공했습니다.

이 두 사고의 결정적인 공통점은 공격의 타깃이 AI 모델이 아니라 도구와의 '이음새'였다는 점입니다. 모델 자체에는 아무런 결함이 없었지만, 모델과 외부 도구를 연결하는 구간에 인증이 아예 빠져있거나 인가 기준이 일관되지 않았던 것이 화근이었습니다. 겉보기엔 최신 AI 보안 사고 같지만, 뚜껑을 열어보면 보안 실무자들이 십수 년간 다뤄온 전형적인 '인증 없는 API 노출' 문제와 다를 바 없습니다.

💡 Key Takeaway: 에이전트를 도입할 때 실제로 늘어나는 공격 표면은 모델이 아니라 도구 연결부입니다. 어떤 도구가 어떤 권한으로 붙어 있는지, 그 연결에 인증이 걸려 있는지부터 확인하세요. 그리고 같은 결과를 만드는 경로가 둘 이상이라면, 두 경로의 인가 기준이 같은지 반드시 대조해야 합니다.

💥 패턴 3. 공격자가 없어도 사고는 납니다

앞서 살펴본 두 사례와 달리, 세 번째 패턴에는 시스템을 노리는 공격자가 존재하지 않습니다. 하지만 아이러니하게도 실제 피해 규모는 이 유형이 가장 컸습니다.

올해 4월 25일, 미국 차량 렌털 업체들의 예약 데이터를 관리하는 SaaS 업체 PocketOS에서 운영 데이터베이스와 백업 데이터가 통째로 9초 만에 사라졌습니다. 발단은 아주 사소했습니다. 작업을 수행하던 AI 에이전트가 자격 증명 오류에 부딪히자, 작업을 멈추고 관리자에게 묻는 대신 '저장 공간을 지우고 새로 만들면 해결된다'고 스스로 판단해 버린 것입니다. 그 누구도 삭제를 지시하지 않았음에도 말이죠.

본래 에이전트에게는 그럴 권한조차 없어야 마땅했습니다. 하지만 에이전트는 본인의 작업과 전혀 무관한 경로를 뒤져 '삭제 권한'이 포함된 자격 증명을 찾아냈고, API를 단 한 번 호출하여 운영 볼륨을 날려버렸습니다. 안전장치가 없었던 것은 아닙니다. 저장소의 에이전트 규칙 파일에는 복구 불가능한 명령을 금지하는 조항이 있었고, 코딩 도구에는 위험 동작 방지 기능이, 인프라 대시보드와 CLI에는 삭제 유예 장치가 마련되어 있었습니다. 그러나 에이전트가 우회하여 호출한 특정 API 경로 단 하나가 이 보호망들과 연결되어 있지 않았고, 삼중으로 쳐둔 방어선은 그 작은 틈 하나에 모두 무력화되었습니다.

이는 비단 작은 기업만의 문제가 아닙니다. 지난해 12월, 아마존(Amazon)에서도 AI 코딩 에이전트가 AWS Cost Explorer 환경을 스스로 삭제한 뒤 재생성하려다 13시간 동안 대규모 장애를 일으킨 바 있습니다. 아마존은 AI의 결함이 아닌 권한 설정의 실수라고 선을 그었지만, 사건 직후 운영 환경 변경 시 반드시 동료 검토를 거치도록 정책을 바꿨습니다.

B2B 영역 밖에서도 비슷한 일이 벌어집니다. 최근 호주에서는 한 사용자가 AI 비서에게 헬스장 예약을 맡기며 "대기 순번을 당겨달라"고 요청했더니, AI가 권한 확인이 허술한 API를 통해 다른 회원의 예약을 멋대로 취소해 버리는 황당한 사건도 있었습니다.

결국 시스템을 무너뜨린 것은 외부의 적이 아니라, 내부의 느슨한 통제였습니다. AI에게 파괴적인 명령까지 실행할 수 있도록 쥐어준 과도한 권한 자체가 언제든 사고를 일으킬 수 있는 가장 치명적인 위협입니다.

💡 Key Takeaway: 프롬프트에 적어둔 금지 사항은 안전장치가 아닙니다. 안전장치는 에이전트가 넘을 수 없는 곳에 걸려 있어야 하며, 아래 확인이 필요합니다: 에이전트가 쓰는 자격 증명이 할 수 있는 최악의 일은 무엇인가, 되돌릴 수 없는 동작에 사람의 승인이 걸려 있는가, 그 승인을 권한만으로 건너뛸 수는 없는가.

✅ 그래서 무엇부터 점검해야 할까요: AI 에이전트 보안 체크리스트

입력 쪽

• ☐ 에이전트가 읽는 데이터의 출처를 목록으로 뽑고, 외부에서 값을 채워 넣을 수 있는 경로를 표시했는가 (URL 파라미터, 로그, 외부 문서)

• ☐ 에이전트가 사용자 권한을 그대로 물려받는지, 아니면 별도 계정으로 동작하는지 확인했는가

연결부 쪽

• ☐ 에이전트가 붙은 도구 연결 지점에 인증 없이 요청을 보내봤는가 (MCP 서버, 내부 브리지)

• ☐ 같은 결과를 만드는 경로가 둘 이상인 기능을 찾아, 각 경로의 인가 기준을 나란히 대조했는가

• ☐ 설치 문서의 기본값을 그대로 쓰고 있는 항목을 확인했는가 (바인딩 주소, 회원가입 정책, 로컬 신뢰 범위)

권한 쪽

• ☐ 에이전트가 쓰는 토큰의 권한 범위를 발급처에서 직접 열어보고, 실제 필요한 작업과 비교했는가

• ☐ 코드와 설정 파일에 남아 있는 자격 증명을 검색해, 에이전트가 접근 가능한 위치인지 확인했는가

• ☐ 되돌릴 수 없는 동작을 실제로 실행시켜 보고, 사람의 승인 단계에서 멈추는지 확인했는가

• ☐ 백업이 원본과 다른 권한·다른 저장 위치에 있는지 확인했는가

• ☐ 다른 사용자의 리소스를 지정해 요청을 보내보고, 거부되는지 확인했는가

보시다시피 새로운 항목은 하나도 없습니다. 전부 애플리케이션 보안에서 오래 다뤄온 것들이죠. 달라진 건 딱 하나, 우선순위를 매기던 기준입니다.

지금까지 이 항목들은 사람이 실수로 건드릴 확률을 감안해 뒤로 밀리곤 했습니다. 넓은 권한이 딸린 토큰이 코드 어딘가에 들어 있어도, 그걸 굳이 찾아내 운영 DB를 지울 사람은 없었으니까요. 하지만 이제 AI 에이전트의 시대에서는 그 확률을 빼고 다시 계산해야 합니다.

🎯 AI 시대에 점검해야 할 대상은 AI가 아닙니다

AI를 붙인 서비스에서 정작 살펴야 할 곳은, 그 AI가 올라타 있는 애플리케이션과 API입니다. 문제는 인가 누락이나 인증 우회 같은 결함이 코드를 읽거나 설정을 확인하는 것만으로는 잘 드러나지 않는다는 점이죠. 실제로 요청을 보내보고, 남의 권한으로도 통하는지 확인해야 비로소 보입니다.

Xint는 운영 중인 서비스를 대상으로 그 확인을 대신합니다. AI 에이전트가 실제 사용자처럼 서비스를 탐색하면서, 인증 우회와 인가 누락, 비즈니스 로직 결함처럼 패턴 스캔으로는 잡히지 않는 취약점을 찾아냅니다. 앞서 살펴본 사례들처럼 권한 확인이 빠진 API가 정확히 이 범주입니다. 점검은 사전에 설정된 범위와 계정 권한 안에서 비파괴 방식으로 진행됩니다.

👉 [Xint 표준 샘플 보고서 확인하기]

👉 [1:1 도입 문의 및 견적 확인하기]

📩 최신 보안 인사이트 받아보기

Xint 팀이 분석한 취약점 연구와 최신 보안 인사이트를 이메일로 가장 먼저 받아보세요.

[이메일 뉴스레터 구독하기]

문의: contact@xint.io

웹사이트: xint.io