앤트로픽은 2025년 11월 13일, '높은 신뢰도'로 중국 국가배후 그룹이라고 평가한 GTG-1002가 앤트로픽의 AI 코딩 에이전트에 전술 작업의 80~90%를 맡겨 약 30곳을 노렸고, 정점에서는 수천 건의 요청을 종종 초당 여러 건씩 보냈다고 공개했다. 탈레스의 2026년판 봇 보고서(업체 조사)에 따르면 2025년 관측된 웹 트래픽의 53%가 봇이었고, 봇 공격의 27%가 API 엔드포인트를 겨냥했다.
AI 에이전트 공격은 공격자가 AI 에이전트에게 정찰, 취약점 탐색, 인증 시도를 맡겨 사람보다 빠르고 넓게, 지치지 않고 반복하게 하는 공격이다. GTG-1002와 앤트로픽 평가 사고의 전체 경위는 AI 해킹 사고 사례 2026에 정리했다. 이 글은 이런 공격이 웹·API 방어에서 무엇을 바꿨는지 1차 자료로 확인하고, 그 자료에 나온 공격 행동과 맞닿은 빈틈 7가지를 OWASP API Security Top 10 2023판 항목에 맞춘 자가점검으로 묶었다.
1차 자료를 모아 보면 AI가 바꾼 것은 공격 기법이 아니라 시도의 속도와 횟수였고, 먼저 뚫린 곳은 인증이 빠진 기능, 인터넷에 열린 관리·디버그 화면, 약한 비밀번호 같은 기본 빈틈이었다. 웹서비스와 API를 운영한다면 API 목록에 없는 엔드포인트가 있는지, 식별자만 바꿔도 남의 데이터가 열리는지, 로그인·OTP에 시도 제한이 있는지부터 확인한다.
왜 중요한가: AI 에이전트가 바꾼 것은 속도, 규모, 반복이다
IBM 사이버보안 서비스 글로벌 매니징 파트너 마크 휴즈는 2026년 2월 25일 X-Force 위협 지수를 발표하며 "공격자는 플레이북을 새로 만드는 것이 아니라 AI로 속도를 높이고 있다"고 말했다. 탈레스 보고서도 AI가 완전히 새로운 공격 범주를 만들기보다 기존 자동화를 가속하고 다듬고 있다고 적었다. 달라진 것은 세 가지다.
- 속도: GTG-1002 보고서가 예로 든 취약점 발견·악용 흐름에서 AI는 서비스·엔드포인트 목록화, SSRF 취약점 식별, 공격 코드 작성과 콜백 검증, 초기 침투까지 1~4시간 동안 스스로 진행했고, 사람 운영자는 2~10분 동안 결과를 검토하고 악용을 승인했다. 앤트로픽은 AI가 '물리적으로 불가능한 요청 속도'로 전술 작업을 수행했다고 표현했다.
- 규모: GTG-1002의 AI는 MCP로 연결한 브라우저 자동화 등으로 여러 표적의 인프라를 동시에 목록화하고 인증 방식을 분석했으며, 표적별 작업 맥락을 따로 유지하면서 수백 개의 서비스와 엔드포인트를 스스로 정리했다. 탈레스가 차단한 AI 기반 봇 공격은 2025년 전년의 12.5배로 늘어 하루 평균 2,500만 건이 됐다. 다만 이 수치에는 '2025년 AI 봇 커버리지 확대'라는 각주가 붙어 있어 전부를 실제 공격 증가로 보기는 어렵다.
- 지치지 않는 반복: GTG-1002의 AI는 며칠에 걸친 세션 사이에서도 작업 맥락을 유지해, 사람이 진행 상황을 다시 정리하지 않아도 캠페인을 이어 갔다. 탈레스 분석팀은 차단 조치를 배포한 지 몇 시간 안에 행동을 바꾸는 봇을 관찰했고, 다른 엔드포인트와 업무 흐름을 바꿔 가며 통하는 경로를 찾을 때까지 되돌아오는 캠페인도 자주 봤다. 체크포인트(2025년 9월 2일)에 따르면 레드팀·보안 연구자용으로 공개된 프레임워크 HexStrike-AI는 AI 에이전트가 150개 넘는 보안 도구를 자율 실행하고 실패해도 작업을 이어 가는 재시도 로직을 갖췄으며, 공개 직후 지하 채널에서 8월 26일 공개된 시트릭스 NetScaler 취약점 공격에 쓰자는 논의가 나왔다.
한계도 있다. 앤트로픽은 AI가 성과를 자주 부풀리고 가끔 데이터를 지어내, 작동하지 않는 자격증명을 얻었다고 주장하거나 공개 정보를 중요한 발견이라고 보고했기 때문에 공격자가 모든 결과를 다시 검증해야 했다고 밝혔다. 보고서는 이것이 완전 자율 공격을 가로막는 장애물로 남아 있다고 봤다.
근거: AI가 관여한 공격과 사고에서 뚫린 곳은 기본 빈틈이었다
- 포티게이트 600여 대(아마존, 2026년 2월 20일): 여러 상용 생성형 AI 서비스를 쓴 금전 목적 행위자가 55개국 이상에서 포티게이트 600대 이상을 장악했지만 포티게이트 취약점 악용은 관측되지 않았고, 통로는 노출된 관리 포트와 단일 인증의 약한 자격증명이었다. 경위는 포티게이트 600여 대 해킹 분석에 정리했다.
- 공개 애플리케이션 악용 44% 증가(IBM, 2026년 2월 25일, 업체 조사): IBM X-Force는 공개 애플리케이션 악용으로 시작한 공격이 전년보다 44% 늘었고, 주된 원인이 "인증 통제 누락과 AI 기반 취약점 탐색"이라고 밝혔다. 2025년 X-Force가 관찰한 사고의 40%는 취약점 악용이 원인으로 1위였고, 공개된 취약점의 56%는 인증 없이 악용할 수 있었다. 휴즈는 "자격증명이 필요 없는 취약점이 이렇게 많으니 공격자는 사람을 거치지 않고 스캔에서 곧바로 피해로 넘어갈 수 있다"고 했다.
- 앤트로픽 평가 사고(2026년 7월 30일 공개): 평가 환경의 설정 오류로 실제 인터넷에 닿은 앤트로픽의 AI 모델들이 실제 조직 3곳에 무단 접근했다. 앤트로픽은 모델들이 약한 비밀번호, 인증 없는 엔드포인트, 노출된 디버그 페이지의 자격증명 같은 기본 기법을 썼고 복잡한 취약점은 찾지도 쓰지도 않았다고 밝혔다.
- 봇 공격(탈레스, 업체 조사): 탈레스는 2025년 가장 피해가 컸던 봇 공격이 소프트웨어 취약점이 아니라 애플리케이션이 설계된 방식을 악용했다고 했다. 로그인, 검색, 예약, 결제, 포인트 시스템이 "유효한 요청을 비정상적인 규모와 빈도로" 실행하는 방식으로 거듭 악용됐다. API 공격에서도 요청은 형식이 올바르고 인증까지 통과하는 경우가 많아 악성으로 보이지 않는다. API를 노린 공격 유형은 데이터 유출(26%), 업무 로직 악용(13%), 원격 코드 실행·원격 파일 포함(13%) 순이었다.
원인: 방어가 사람의 속도를 전제로 설계됐다
AI 에이전트가 새 취약점을 만든 것은 아니다. 남아 있던 빈틈을 사람보다 빠르고 끈질기게 찾을 뿐이다. 1차 자료가 짚는 원인은 네 가지다.
- 목록에 없는 API: NIST SP 800-228은 다른 자산 관리가 성숙한 조직도 대부분 API 목록에 빈틈이 있다고 본다. 디버깅·테스트용으로 만들어 보안 검토를 건너뛴 섀도 API와, 대체됐지만 아직 내리지 못한 좀비 API가 대표적이다.
- 사람 기준의 시도 제한: NIST는 서비스 전체 부하 기준의 속도 제한은 효과가 적다며, 출발지 IP나 사용자 자격증명을 기준으로 사용자별 한도를 걸라고 권고한다. 탈레스는 IP 평판, User-Agent 문자열, 단순 속도 제한에만 기대는 방식은 더 이상 충분하지 않다고 했다. 2025년 나쁜 봇 트래픽의 41%가 자신을 크롬 브라우저라고 밝혔다.
- 자동화를 계산하지 않은 업무 흐름: OWASP는 API6을 자동화로 과도하게 쓰일 때 사업에 해가 되는 점을 보완하지 않은 채 업무 흐름을 노출한 상태로 정의하고, 구현 버그에서만 생기는 문제가 아니라고 적었다.
- 잘못 설정된 접근 통제: IBM X-Force Red 모의해킹에서 가장 흔한 진입점이 이것이었다.
AI 에이전트 공격 대비 웹·API 자가점검 7가지
아래 7개 질문에 예/아니오로 답한다. 기준은 OWASP API Security Top 10 2023판의 항목 정의와 예방 방법, NIST SP 800-228(2025년 6월 발행, 2026년 3월 13일 부록 추가), KISA의 '최근 사이버공격 대비 기업 보안강화 권고'(2026년 10월 3일)다. '아니오'인 항목부터 조치한다.
| 점검 | OWASP API Top 10(2023) | 1차 자료에 나온 행동(공격·평가 사고) |
|---|---|---|
| 1. API 목록 | API9 Improper Inventory Management | 서비스·엔드포인트 수백 개 목록화(GTG-1002) |
| 2. 객체 권한 | API1 Broken Object Level Authorization | 2025년 봇 공격 유형 중 BOLA 등 API 위반 24%(탈레스) |
| 3. 인증 시도 | API2 Broken Authentication | 약한 비밀번호 악용(앤트로픽 평가 사고), 수집한 자격증명을 내부 API에 대입(GTG-1002) |
| 4. 자원 소비 | API4 Unrestricted Resource Consumption | OTP 요청 반복으로 문자 요금 유발(탈레스 사례) |
| 5. 업무 흐름 | API6 Unrestricted Access to Sensitive Business Flows | 유효한 요청을 비정상 규모로 반복(탈레스) |
| 6. 서버 측 요청 | API7 Server Side Request Forgery | SSRF 식별과 콜백 검증, 메타데이터 엔드포인트 탐색(GTG-1002) |
| 7. 설정·오류 노출 | API8 Security Misconfiguration | 노출된 디버그 페이지에서 자격증명 획득(앤트로픽 평가 사고) |
1. 문서에 없는 API와 구버전 엔드포인트까지 목록에 있는가
OWASP는 API9:2023 Improper Inventory Management를 설명하며, API는 전통적인 웹 앱보다 엔드포인트를 더 많이 노출하므로 호스트와 배포된 API 버전의 목록이 있어야 구버전 API와 노출된 디버그 엔드포인트 문제를 줄일 수 있다고 적었다. OWASP 예시 시나리오에서는 정식 API 앞단에만 있던 재설정 토큰 대입 제한이 같은 API를 돌리는 베타 호스트에는 없어, 6자리 토큰 대입만으로 아무 사용자의 비밀번호나 재설정할 수 있었다. 호스트마다 운영 환경(운영·스테이징·테스트·개발), 접근 대상(공개·내부·파트너), API 버전을 적고 버전별 폐기 계획을 둔다. NIST SP 800-228은 섀도·좀비 API까지 포함한 전사 API 목록을 유지하고, API 탐색 도구와 정기 자동 스캔으로 실제 돌고 있는 API를 찾으라고 권고한다(REC-API-4.2·4.3). KISA 권고도 담당자가 지정되지 않은 자산과 시험용·미사용 서비스를 정리하라고 했다. 운영 데이터를 쓰는 비운영 API는 운영 API와 같은 수준으로 보호한다(OWASP).
2. 객체 ID만 바꿔도 남의 데이터가 열리지 않는가
API1:2023 Broken Object Level Authorization은 요청 속 객체 ID를 바꿔 다른 사용자의 객체에 접근하는 문제다. OWASP는 ID가 순차 정수든 UUID든 경로, 쿼리, 헤더, 본문 어디에 있어도 쉽게 찾을 수 있고, 서버 응답만 봐도 성공 여부를 알 수 있다고 설명한다. OWASP 예시에서는 간단한 스크립트로 상점 이름만 바꿔 수천 개 상점의 매출 데이터를 가져간다. KISA 권고는 별도 시험 계정으로 문서번호·사용자번호 같은 요청값을 바꿔 다른 사용자의 정보가 조회·수정되는지 확인하라고 했다. 객체 ID를 받아 동작하는 모든 엔드포인트에서 서버가 로그인한 사용자에게 그 객체에 대한 그 동작의 권한이 있는지 확인해야 한다. OWASP는 세션의 사용자 ID와 요청 속 ID를 비교하는 것만으로는 일부 경우만 막는다고 경고하고, 레코드 ID에는 예측하기 어려운 무작위 값을 쓰되 권한 검증 테스트를 만들어 실패하면 배포하지 말라고 권한다. 무작위 ID는 열거를 어렵게 할 뿐 권한 검증을 대신하지 않는다. 기본 점검 방법과, 이 글에서 뺀 응답의 과도한 데이터 노출(API3)·관리자 기능 무단 호출(API5) 점검은 API 보안 취약점 점검 가이드에 정리했다.
3. 로그인·OTP·비밀번호 재설정·토큰 발급에 시도 제한과 MFA가 있는가
API2:2023 Broken Authentication에서 OWASP는 인증 엔드포인트와 흐름 자체를 보호할 자산으로 보고, 비밀번호 찾기·재설정도 로그인과 같은 수준으로 다루라고 한다. 크리덴셜 스터핑이나 캡차·계정 잠금 없는 대입을 허용하거나, 약한 비밀번호를 받아들이거나, 토큰의 진위·만료를 검증하지 않거나, 서명 없는 JWT(alg: none)를 받아들이면 취약하다. 무차별 대입 방어는 일반 API 속도 제한보다 엄격해야 하고, GraphQL 일괄 요청처럼 한 요청에 로그인 시도 여러 개를 묶어 속도 제한을 피하는 경로도 막아야 한다. OTP 검증과 비밀번호 재설정 요청도 사용자별 실행 횟수를 제한한다(OWASP API4). NIST SP 800-228(REC-API-11-1)은 반복 실패 시 속도 제한과 계정 잠금, MFA, 봇 탐지와 캡차, 위험 기반 적응형 인증, 유출 자격증명 대조를 함께 권한다. 탈레스 보고서에서 계정 탈취 공격은 2025년 7월에 전년 같은 달보다 70% 늘었다. 탈레스는 주거용·모바일 프록시로 정상 사용자 회선을 거치는 봇이 IP 기반 탐지를 무디게 한다고 했으므로, 시도 제한은 계정, IP, 기기 단위로 따로 건다.
4. 요청량·페이지 크기·비용이 드는 호출에 상한이 있는가
API4:2023 Unrestricted Resource Consumption은 실행 시간, 메모리, 업로드 크기, 한 요청 안의 작업 수(GraphQL 일괄 처리 등), 한 번에 돌려주는 레코드 수, 외부 서비스 지출 한도 가운데 하나라도 없거나 부적절하면 취약하다고 본다. OWASP 예시에서는 건당 0.05달러인 문자 발송을 부르는 비밀번호 찾기 API를 스크립트가 수만 번 호출해 몇 분 만에 수천 달러 손실이 난다. 탈레스 보고서에는 봇이 인증 API로 OTP 요청을 반복해 20일 동안 약 30만 달러의 문자 요금이 나온 글로벌 건강보험사 사례(업체 사례)가 있다. NIST는 페이지 크기 상한(일반 사용자의 항목이 100개라면 페이지당 최대 1,000개), 조회 기간 제한, 외부 API 소비 하드 리밋을 예로 들고, AI를 도입한 조직이 비싼 AI API를 뜻하지 않게 과다 사용해 큰 예상 밖 비용을 떠안는 일이 흔하다고 적었다. KISA 권고도 계정·인증토큰별 호출 횟수, 조회 기간, 반환 건수, 다운로드 용량에 업무 특성에 맞는 제한을 걸라고 했다. 서비스에 LLM 호출 기능이 있다면 그 호출도 사용자별 한도에 넣고, 지출 한도를 걸 수 없는 연동에는 결제 알림이라도 둔다(OWASP).
5. 가입·쿠폰·예약·결제 흐름의 자동화 남용을 제한하는가
API6:2023 Unrestricted Access to Sensitive Business Flows의 OWASP 예시는 한정 상품 재고 싹쓸이, 항공 좌석 90% 예약 뒤 일괄 취소, 가입 자동화로 추천 보상 쌓기다. OWASP는 먼저 사업 쪽에서 과도하게 쓰이면 해가 되는 흐름을 고르고, 기술 쪽에서 맞는 보호 수단을 고르는 두 단계를 권한다. 수단으로는 헤드리스 브라우저 같은 예상 밖 기기를 거르는 기기 지문, 캡차 같은 사람 확인, '장바구니 담기에서 결제 완료까지 1초 미만' 같은 비인간 패턴 분석, 토르 출구 노드·알려진 프록시 IP 차단을 들고, 개발자·B2B용처럼 기계가 직접 쓰는 API가 쉬운 표적이라고 했다. 탈레스는 AI가 캡차 풀이와 상호작용 간격 조정, 지문 회피를 돕는다고 했으므로 한 가지 수단에 기대지 않는다. 탈레스는 개별 페이지나 엔드포인트가 아니라 업무 로직 자체를 보호 대상으로 삼고, 정상 사용이 어떤 모습인지부터 이해하라고 권했다. 계정당 쿠폰 수, 기간당 예약 수처럼 흐름별 한도를 업무 규칙으로 먼저 적는다.
6. URL을 받아 서버가 가져오는 기능의 목적지를 제한하는가
API7:2023 Server Side Request Forgery는 API가 사용자가 준 URI를 검증하지 않고 원격 자원을 가져올 때 생긴다. OWASP는 웹훅, URL로 파일 가져오기, 맞춤 SSO, URL 미리보기가 이런 기능을 흔하게 만들고, 클라우드·쿠버네티스·도커가 관리 채널을 예측 가능한 HTTP 경로로 열어 두어 위험이 커진다고 설명한다. GTG-1002 보고서의 예시 흐름에서도 AI는 SSRF 취약점을 찾아 콜백으로 악용 가능성을 확인했고, 침투 뒤에는 내부 서비스와 관리 인터페이스, 메타데이터 엔드포인트를 찾았다. 링크 요약이나 문서 가져오기처럼 URL을 받는 AI 기능도 같은 점검 대상이다. OWASP는 가져오기 기능을 내부망과 분리하고, 허용할 원격 출처·URL 스킴·포트·미디어 유형을 허용 목록으로 정하고, HTTP 리다이렉트를 끄고, 검증된 URL 파서를 쓰고, 원격 응답 원문을 사용자에게 그대로 돌려주지 말라고 권한다. KISA 권고도 외부 URL을 가져오는 기능은 허용된 목적지·프로토콜로만 통신하게 하고, 내부 관리 서비스와 클라우드 인증정보 제공 경로에 닿지 못하게 하라고 했다. AI 에이전트 도구에서 같은 결함이 나온 사례는 MCP 보안 SSRF 점검에 정리했다.
7. 오류 응답·디버그·관리 기능이 밖에서 보이지 않는가
API8:2023 Security Misconfiguration에서 OWASP는 공격자가 패치 안 된 결함, 흔한 엔드포인트, 안전하지 않은 기본 설정으로 도는 서비스, 보호되지 않은 파일·디렉터리를 찾으려 하고, 불필요한 서비스나 레거시 옵션을 찾아 악용하는 자동화 도구가 이미 있다고 설명한다. 취약 조건에는 스택 트레이스나 민감 정보를 담은 오류 메시지, 불필요한 HTTP 메서드와 로그 기능, 빠지거나 잘못된 CORS 정책, 최신 보안 패치 누락이 들어간다. 오류 응답을 포함한 모든 응답의 스키마를 정의해 예외 추적 정보가 밖으로 나가지 않게 하고(OWASP), 오류 메시지에 소프트웨어의 정확한 버전이나 내부 시스템 이름을 남기지 않는다(NIST). NIST는 권한 없는 자원에 403, 없는 자원에 404를 돌려주면 공격자가 자원의 존재 여부를 구분해 열거할 수 있다고 지적한다. 권한 없는 자원을 요청해도 없는 자원과 같은 응답(예: 404)이 오는지 확인한다. KISA 권고대로 웹 공개 경로에 환경설정 파일, 소스코드 저장소 정보, 백업 파일, 상세 오류정보가 노출되는지 점검하고, 관리자 페이지와 관리용 접속 기능은 업무상 필요한 대상과 지정된 경로에서만 열리게 한다. 체크포인트는 악용까지 걸리는 시간이 시간 단위라면 패치에 몇 주를 쓸 수 없다고 했다.
탐지: 사람 속도를 넘는 반복에 경보를 건다
NIST SP 800-228은 API 게이트웨이가 누가 어떤 메서드로 어디서 호출했는지, API·엔드포인트별 요청률·오류율·지연, 인증·인가 실패로 거부되거나 속도 제한에 막힌 요청 같은 정책별 집행 결과를 남기도록 권한다(REC-API-18). 사용자 자격증명이나 네트워크 주소 단위로 세밀하게 차단하는 기능도 함께 두라고 한다(REC-API-17). KISA 권고도 식별자를 바꾼 연속 조회와 접근 거부 뒤 다른 경로로 하는 조회를 감시하고, 단시간 탐지와 장시간 누적 분석을 함께 돌리라고 했다. 토큰 하나가 순차 ID를 훑거나, 인증·인가 실패나 속도 제한으로 거부된 뒤에도 같은 출처가 경로를 바꿔 시도를 이어 가는 패턴이 여기에 해당한다. 권한 없는 요청을 404로 통일했다면 응답 코드 대신 서버의 인가 거부 기록으로 센다. 탈레스는 행동 분석, 세션 일관성, 업무 흐름의 과거 패턴을 함께 봐야 한다고 했다. 자율 침투 도구의 탐지 규칙과 SIEM 적용 순서는 ARTEX 한국어판 탐지 규칙과 한계에 정리했다.
정상 AI 에이전트는 서명으로 가려내되 차단 기준으로 쓰지 않는다
탈레스는 사용자를 대신해 데이터를 가져오고 작업하는 AI 에이전트를 좋은 봇, 나쁜 봇에 이은 세 번째 자동화 트래픽으로 분류했다. 이를 가려내려는 방식이 봇과 에이전트가 HTTP 메시지 서명(RFC 9421)으로 자기 요청에 서명하는 Web Bot Auth다. 클라우드플레어는 2025년 5월 15일 이 방식을 제안했고, 8월 28일에는 사용자 지시로 움직이는 에이전트를 '서명된 에이전트(signed agents)'로 따로 분류하기 시작했다. IETF에서는 Web Bot Auth 워킹그룹이 표준화를 진행 중이고, 2026년 9월 1일 워킹그룹 초안이 나왔다. 아직 RFC는 아니다.
다만 서명에는 한계가 있다. 이 초안은 서명 없는 요청을 받은 검증자는 보낸 쪽이 자동화인지, 사람인지, 회피 중인지조차 알 수 없고, 신호가 없다는 것은 보내지 않은 쪽에 대한 증거가 아니라고 적었다. 서명은 그 키를 공개한 주소의 주인이 서명했다는 사실만 알려 줄 뿐 운영자가 정직하다는 뜻도 아니다. 탈레스도 공격자가 AI 에이전트임을 밝히지 않는 자체 호스팅·변형 LLM을 쓸 수 있어 탐지 가능한 AI 트래픽은 일부일 뿐이라고 했다. 서명은 허용할 정상 에이전트를 분리하는 데 쓰고, 서명 없는 트래픽은 위의 7가지 통제로 다룬다. 탈레스는 지속적인 모니터링 없는 허용 목록은 더 이상 통하지 않는다고 했으므로, 서명된 에이전트에도 로그인·결제 같은 흐름의 한도는 똑같이 건다.
인증·권한·업무 흐름의 빈틈을 공격자보다 먼저 확인하기
보안 전문 기업 SENTRIX의 AI 심화 취약점 진단 가운데 '일반 웹·API의 공격 경로 검증'은 AI 점검 도구와 전문가가 로그인·권한·결제 흐름을 검증하며, LLM 기능이 없는 일반 웹·API도 진단할 수 있다. 합의한 대상의 노출·구성 정보 수집과 취약점 후보 정리는 자동화가 넓게 맡고, 다른 사용자의 주문에 접근하는 권한 문제, 결제·업무 로직 악용, 관리 기능 노출 같은 후보는 레드팀이 서비스 맥락에서 재현 조건과 영향을 확인해 수정 방향과 재점검 기록으로 남긴다. 재점검 범위와 횟수는 계약 때 정하며, 모든 취약점을 찾아낸다고 보장하는 서비스는 아니다. 자가점검 2·3·5·7번처럼 권한, 인증, 업무 흐름, 관리 기능에서 '아니오'가 나온 항목이 있다면 AI 에이전트가 두드리기 전에 그 경로부터 확인하세요. 진단 문의하기
참고 자료
- 앤트로픽, Disrupting the first reported AI-orchestrated cyber espionage campaign(2025-11-13)·전체 보고서 PDF(2025-11-17 갱신)
- 앤트로픽, Investigating three incidents in our cybersecurity evaluations(2026-07-30)
- 아마존 AWS 보안 블로그, AI-augmented threat actor accesses FortiGate devices at scale(2026-02-20)
- IBM, IBM 2026 X-Force Threat Index: AI-Driven Attacks are Escalating as Basic Security Gaps Leave Enterprises Exposed(2026-02-25)·X-Force Threat Intelligence Index 2026 보고서 페이지(2026-02-25, 업체 조사)
- 탈레스(임퍼바), 2026 Thales Bad Bot Report(2026-04-28, 업체 조사)
- 체크포인트, Hexstrike-AI: When LLMs Meet Zero-Day Exploitation(2025-09-02)
- OWASP, OWASP Top 10 API Security Risks 2023·API1·API2·API4·API6·API7·API8·API9(2023년판)
- NIST, SP 800-228 Guidelines for API Protection for Cloud-Native Systems(2025-06-27 발행, 2026-03-13 개정)
- KISA 보호나라, 최근 사이버공격 대비 기업 보안강화 권고(2026-10-03)
- 클라우드플레어, Forget IPs: using cryptography to verify bot and agent traffic(2025-05-15)·The age of agents: cryptographically recognizing agent traffic(2025-08-28)
- IETF Web Bot Auth 워킹그룹, HTTP Message Signatures for automated traffic(draft-ietf-webbotauth-httpsig-protocol-00)(2026-09-01, 인터넷 초안)