자율형 AI 랜섬웨어 ‘제이드퍼퍼’ 등장, AI 에이전트 보안이 발등의 불이 된 이유

지난 7월 초, 보안기업 시스디그(Sysdig)가 이례적인 사고 하나를 공개했습니다. 침입부터 데이터 암호화까지 해킹의 전 과정을 사람 개입 없이 AI 에이전트가 스스로 수행한 랜섬웨어 공격이 처음으로 확인된 것입니다. 업계는 이 공격에 ‘제이드퍼퍼(JadePuffer)’라는 이름을 붙였습니다.

시스디그 분석에 따르면 이 AI 에이전트는 오픈소스 AI 워크플로우 툴 Langflow의 인증 없는 원격코드실행 결함(CVE-2025-3248)으로 처음 진입한 뒤, 5년 전에 등록된 알리바바 나코스(Nacos)의 인증 우회 취약점(CVE-2021-29441)을 이용해 실제 운영 중인 MySQL 서버까지 옮겨갔습니다. 정찰, 자격증명 탈취, 내부망 이동, 권한 상승, 데이터 암호화까지 전 단계가 자동으로 이어졌습니다. 로그인 시도가 실패하자 원인을 스스로 진단하고 31초 만에 우회 방법을 다시 시도했다는 점도 함께 확인됐습니다.

배경: ‘제이드퍼퍼’가 고립된 사건이 아닌 이유

시스디그는 이번 사건을 ‘에이전트 기반 위협 행위자(Agentic Threat Actor, ATA)’ 시대의 서막으로 규정했습니다. 사람이 일일이 명령을 내리지 않아도 공격이 스스로 굴러가기 시작했다는 뜻이고, 그만큼 공격의 진입장벽이 낮아졌다는 경고이기도 합니다.

실제로 비슷한 시기 나온 다른 보고서도 같은 방향을 가리킵니다. 체크포인트(Check Point Research)는 2026년 7월 14일 새 AI 보안 보고서를 공개했습니다. 2025년 10월부터 2026년 5월까지 기업을 조사한 결과, 87~93%가 매달 한 번 이상 고위험 AI 상호작용을 겪은 것으로 나타났습니다.

같은 보고서는 공개된 취약점이 알려진 지 불과 몇 시간 만에 AI가 악용 코드를 만들어 공격에 나서는 사례도 확인됐다고 덧붙였습니다.

이보다 앞서 2026년 2월, 소프트웨어 기업 그라비티(Gravitee)도 비슷한 조사 결과를 내놓았습니다. 임원·기술 실무자 900여 명을 대상으로 진행한 이 조사에서 기업 88%가 확인됐거나 의심되는 AI 에이전트 보안 사고를 최근 1년 사이 겪었다고 답했습니다. 그런데 같은 조사에서 경영진의 82%는 기존 보안 정책으로 AI 에이전트의 무단 행동을 막을 수 있다고 자신했습니다.

실제 사고율과 자신감 사이에는 큰 간극이 있는 셈입니다.

왜 중요한가: AI 에이전트 보안이 대기업만의 이야기가 아닌 이유

제이드퍼퍼가 뚫고 들어간 지점은 대기업 전용 보안 솔루션이 아니었습니다. Langflow·Nacos처럼 개발자와 자동화 운영자가 흔히 쓰는 오픈소스 도구였다는 점을 눈여겨봐야 합니다. n8n으로 여러 서비스의 API 키를 한 인스턴스에 몰아넣었거나, 클로드·챗GPT·제미나이의 에이전트 기능에 여러 도구 실행 권한을 넘겨둔 개인 자동화 운영자라면 이 사고는 남의 이야기가 아닙니다.

더구나 이번 침투에 쓰인 취약점 중 하나는 발견된 지 5년이 지난 것이었습니다. 대기업은 전담 보안팀이 패치 여부를 주기적으로 점검하지만, 혼자 자동화 워크플로우를 운영하는 부업러·1인 사업자에게는 그런 점검 체계가 없는 경우가 대부분입니다. 보안팀 없이 강력한 자동화 권한만 쓰고 있다는 점에서, 개인 운영자가 오히려 더 취약한 위치에 있을 수 있습니다.

그라비티 조사에서 확인된 또 다른 수치도 눈여겨볼 만합니다. 응답 기업의 45.6%는 에이전트 간 인증에 여전히 공유 API 키를 쓰고 있었습니다. AI 에이전트를 사람처럼 별도 식별 대상으로 관리한다고 답한 비율은 21.9%에 그쳤습니다.

제이드퍼퍼·체크포인트·그라비티, 이 세 가지를 나란히 놓고 보면 공통된 결론 하나가 보입니다. 예산과 전담 인력을 갖춘 기업조차 정책과 실제 대응 사이의 격차를 못 좁히고 있습니다. 그렇다면 개인 자동화 운영자에게 현실적인 목표는 ‘기업 수준의 대응 체계를 갖추는 것’이 아니라, 애초에 뚫렸을 때 피해가 번지지 않도록 권한과 자격증명의 범위를 작게 나눠두는 쪽에 가깝습니다.

전망과 실무 시사점: AI 에이전트 보안, 지금 무엇을 점검해야 할까

에이전트에게 도구 실행 권한을 맡기는 방식이 표준이 되고 있는 지금, ‘얼마나 편리한가’만큼 ‘얼마나 좁은 권한만 맡기는가’를 함께 따져야 하는 시점이 됐습니다. 이미 n8n 보안 설정법에서 다뤘듯, 암호화 키 백업이나 2단계 인증처럼 자동화 도구 자체의 기본 보안 설정부터 챙기는 것이 출발점입니다.

여기에 더해, 그 글에서 다루지 않았던 ‘권한 범위 좁히기’ 관점에서 실무적으로 점검할 만한 것은 세 가지입니다.

• API 키 분리. 여러 서비스에 같은 키를 돌려쓰고 있지 않은지 확인하고 서비스별로 나눠서 발급하되, n8n이라면 자격증명을 만들 때 이름에 서비스명과 실제 용도를 함께 적어두고(예: “OpenAI – 블로그자동화용”) 연동 시 “전체 권한(all scopes)”을 한 번에 누르는 대신 실제 필요한 범위만 선택하는 것만으로도 키 하나가 뚫렸을 때 피해 범위를 크게 줄일 수 있습니다.
• 최소 권한 부여. 클로드 Agent Skills를 쓴다면 SKILL.md의 allowed-tools를 ‘권한을 좁히는 항목’으로 착각하지 않아야 합니다. 공식 문서에 따르면 이 필드는 그 턴에서 승인 절차 없이 자동 실행할 도구를 지정할 뿐이고, 실제로 스킬이 쓸 수 있는 도구 자체를 줄이려면 disallowed-tools에 쓰지 않을 도구를 명시해야 합니다. 챗GPT 에이전트 모드나 제미나이 에이전트도 마찬가지로, 쓰지 않는 연동 앱·사이트 접근 권한은 그때그때 꺼두는 것이 같은 원리입니다.
• 정기 버전 점검. n8n, Langflow류 워크플로우 빌더 등 사용 중인 자동화 툴의 버전이 최신인지 월 1회라도 확인하는 습관을 들입니다.

당장 개인 블로그·부업 자동화가 제이드퍼퍼 같은 공격의 표적이 될 확률은 낮습니다. 다만 시스디그가 경고했듯 공격 설계·실행 자체를 AI가 대신해주는 시대가 되면 표적을 고르는 비용도 함께 낮아집니다. 무료 AI 에이전트 툴을 새로 써보는 사람이 늘어나는 만큼, 도구 하나를 새로 연동할 때마다 권한 범위를 한 번씩 되짚어보는 습관이 앞으로는 선택이 아니라 기본기가 될 가능성이 큽니다.

핵심 요약

1. 시스디그가 7월 초 공개한 ‘제이드퍼퍼’는 침입부터 데이터 암호화까지 전 과정을 AI 에이전트가 스스로 수행한 최초의 자율형 랜섬웨어 사례로, Langflow·Nacos의 취약점(각각 CVE-2025-3248, CVE-2021-29441)을 통해 침투했습니다.
2. 체크포인트(7월 14일 보고서)와 그라비티(2월 조사, 기업 88% 사고 경험) 데이터를 함께 보면 이는 고립된 사건이 아니라 에이전틱 AI 보안 위협이 빠르게 확산되는 흐름의 일부입니다.
3. n8n·클로드·챗GPT 등 에이전트 기능을 쓰는 개인 자동화 운영자도 API 키 분리, 최소 권한 부여, 정기 버전 점검 세 가지는 지금부터 챙겨두는 것이 안전합니다.