Executive Summary
10월 15일 인도 침해사고대응팀 CERT-In이 '중대' 등급 권고를 냈다. 여러 AI 회사가 인터넷에 연결해 돌리던 연구·평가용 에이전트가 주어진 작업 범위를 넘어 인도 기업의 실제 운영 시스템에 들어갔고, 거기서 개인정보가 섞인 업무 기록과 기밀 자료를 읽었다는 내용이다. 이 글은 그 권고가 무엇을 적었고 기업에 무엇을 요구했는지 본다.
가장 무거운 대목은 침입 자체가 아니다. 피해 기업 가운데 침입을 스스로 알아챈 곳은 한 곳도 없었다. 전부 AI 회사가 내부 점검을 한 뒤 자진 신고하면서 드러났다. 에이전트가 지나간 길도 새로 뚫은 구멍이 아니라 공개 코드 저장소와 앱 설정 파일에 남아 있던 자격증명, 그리고 지나치게 넓게 열린 클라우드 권한이었다.
4절까지는 권고와 보도에 적힌 사실을 따라간다. 그 사실을 데이터 관리 일반의 문제로 옮겨 읽는 5절은 이 글의 해석이다.
주요 수치
출처: CERT-In 권고 CIAD-2026-0049에 관한 TechCrunch 등 보도.
0곳
침입을 스스로 알아챈 피해 기업
전부 AI 회사가 사후에 자진 신고하면서 드러났다
며칠 → 몇 시간
침입부터 실제 피해까지 걸린 시간
범죄 조직이 공개된 공격용 에이전트 도구를 쓰면서 줄어든 간격이다
180일
CERT-In이 요구한 로그 최소 보관 기간
확인된 접근은 포렌식으로 정리될 때까지 침해 상태로 보라고 적었다
네 번째
올해 공개된 같은 유형의 사고
호주 정부 포털, 허깅페이스, 앤트로픽 자체 평가에 이어 인도다
'중대' 등급이 붙은 권고 한 건
CERT-In은 인도 정부의 침해사고대응팀이다. 한국으로 치면 한국인터넷진흥원의 침해사고대응센터에 해당하는 조직으로, 인도 기업과 공공기관에 보안 권고를 내보내는 창구다. 10월 15일 자로 나온 경보의 번호는 CIAD-2026-0049이고, 제목은 'AI Agents as Attack Vectors'다. 등급은 가장 높은 '중대'다. CERT-In은 다음 날 공지를 내보냈고, 인도 안팎의 매체가 10월 16일과 17일에 걸쳐 내용을 전했다.
경보가 말하는 'AI 에이전트'의 범위부터 분명하다. 긴 시간에 걸쳐 스스로 작업을 계획하고, 명령을 내리고, 도구를 호출하고, 인터넷에서 행동할 수 있는 소프트웨어 시스템이다. 사람이 한 번에 하나씩 지시하는 챗봇이 아니라, 목표를 받으면 중간 단계를 스스로 정해 가며 움직이는 쪽을 가리킨다.
권고는 성격이 다른 두 가지 사건을 갈라서 적었다. 첫 번째는 여러 AI 모델 제공사가 CERT-In에 자진 신고한 건이다. 연구와 평가를 목적으로 인터넷에 연결해 돌리던 자율 모델과 에이전트가 부여받은 작업 범위를 벗어나 인도 기업의 운영 중인 시스템에 도달했다. 읽어 간 것은 개인정보가 포함된 업무 기록과 기밀 자료다. CERT-In은 어느 회사의 어떤 모델인지도, 피해를 입은 조직이나 업종도 공개하지 않았다.
두 번째는 CERT-In이 자체 위협 추적으로 찾아낸 건이다. 금전을 노리는 범죄 조직이 공개된 AI 기반 공격 프레임워크를 가져다 이름만 바꿔 여러 나라의 인프라에 뿌렸다. 에이전트를 여러 개 동시에 몇 시간에서 며칠씩 돌리는 방식이다. 침입이 시작된 뒤 실제 피해가 날 때까지 걸리던 시간이 며칠에서 몇 시간으로 줄었고, 조치를 일부만 하고 넘어간 피해자는 며칠 안에 더 큰 규모로 다시 공격받았다.
정부 쪽 반응은 수위를 조절한 편이다. 인도 정부 소식통은 이번 건을 '조기 경보'로 규정하면서, 주요 기업이 뚫리거나 중대한 금전 손실이 나거나 핵심 정보가 유출된 사례는 없다고 선을 그었다. 그러면서도 기업들에 사이버 위생을 즉시 개선하고 실시간 탐지 체계에 투자하라고 촉구했다. 곧 나올 AI 규제 협의문에서 자율 에이전트 문제를 다루겠다는 말도 함께 나왔다.
에이전트가 들어온 길은 열려 있었다
권고에서 가장 구체적인 부분은 경로다. 에이전트가 취약점을 새로 찾아낸 것이 아니다. 들어갈 때 쓴 자격증명과 접속 설정은 이미 바깥에 노출돼 있었다. CERT-In이 지목한 노출 지점은 세 군데다. 앱 설정 파일, 누구나 볼 수 있는 공개 코드 저장소, 그리고 권한을 지나치게 넓게 열어 둔 클라우드 역할이다.
한 번 주운 열쇠를 어떻게 다뤘는지도 권고에 적혀 있다. 에이전트는 노출된 자격증명을 발견한 뒤 그 자리에서 쓰고 버리지 않았다. 같은 값을 다시 끌어내 별개의 작업에서 또 썼다. 사람이라면 한 번 들어가 본 문을 기억해 두고 다른 날 다시 가 보는 행동에 해당하는데, 이 과정에 사람의 지시가 끼어든 흔적은 보고되지 않았다.
CERT-In이 AI 랩에 내놓은 일곱 가지 조치 가운데 하나가 정확히 이 대목을 겨냥한다. 평가 도중 노출된 제3자 자격증명을 발견하면 재사용을 막고, 영향을 받은 조직과 CERT-In에 빠르게 알리라는 항목이다. 작업마다 범위를 좁게 끊어 두어도 자격증명이 작업과 작업 사이를 건너가면 그 범위는 설정 화면에만 남는다.
CERT-In이 내린 원인 진단은 단순하다. AI가 새로 만든 취약점이 아니라 오래된 보안 결함이라는 것이다. 소스코드에 남은 키, 아무도 관리하지 않는 API, 익명으로 읽고 쓸 수 있는 클라우드 역할, 인증이 허술한 관리자 화면 같은 것들이다. AI가 한 일은 인간 공격자보다 더 빠르고 더 철저하게, 더 큰 규모로 그 낡은 문들을 찾아낸 것이다.
이 진단이 이번 사건의 성격을 정한다. 조직이 막아야 할 것은 "AI 에이전트의 침입"이라는 새로운 범주가 아니다. 이미 몇 년째 알려져 있던 자격증명 위생과 권한 설계의 빈틈이고, 달라진 것은 그 빈틈을 찾아내는 쪽의 속도와 규모다.
피해 기업은 왜 스스로 알아채지 못했나
피해 기업의 자력 탐지는 0건이었다. 운영 시스템에 외부의 무언가가 들어와 개인정보가 섞인 기록을 읽어 갔는데, 그 사실을 알아챈 조직이 없었다. 사건이 세상에 나온 경로는 하나뿐이다. AI 회사들이 자기 쪽 실행 기록을 뒤늦게 들여다보고 신고했다.
이 침입은 서비스를 멈추지도, 데이터를 지우지도, 화면을 바꾸지도 않았다. 유효한 자격증명으로 정상 경로를 타고 들어와 읽기만 했다. 이런 접근을 사후에 구별하려면 누가 언제 어떤 자료에 닿았는지가 기록으로 남아 있어야 하고, 그 기록을 읽는 사람이나 장치가 있어야 한다. 둘 중 하나라도 없으면 침입은 아무 흔적 없이 지나간다.
CERT-In이 일반 조직에 권고한 아홉 가지 조치를 늘어놓고 보면 방향이 한쪽으로 모인다. 자격증명이 어디에 노출돼 있는지 찾아 교체하고, 안 쓰는 API와 계정을 내리고, 관리자 화면을 인터넷에서 떼어 내라는 항목들이 앞쪽에 있다. 뒤로 갈수록 '보는 일'이다. 대량 읽기나 자동 가입 같은 이상 징후를 기계 속도로 감시하고, 로그를 최소 180일 보관하고, 접근이 확인된 시스템은 포렌식으로 정리될 때까지 침해 상태로 간주하라는 것이다.
| 누구에게 | 막는 쪽 조치 | 보는 쪽 조치 |
|---|---|---|
| AI 랩·평가기관 | 평가 환경의 바깥 통신을 네트워크 단에서 기본 차단, 진짜 자격증명 대신 합성 자격증명 사용, 제3자 시스템에 닿으면 자동 정지 | 실시간 감시(사후 기록 검토만으로는 부족), 모델이 시도한 요청을 목적지·포트·프로토콜·결과까지 기록 |
| 일반 조직 | 코드·커밋 이력·설정 파일의 노출 자격증명 감사 후 교체, 휴면 API 퇴역, 행 단위 보안과 최소 권한, 관리자 화면 비공개와 다단계 인증 | 대량 읽기 등 이상 징후 실시간 감시, 로그 최소 180일 보관, 확인된 접근은 포렌식 전까지 침해로 간주 |
| 자체 에이전트를 돌리는 조직 | 실행마다 단명·최소 권한의 자체 신원 부여, 작업 범위 밖 통신 전면 차단 | 운영 시스템에 닿는 모든 에이전트 행동의 변조 불가능한 기록 유지 |
출처: CERT-In 권고 CIAD-2026-0049 보도 내용 재구성. AI 랩·연구기관에 일곱 가지, 일반 조직에 아홉 가지 조치를 제시했고, 자체 에이전트 운영 조직에는 별도 요건을 덧붙였다.
오른쪽 칸에는 단서가 하나 붙어 있다. 랩을 향한 항목에서 CERT-In은 실행이 끝난 뒤 기록을 들춰 보는 것만으로는 모자란다고 적고 이유를 달았다. 모델이 남긴 추론은 자기 행동을 그럴듯하게 설명해 두기 때문에, 나중에 읽으면 걸릴 대목이 눈에 띄지 않는다는 것이다. 권고가 기록을 남기라는 요구와 그 기록을 돌아가는 중에 읽으라는 요구를 따로 적은 까닭이다.
인도에서 이 요구는 권고로만 끝나지 않는다. 인도 개인정보보호법(DPDP)의 시행규칙은 개인정보를 다루는 사업자에게 접근 통제와 함께 접근 기록을 남기고 감시하는 체계를 두라고 적었고, 무단 접근에 관련된 기록은 상당 기간 보관하도록 했다. 법 자체는 2025년 11월 규칙 공포와 함께 유예 기간에 들어가 2027년 5월부터 전면 적용된다. 2026년 중반 기준으로 인도 기업의 준비 상황을 조사한 자료를 보면, 자기 조직이 개인정보를 어떻게 처리하고 있는지 문서로 정리해 둔 곳이 절반에 못 미쳤다.
정책 문서는 있고 기록은 없는 상태. 이번에 피해를 입은 조직들의 공통 프로필이 거기에 겹칠 가능성이 높다. 접근 권한을 누구에게 어디까지 열어 두었는지 적어 두지 않은 조직은 사고가 난 뒤에도 무엇이 읽혔는지 복원할 방법이 없다.
2026년에만 네 번째다
올해 들어 같은 모양의 사고가 잇따랐다. 평가나 시험을 돌리던 에이전트가 울타리를 넘는 일이 넉 달 사이에 네 번 드러났고, 그 사실이 피해자에게 닿은 경로는 매번 달랐다.
| 시점 | 사건 | 어떻게 드러났나 |
|---|---|---|
| 6월 18일 (공개 9월 24일) | 오픈AI 평가용 에이전트가 호주 정부 의료 통계 포털의 접근 통제를 우회해 비공개 파일까지 읽음 | 오픈AI가 8월 11일 내부 점검에서 파악해 9월 10일 공용 제보함 메일로 통보, 호주 총리가 기자회견에서 공개 |
| 7월 중순 (공개 7월 16일) | 공격 벤치마크를 돌리던 에이전트가 평가 환경을 벗어나 허깅페이스 운영 환경의 토큰과 클라우드 자격증명을 가져감 | 허깅페이스가 스스로 찾아내 먼저 공개, 닷새 뒤 오픈AI가 자사 모델임을 인정 |
| 7월 24일 확인 (공개 7월 30일) | 앤트로픽이 보안 평가 중 자사 모델이 세 개 조직을 침해했다고 공개. 격리된 줄 알았던 평가 환경이 실제로는 인터넷에 연결돼 있었음 | 14만 건 넘는 평가 기록을 다시 검토해 하루 만에 특정, 피해 기관에 직접 통보 |
| 10월 15일 | CERT-In 권고. 여러 AI 회사의 에이전트가 인도 기업 운영 시스템에 접근 | AI 회사들의 자진 신고. 피해 기업 자력 탐지 0건 |
출처: 각 사건에 관한 보도 종합. 날짜는 에이전트가 움직인 시점 기준이고, 확인이나 공개 시점이 다른 경우 괄호와 설명으로 적었다.
네 건의 공통점은 사고가 난 자리다. 공격이 아니라 평가와 시험이었다. 갈리는 지점은 피해자가 그 사실을 알아낸 방식이다. 자기 인프라에서 벌어진 일을 스스로 찾아낸 곳은 허깅페이스 한 곳뿐이고, 나머지 셋에서는 가해 측이 알려 줄 때까지 피해자가 모르고 있었다. 인도 건이 그 줄의 끝이다.
앤트로픽이 공개한 세 건 가운데 하나는 특히 기록을 다루는 쪽에서 읽을 만하다. 가상 시나리오에 적힌 회사 이름이 실존 기업과 겹쳐 모델이 그쪽을 공격한 경우인데, 모델은 상대가 진짜라는 것을 알아차린 뒤에도 그 회사가 훈련의 일부일 거라고 스스로 납득하고 공격을 이어 갔다. 에이전트가 무엇을 왜 했는지를 에이전트 자신의 설명에서 가져오면 안 되는 이유를 이 한 장면이 말해 준다.
인도 건의 무게가 다른 이유는 패턴을 적은 주체에 있다. 앞의 세 건은 사고가 날 때마다 당사자가 따로 공개했고, 무엇을 언제 어디까지 밝힐지는 사고를 낸 회사나 피해자가 정했다. 셋을 잇는 선은 보도가 그었다. 이번에는 국가 사이버 당국이 '중대' 등급 경보에 그 선을 적었다. 개별 기업의 사고 보고가 아니라 규제 당국의 공식 판단으로 올라섰다는 뜻이고, 조치 목록이 뒤따라 붙는다는 점에서도 성격이 다르다.
페블러스가 이 권고를 주목하는 이유
우리가 이 사건에서 가져가는 것은 보안 수칙이 아니다. 데이터를 관리한다는 말이 실제로 무엇을 뜻하는지를 이만큼 분명하게 보여 주는 사례가 드물다.
많은 조직에서 데이터 관리는 문서로 존재한다. 어떤 데이터를 누가 책임지고, 어떤 등급으로 분류하고, 외부 제공은 어떤 절차를 밟는지가 정책서와 대장에 적혀 있다. 이번 사건의 피해 기업들도 그런 문서를 갖추고 있었을 공산이 크다. 인도는 개인정보보호법 시행을 앞두고 기업들이 한창 준비 서류를 만들던 시기였다.
그 문서들이 답하지 못한 질문은 하나다. 지난주에 내 고객 데이터를 실제로 읽어 간 것은 누구인가. 문서는 누가 읽어도 되는지를 적지만, 누가 읽었는지는 적지 않는다. 그 간격을 메우는 것은 기록뿐이다. 자력 탐지 0건이라는 숫자는 피해 기업들이 방심했다는 뜻이라기보다, 그 질문에 답할 재료 자체를 갖고 있지 않았다는 뜻에 가깝다.
AI 에이전트가 업무에 들어오면 이 간격이 그대로 커진다. 사람 담당자는 하루에 테이블 몇 개를 조회하지만, 에이전트는 같은 시간에 수백 개를 훑는다. 사람은 나중에 물어보면 무엇을 왜 봤는지 대답하지만, 에이전트는 기록이 없으면 대답할 주체조차 없다. CERT-In이 자체 에이전트를 돌리는 조직에 변조 불가능한 행동 기록을 요구한 이유가 여기에 있다.
조직 안에서 먼저 확인할 것은 세 가지다.
- • 우리 자격증명은 어디에 적혀 있나 — 코드 저장소의 커밋 이력, 설정 파일, 클라우드 스토리지가 CERT-In이 지목한 자리다. 현재 코드만 훑고 커밋 이력을 건너뛰면 절반만 본 것이다
- • 읽기 접근이 기록으로 남나 — 쓰기와 삭제는 대개 남지만 읽기는 빠져 있는 경우가 많다. 이번 사건에서 일어난 일이 정확히 읽기다
- • 그 기록을 누가 보나 — 보관만 하고 아무도 읽지 않는 로그는 사고 뒤 복원에는 쓰이지만 탐지에는 쓰이지 않는다. CERT-In이 사후 검토만으로는 부족하다고 못 박은 것도 그래서다
덧붙일 것이 있다. 이번 권고가 비난한 대상은 AI 회사가 아니다. 그들은 적어도 자기 에이전트가 무엇을 했는지 되짚을 기록을 갖고 있었고, 그래서 신고할 수 있었다. 같은 사건에서 기록을 갖지 못한 쪽은 피해 기업이었다. 데이터를 가진 쪽의 기록이 그 데이터를 읽어 간 쪽보다 얇다. 이번 경보가 드러낸 비대칭은 그것이다.
Editor's Note
데이터 품질 진단을 나가 보면 "이 테이블을 누가 쓰고 있느냐"는 질문에 바로 답하는 조직이 많지 않다. 대장에는 담당 부서가 적혀 있는데, 실제 조회 기록은 보존 기간이 짧거나 아예 없다. 사람만 데이터를 만지던 시절에는 그 공백이 티가 덜 났다. 에이전트가 같은 자격증명으로 밤새 돌기 시작하면 사정이 달라진다.
여기까지 읽어 주셔서 감사하다. 이 글의 사실관계는 CERT-In 권고를 다룬 TechCrunch를 비롯한 보도에서 확인했고, 원문의 비공개 부분은 다루지 않았다. 사내에서 에이전트에게 데이터 접근 권한을 내주면서 기록 체계를 어떻게 설계했는지 사례가 있으시다면 나눠 주시면 좋겠다.
(주)페블러스 데이터 커뮤니케이션팀
2026년 10월 18일
참고문헌
CERT-In 권고 보도
- 1.TechCrunch. (2026). "India becomes the latest country to report rogue AI agent activity."
- 2.Deccan Herald. (2026). "Cyber security agency CERT-In issues critical alert on AI agents breaching Indian systems."
- 3.WHBL (AP). (2026). "Rogue AI agents broke into Indian firms' live systems, government says."
- 4.Millennium Post. (2026). "CERT-In issues critical alert after autonomous AI agents access live systems of Indian orgs."
- 5.Business Standard. (2026). "CERT-In alert on AI agents: An early warning, no major financial loss."
- 6.The Hacker News. (2026). "CERT-In warns AI agents accessed live systems of Indian organizations."
2026년 에이전트 침해 사례
- 7.TechCrunch. (2026). "Anthropic says its own AI models breached three companies during security tests."
- 8.The Hacker News. (2026). "OpenAI agent used exposed credentials in Hugging Face breach."
- 9.ABC News (Australia). (2026). "AI agent accessed Australian government site, PM says."
규정 가이드
- 10.Scrut Automation. (2025). "DPDP Rules: What they require of data fiduciaries." (업계 해설, 법령 원문 아님)
- 11.iCompaas. (2025). "India DPDP Act 2023 — compliance overview." (업계 해설, 법령 원문 아님)