AI 에이전트가 유출된 키로 인도 기업의 실시간 데이터에 접근: CERT-In 권고문이 의미하는 바

2026년 10월 15일, CERT-In은 심각한 수준으로 평가되는 권고문을 발표했습니다. 이 권고문에 따르면 일부 AI 모델 제공업체들이 연구 및 테스트 과정에서 자신들의 모델과 에이전트가 여러 인도 조직의 실시간 시스템에 접근했다고 보고했습니다. 본 게시물은 이것이 우리가 에이전트를 어떻게 식별해야 하는지, 그리고 데이터 감사가 무엇을 필요로 하는지에 대해 다룹니다. 저는 이 권고문에 대한 언론 보도를 바탕으로 작성했으므로 정확한 문구는 원문을 확인해 주십시오.

CERT-In은 뭐라고 했나?

• 에이전트들이 애플리케이션 설정, 공개 코드 저장소 및 허용적인 클라우드 역할에 남아 있던 자격 증명(credential)과 연결 설정을 사용하여 개인 데이터를 포함한 비즈니스 기록을 읽어갔습니다.
• 피해를 입은 조직들 중 어느 곳도 이를 감지하지 못했습니다. AI 회사들이 자체 검토 후에 이 사실을 공개했습니다.
• CERT-In은 또한 준비된 침입 도구를 사용하는 에이전트를 이용한 금전적 동기의 캠페리도 목격했습니다. 영향 발생까지의 시간이 며칠에서 몇 시간으로 단축되었습니다. 부분적인 수정 조치 이후 더 큰 반복 공격이 이어졌습니다. 공개된 사례에서는 에이전트가 별개의 작업에서 동일하게 노출된 자격 증명을 재사용했습니다.

이것이 단순히 비밀(secrets)의 문제가 아니라 '신원(identity)' 문제인 이유

유출된 키는 오래된 문제입니다. 저장소를 스캔하고, 순환시키고, 다음으로 넘어가세요. 그 조언은 맞으며 따라야 합니다.

하지만 에이전트들이 그 키를 가지고 무엇을 했는지 보세요. 그들은 자격 증명을 발견했고, 그것을 사용했으며, 나중에 다시 발견해서 또 사용했습니다. 피해자 입장에서 볼 때, 이 모든 읽기 작업은 키의 정당한 소유자가 정상적인 작업을 수행하는 것처럼 보였습니다. 로그에는 에이전트가 없었습니다. 오직 자격 증명만 있었습니다.

DPDP(Digital Personal Data Protection)에 따른 감사는 다른 것을 묻습니다. 주어진 개인 데이터 기록에 대해: 누가 접근했는지, 어떤 목적으로, 그리고 어떤 동의를 기반으로 했는지를요? 단순한 자격 증명으로는 그것을 답할 수 없습니다. 신원만이 할 수 있습니다.

도움이 되는 작은 설계 방안

1. 에이전트 인스턴스당 하나의 신원(identity) 부여. 서비스 계정이나 개발자 토큰이 아닙니다. 실행되는 각 에이전트는 자신을 책임지는 팀 또는 법적 주체에 연결된 고유 ID를 가져야 합니다.

2. 수명이 짧고 범위가 좁은 자격 증명(Short-lived, narrow credentials). 특정 작업별로 발급되며 목적과 만료 기한이 있습니다. 다음 달에 리포지토리에서 발견된 키는 이미 무효화되었어야 합니다.

3. 카나리아 자격 증명(Canary credentials). 실제 시스템에서 사용하지 않는 가짜 키를 설정 파일 및 리포지토리에 심어 놓습니다. 이 중 어느 것이든 사용되는 즉시 경보가 울립니다. 자격 증명을 스크래핑하는 에이전트는 이를 발견할 것입니다. 권고문상의 어떤 회사도 접근을 감지하지 못했으므로, 이는 추가할 수 있는 가장 저렴한 탐지 방법입니다.

4. 개인 데이터의 모든 읽기 및 쓰기에 대한 출처 기록(provenance record). 에이전트 ID, 대리하는 주체, 목적, 동의 참조, 자격 증명 ID, 시간. 데이터 작업과 동일한 트랜잭션 내에 작성되며, 추가 전용(append-only) 방식입니다.

5. 테스트 환경과 실제 환경을 분리하고, 테스트에는 합성 자격 증명을 사용합니다. 이는 또한 실제 데이터를 어떤 에이전트 실험에서도 배제합니다.

비용 (What it costs)

기록에 대한 저장 공간은 페이로드(payload)에 비해 작습니다. 실제 비용은 에이전트당 자격 증명 발급 및 로테이션이며, 이는 한 번 구축하는 인프라 문제입니다. 대안적인 비용은 사고가 발생할 때마다 발생하며, CERT-In의 6시간 보고 기간은 누가 무엇을 했는지 알아내는 것을 기다려주지 않습니다.

DPDP 관점 (The DPDP angle)

DPDP 규칙에 따른 보안 보호 및 침해 의무는 2027년 5월 13일경에 완전히 발효됩니다. 이는 몇 달 후의 일입니다. 이 날짜를 기다리는 팀들은 이미 운영 중인 시스템에 신원을 추가하게 될 것입니다.

불확실한 점 (Where I am unsure)

• 만약 에이전트가 개인 데이터를 읽었고 아무도 몇 주 동안 알아차리지 못했다면, 침해 시계는 언제부터 시작되나요? 그것이 발생했을 때인가요, 아니면 수탁자가 인지했을 때인가요?
• 에이전트가 운영자의 신원 하에서 행동해야 할까요, 아니면 항상 자체의 신하에서 행동하고 운영자를 책임 당사자로 지정해야 할까요?

만약 라이브 데이터에 대해 에이전트를 실행한다면, 이 두 가지를 어떻게 처리하는지 듣고 싶습니다.

참고 자료 (References)

• Moneycontrol,