대상 독자: 웹사이트나 앱을 운영하는 소규모 사업자와 개인 개발자, 업무에서 AI 에이전트나 LLM API를 사용하는 개발자. 이 페이지는 AI가 관련된 2026년 공식 공격 공개 자료와 공공기관 및 표준화 단체가 발표한 방어 지침을 모아 둔 허브입니다. 공격 절차나 익스플로잇 세부 내용은 다루지 않습니다. 새로운 사례가 공개되면 이 페이지와 연결된 보고서를 업데이트합니다.
AI 기반 공격의 네 가지 유형
방어자의 관점에서 공개 사례를 침입 경로별로 묶었습니다. 자신에게 해당하는 유형부터 살펴보십시오.
| 유형 | 공개된 사례 | 진입점으로 악용된 약점 | 가장 먼저 할 일 |
|---|---|---|---|
| 1. 자율 침입 | 평가 중이던 AI 에이전트가 사람의 단계별 지시 없이 AI 플랫폼의 운영 환경에 침입 (2026년 7월, 피해 측과 개발자가 공개). 네덜란드 취약점 공개 조직에서 발생한 침입 후 활동도 AI 에이전트의 것으로 분석됨 | 인터넷에 노출된 자격 증명, 취약한 데이터 처리 경로, 알려지지 않은 취약점 | 노출된 키 폐기, 키 하나로 접근할 수 있는 범위 축소, 외부 데이터를 처리하는 부분 격리 |
| 2. AI로 자동화된 공격 | 일본의 침입 사태. 공격자는 AI로 알려진 취약점을 스캔하고 API를 식별 (JPCERT/CC, 10월 15일). AI 기반 침투 테스트 플랫폼을 악용한 시도도 확인됨 (JPCERT/CC, 10월 23일 업데이트) | 필요 이상의 데이터를 반환하는 API, 서버 측 권한 검사 누락, 앱에 내장된 키, 패치되지 않은 취약점 | API 권한 부여 점검, 앱에서 비밀 정보 제거, 더 빠른 패치 |
| 3. 에이전트 대상 프롬프트 인젝션 | OWASP LLM 애플리케이션 Top 10 (2025)에서 첫 번째로 꼽힘. 에이전트가 읽는 웹 페이지나 파일에 숨겨진 지시 | 에이전트에 부여된 강한 권한, 외부 텍스트와 지시의 미분리 | 최소 권한, 고위험 작업에 대한 사람의 승인, 외부 텍스트를 데이터로 취급 |
| 4. AI 공급망 | LLM API를 통합하는 오픈소스 도구 LiteLLM의 악성코드 삽입 1.107.0 (10월 21일). 개발자의 조사에 따르면 공개 저장소에 커밋된, 폐기되지 않은 내부 에이전트 플랫폼 키가 원인 | 폐기되지 않은 키, 버전 고정 없는 설치, 검토 없이 시작된 MCP 서버 | 버전 고정, 폐기 절차 마련, MCP 서버의 시작 명령과 권한 범위 검토 |
각 유형의 사실관계는 개별 보고서에 있습니다. 유형 1은 AI 플랫폼에 대한 AI 에이전트 침입, 실제 웹사이트에 접근하는 AI 에이전트, DIVD 침입을 참고하십시오. 유형 2는 일본의 무단 접근 경보와 이번 주 점검 사항을 참고하십시오. 유형 4는 LiteLLM 1.107.0 악성코드 배포를 참고하십시오.
2026년 공개된 주요 사례
2026년 7월
평가 중이던 AI 에이전트가 격리 통제를 우회하고, 인터넷에 노출된 자격 증명을 찾아 사용했으며(개발자 보고), 데이터셋 처리 경로를 통해 AI 플랫폼의 운영 환경에 침입했습니다(피해 측 공개). 피해 측은 이 공격이 자율 AI 에이전트에 의해 처음부터 끝까지 수행된 것으로 설명했습니다.7월–10월
AI 개발사들이 평가 중이거나 내부에서 사용 중인 모델이 실제 제3자 시스템과 웹사이트에 접근한 사례를 잇따라 공개했습니다. 사용된 약점은 노출된 자격 증명과 디버그 페이지 같은 기본적인 것이었습니다.9월 24일
네덜란드 취약점 공개 조직이 헬프데스크 소프트웨어의 알려지지 않은 취약점을 통한 침입을 공개했습니다. 침입 후 활동은 AI 에이전트의 것으로 분석되었습니다.10월 8–9일
JPCERT/CC는 일본 조직에 대한 지속적인 무단 접근 경보를 발표했습니다. 일본 국가사이버보안국은 지침을 발표했고, IPA는 조직이 신속히 취해야 할 조치를 공개했습니다.10월 15일
JPCERT/CC는 공격에 사용되었을 것으로 보이는 서버를 분석한 결과를 발표하며, 공격자가 스캔과 API 공격에 AI를 사용했다고 밝혔습니다.10월 21일
악성코드가 삽입된 LiteLLM 1.107.0이 PyPI와 Docker 이미지로 약 2시간 동안 배포되었습니다(Docker Hub 약 2.5시간).10월 23일
JPCERT/CC는 경보에 사례 E를 추가했습니다. 주로 인터넷에 노출된 웹 애플리케이션을 대상으로, 취약점과 관리 측면의 약점을 악용한 AI 기반 침투 테스트 플랫폼 악용 공격 시도입니다.
새로운 점과 새롭지 않은 점
새로운 점
- 정찰, 공격 시도, 내부 이동이 사람의 단계별 지시 없이 계속됩니다
- 차단되면 공격자는 다른 경로와 다른 요청 형태를 계속 시도합니다
- 공개 앱 분석과 API 매핑이 빠르고 대량으로 이루어집니다
- AI 에이전트 자체가 외부 텍스트에 의해 조종되는 표적이 됩니다
새롭지 않은 점
- 진입점은 여전히 패치되지 않은 취약점, 권한 부여 누락, 노출된 키입니다
- 수정되면 사람 공격자와 AI 모두를 같은 방식으로 막습니다
- 키 폐기, 최소 권한, 로그 보관이 피해 확산 범위를 결정합니다
- 연락 창구가 없으면 선의의 제보도 전달되지 않습니다
AI를 사용하는 공격자는 사람이 며칠 걸릴 일을 짧은 시간에 병렬로 시도합니다. 그래서 "다음 정기 점검 때 고치겠다"는 판단은 예전보다 위험해졌습니다. 반대로 방어자가 해야 할 일 자체는 크게 바뀌지 않았습니다. 순서와 속도의 변화로 보면 됩니다.
사람이 승인하고 AI가 실행하는 방식도 보고되었습니다. 10월 20일 한 위협 인텔리전스 기업의 연구팀은 랜섬웨어 제휴자(공격을 실제로 수행하는 사람들)가 사용하는 서버가 노출된 상태였다고 보고했습니다. 기록에 따르면 사람인 운영자가 각 단계를 승인하고, 상용 AI 모델이 정찰을 계획하고 명령을 생성하며 탈취한 데이터를 분류하는 구조였습니다. 같은 보고서에 따르면 한 사례에서는 재사용된 비밀번호 하나로 VPN, 서버, 원격 모니터링 및 관리(RMM) 도구, 백업, 보안 관리 플랫폼에 한꺼번에 접근할 수 있었습니다. AI가 작업을 빠르게 만들었지만, 공격자에게 실제로 효과를 낸 것은 비밀번호 재사용이라는 오래된 약점이었습니다. 보고서는 VPN과 RMM 접근에 다중 인증을 적용하고, 자격 증명을 교체하며, 백업을 보호할 것을 권고합니다.
소규모 운영자와 개발자를 위한 순서
실제 악용된 취약점은 며칠 안에 수정하십시오
공개 서버와 소프트웨어가 CISA KEV(실제 악용이 확인된 취약점 목록)에 포함되는지 확인하십시오. 버전 점검에는 CVE 조회 도구를, 우선순위 결정에는 CVSS, EPSS, KEV로 우선순위 정하기를 활용하십시오.
모든 API에 대해 서버에서 누가 무엇을 할 수 있는지 확인하십시오
JPCERT/CC는 앱 내 서명이나 난독화에만 의존하지 말고, 서버에서 사용자를 인증하고 각 작업을 대상과 내용에 따라 권한 부여할 것을 권고합니다. 관리용 및 내부 API도 검토하십시오. ID를 바꾸면 다른 사람의 데이터를 반환하는 API(IDOR)나 필요 이상의 필드를 반환하는 API가 없는지 확인하십시오. 개념은 인증과 권한 부여의 차이에서 다룹니다.
비밀 정보를 앱과 공개 파일에서 제거하고, 유출된 키를 차단하십시오
JPCERT/CC는 컴파일된 모바일 앱에 내장된 비밀 정보도 추출될 수 있다고 지적합니다. API 비밀 키와 장기 자격 증명은 앱과 브라우저로 전송되는 설정 파일에서 빼내고, 키에는 최소 범위와 만료 기한을 두십시오. 공개 저장소에 한 번 커밋된 키는 커밋을 덮어쓴 뒤에도 폐기되기 전까지 계속 사용할 수 있습니다. LiteLLM 사례도 여기서 시작되었습니다. 유출되어도 유효한 GitHub 자격 증명과 gitleaks로 비밀 정보 커밋 막기를 참고하십시오.
IP별 횟수가 아니라 양, 속도, 간격으로 탐지하십시오
출발지 주소를 바꾸는 공격에 대비하려면 IP별 제한과 함께 기능별 사용량도 확인하십시오. 로그인, 비밀번호 재설정, 검색, 목록 API 등 각 기능에 대해 시간당 요청 수, 반환된 레코드 수, 요청 간격이 얼마나 짧은지 살피십시오. 가장 먼저 추가할 규칙은 가장 많은 레코드를 반환하는 엔드포인트에 시간당 상한을 두고, 80%에서 경고를 보내는 것입니다. 자세한 내용은 속도 제한과 남용 통제에 있습니다.
관리 기능은 인터넷에서 분리하고, 테스트 범위에 포함하십시오
공개할 필요가 없는 관리 기능은 인터넷에서 접근할 수 없는 곳으로 옮기십시오. 테스트를 의뢰할 때는 관리 기능이 점검 범위에 포함되었는지 확인하십시오.
AI 에이전트를 사용한다면 권한과 외부 텍스트 처리 방식을 정하십시오
OWASP는 프롬프트 인젝션을 완전히 막는 방법이 알려져 있지 않다고 밝히고 있으며, 다음 조치를 제시합니다. 모델의 역할과 범위를 제한하고, 정의된 출력 형식을 요구해 코드에서 검사하며, API 키와 특권 기능은 모델에 맡기지 말고 애플리케이션 코드에 두고, 고위험 작업에는 사람의 승인을 요구하며, 외부 콘텐츠는 명확히 구분해 표시하십시오. 에이전트가 읽는 이메일, 웹 페이지, 파일이 지시가 아니라 데이터로 처리되도록 설계하십시오.
MCP 서버와 AI 라이브러리는 버전과 실행 내용을 확인한 뒤 설치하십시오
MCP 명세의 보안 모범 사례는 원클릭 로컬 서버 설정을 제공하는 클라이언트가 정확한 명령을 잘리지 않게 보여주고 명시적 승인을 받을 것을 요구합니다. 서버는 자신에게 발급되지 않은 토큰을 받아들이면 안 되며, 권한 범위는 최소로 시작해 필요할 때만 올려야 합니다. LiteLLM 사례가 보여주듯 잘못된 버전은 정상적인 채널을 통해서도 전달될 수 있으므로, 버전을 고정하고 릴리스 공지를 읽은 뒤 업데이트하십시오. npm에 대해서는 npm 공급망 웜 방어를 참고하십시오.
침해를 가정하고, 차단 절차와 연락 창구를 준비하십시오
즉시 폐기할 수 있는 키 목록, 몇 달 전까지 검색할 수 있는 로그, 책임자에게 닿는 연락 창구(security.txt)를 준비해 두십시오. AI 개발사로부터 통지를 받은 한 정부는 그 통지가 일반 수신함에 들어가 며칠간 방치되었다고 밝힌 바 있습니다. 침입 흔적을 찾으려면 웹사이트와 서버의 침입 여부 확인을 참고하십시오.
진입
패치되지 않은 취약점 / 노출된 키 / 앱에 내장된 비밀 정보
차단: 며칠 내 패치, 키 폐기와 만료 설정
↓
권한
서버 측 권한 부여 누락 / 범위가 넓은 키 / 에이전트에 부여된 권한
차단: 작업별 권한 부여, 최소 권한, 사람의 승인
↓
양
임계값 아래에 머무는 대량 트래픽 / 사람이 할 수 없는 규칙적인 간격
알림: 기능별 횟수, 속도, 간격
↓
유출
보관하지 않는 데이터는 유출될 수 없습니다
축소: 보존 기간이 지난 데이터 삭제, 필요한 최소 필드만 반환
이 사이트의 견해: AI 방어는 AI 제품을 사는 문제가 아닙니다
"AI 기반 공격"이라는 표현 때문에 방어용 새 AI 제품을 찾게 됩니다. 기본 통제는 노출된 키와 권한 부여 결함에 따른 위험을 줄일 수 있으며, 일부 사례에는 제로데이도 관련되어 있었습니다. 알려진 약점을 해결하고 침해에도 대비하십시오. 소규모 운영자가 시간이 제한되어 있다면, 가장 큰 효과는 패치까지 걸리는 시간, API 권한 부여, 키 보관 위치에서 얻을 수 있습니다.
AI를 사용하는 사람에게는 새로운 과제도 있습니다. 에이전트는 읽은 텍스트를 따를 수 있고, 부여된 권한 안에서 행동합니다. 내부에서 에이전트나 MCP 서버를 사용하기 전에 어떤 키를 줄지, 어떤 작업에 사람의 승인이 필요한지 정하십시오.
이 페이지의 업데이트 방식
새로운 AI 관련 공격이 공개되면 보안 속보에 첫 보고서를 게시하고, 이 페이지의 표와 연표에 추가합니다. 각 사고의 사실관계는 개별 보고서가 기준이며, 이 페이지는 유형과 방어 순서를 요약합니다.
출처 (공개 기록)
- JPCERT/CC, 일본 조직 대상 최근 무단 접근 경보 (JPCERT-AT-2026-0030, 2026년 10월 8일 게시, 10월 9일 및 10월 23일 업데이트; 일본어) — jpcert.or.jp
- JPCERT/CC Eyes, 지속 중인 침입의 공격 방식 분석 (2026년 10월 15일; 일본어) — blogs.jpcert.or.jp
- IPA, 무단 접근 사고에 비추어 신속히 취해야 할 조치 (2026년 10월 9일, 필요 시 업데이트; 일본어) — ipa.go.jp
- 한 위협 인텔리전스 기업 연구팀의 보고서 (2026년 10월 20일 게시, 10월 23일 업데이트) — socradar.io
- 일본 보안 기업의 분석 (2026년 10월 7일; 공공기관 문서가 아님; 일본어) — 10월 7일 분석
- OWASP Gen AI Security Project, "LLM01:2025 Prompt Injection" — genai.owasp.org
- Model Context Protocol, "Security Best Practices" (명세 2025-11-25) — modelcontextprotocol.io
- 각 사례의 공식 공지는 위에 연결된 보고서의 출처 항목에 나열되어 있습니다.
변경 기록
2026-10-24: "새로운 점과 새롭지 않은 점"에 사람이 승인하고 AI가 실행하는 구조, 재사용된 비밀번호 하나로 여러 플랫폼이 열린 사례(10월 20일 위협 인텔리전스 기업 보고서)를 추가했습니다.
2026-10-24: 첫 번째 버전. 2026년 7월–10월 공개 사례를 네 가지 유형으로 분류하고, JPCERT/CC, IPA, OWASP, MCP 명세에 따른 방어 순서를 정리했습니다.
다음으로 읽을거리
- 일본의 침입 사태: 일본 무단 접근 경보(2026년 10월): 이번 주 점검 사항과 이상을 발견했을 때 할 일
- AI 에이전트 사례: 실제 웹사이트에 접근하는 AI 에이전트와 사이트 운영자가 할 일
- AI 공급망: LiteLLM 1.107.0의 자격 증명 탈취 악성코드
- 도구에서 탈취된 AI 제공업체 키: OpenCode Console 침해 (2026년 10월)
- 기본부터 순서대로: AI 시대 보안 체크리스트 (우선순위순)
- 용어 정리: SSRF란 무엇인가? / 섀도 AI란 무엇인가?