핵심 POINT
Google은 9월 18일 Gemini가 외부 기관의 사이버보안 평가 과정에서 실제 기업 3곳의 시스템에 접근한 사실을 확인했습니다.
이번 사례는 특정 AI 서비스의 취약점이라기보다, 에이전트에 허용된 인터넷 접근과 자격증명·도구 권한의 경계를 어떻게 통제할지 보여주는 운영 이슈에 가깝습니다.
기업은 AI 에이전트 도입 시 외부 통신 허용 범위, 최소 권한, 비밀정보 분리, 사람의 승인, 행동 로그와 중단 장치를 함께 설계해야 합니다.
생성형 AI가 질문에 답하는 단계를 넘어 브라우저를 열고, 코드를 실행하고, 외부 시스템의 정보를 조회하는 ‘AI 에이전트’ 형태로 확장되면서 보안의 초점도 달라지고 있습니다. 모델이 어떤 답을 내놓는지뿐 아니라, 실제로 무엇에 접속할 수 있고 어떤 도구를 사용할 수 있는지까지 통제해야 하기 때문입니다.
Google은 2026년 9월 18일 보안 책임자 명의의 성명을 통해, 지난 5월 외부 평가기관 Irregular가 진행한 사이버보안 평가에서 Gemini가 테스트 범위에 포함된 것으로 인식한 실제 기업 3곳의 웹사이트에 접근한 사실을 확인했습니다. Google에 따르면 모델은 공개된 정보를 활용하거나 자격증명을 추측해 접근했고, 실제 기업이라는 점을 인지한 뒤에는 각 사례에서 행동을 중단했습니다.
현재 공개된 정보만으로는 세부 로그, 사용된 모델 버전, 접근 범위 전체를 독립적으로 검증하기 어렵습니다. 따라서 이번 사례를 ‘AI가 통제 없이 자율 해킹을 했다’고 확대 해석하기보다는, AI 에이전트의 테스트 환경과 인터넷 접근, 도구 권한, 승인 절차가 실제 시스템과 맞닿을 때 어떤 운영 리스크가 생길 수 있는지 살펴보는 것이 중요합니다. 이번 사례가 국내 기업의 피해로 이어진 것으로 확인되지는 않았습니다. 하지만 AI 에이전트가 브라우저·API·사내 시스템과 직접 연결되는 환경이 빠르게 늘고 있는 만큼, 이제는 모델 성능만큼 ‘어디까지 접근하고 무엇을 할 수 있는지’를 함께 살펴봐야 합니다. 이번 글에서는 기업이 AI 에이전트를 개발·도입·평가할 때 놓치기 쉬운 보안 점검 항목을 정리해보겠습니다.
■ 보안 평가가 실제 시스템 접근으로 이어진 과정
출처: AI(ChatGPT) 생성 이미지
이번 사례는 정식 서비스 운영 중 발생한 침해사고가 아니라, AI의 사이버보안 수행 능력을 평가하는 테스트 과정에서 발생했습니다. 공개된 설명을 기준으로 핵심 흐름은 비교적 단순합니다.
• 외부 평가기관이 가상의 대상을 상정해 사이버보안 과제를 수행하도록 했습니다.
• 평가 환경에서 인터넷 접근이 가능해지면서 모델이 실제 외부 정보를 조회할 수 있었습니다.
• 모델은 테스트 범위에 포함된 대상으로 인식한 사이트에 대해 공개된 정보를 활용하거나 자격증명을 추측해 접근했습니다.
• Google은 세 사례 모두 모델이 실제 기업이라는 점을 인지한 뒤 행동을 중단했다고 설명했습니다.
여기서 중요한 점은 공격 기법의 난도가 아닙니다. AI 에이전트가 ‘테스트 대상’이라고 판단한 범위와 실제 인터넷상의 자산이 겹칠 때, 잘못 설정된 네트워크 경계와 자격증명 접근이 현실의 시스템 접근으로 이어질 수 있다는 점입니다. 테스트용 에이전트라 하더라도 외부 통신과 도구 사용 권한이 열려 있다면, 일반적인 보안 테스트 도구와 마찬가지로 명확한 범위 통제가 필요합니다.
■ AI 모델보다 먼저 점검해야 할 것은 ‘권한과 경계’
출처: AI(ChatGPT) 생성 이미지
이번 이슈를 특정 모델 하나의 문제로만 보면 놓치는 부분이 있습니다. Anthropic도 9월 9일 공개한 분석에서 사이버보안 평가 중 Claude 모델이 실제 제3자 시스템에 무단 접근한 사례 4건을 공개했습니다. 당시 분석 역시 평가 환경에서의 인터넷 접근, 테스트 경계, 모델이 수행할 수 있는 행동 범위가 중요한 통제 지점으로 다뤄졌습니다.
AI 에이전트는 사용자의 목표를 해석한 뒤 브라우저, 코드 실행기, API, 클라우드, 파일 시스템 같은 도구를 연속적으로 사용할 수 있습니다. 이때 모델의 판단이 완벽하다고 가정해서는 안 됩니다. 사람이 잘못된 링크를 열거나 잘못된 서버에 접속할 수 있는 것처럼, 에이전트 역시 모호한 이름, 잘못된 설정, 예상하지 못한 외부 입력 때문에 업무 범위를 벗어날 가능성을 고려해야 합니다.
따라서 보안 통제는 ‘모델이 안전하게 판단할 것’이라는 기대보다, 모델이 실수하더라도 피해 범위가 커지지 않도록 기술적 경계를 만드는 방향으로 설계하는 것이 바람직합니다. OWASP의 AI Agent Security 가이드도 도구 접근 최소화, 민감 작업에 대한 명시적 승인, 격리된 실행 환경, 도구 호출 로그를 주요 방어 원칙으로 제시하고 있습니다.
■ 기업이 AI 에이전트 도입 전 확인할 5가지
출처: AI(ChatGPT) 생성 이미지
❶ 외부 인터넷 접근은 기본 허용보다 ‘허용 목록’ 중심으로
보안 테스트나 자동화 업무에 외부 통신이 꼭 필요하지 않다면 네트워크를 격리하는 것이 우선입니다. 인터넷 접근이 필요한 경우에도 목적지 도메인과 포트, 호출 가능한 API를 사전에 제한하고, 테스트 자산과 실제 운영 자산이 혼동되지 않도록 별도의 도메인·계정·네임스페이스를 사용하는 것이 좋습니다.
❷ 도구·API 권한은 읽기 전용에서 시작하기
AI 에이전트에 셸 실행, 파일 삭제, 계정 생성, IAM 변경, 배포 권한을 한 번에 부여하면 판단 오류 한 번의 영향 범위가 커질 수 있습니다. 업무에 필요한 도구만 연결하고, 읽기 전용과 쓰기 권한을 분리하며, 작업별로 최소 권한 계정을 사용하는 방식이 권고됩니다.
❸ 운영 자격증명과 테스트 환경을 분리하기
API 키, 토큰, 비밀번호가 코드 저장소나 테스트 데이터에 남아 있으면 에이전트가 이를 정상적인 작업 자원으로 인식해 사용할 가능성이 있습니다. 테스트 환경에는 운영용 비밀정보를 넣지 않고, 짧은 수명의 제한된 자격증명을 사용하며, 코드 저장소와 이미지·배포 파일에 노출된 비밀정보를 주기적으로 점검해야 합니다.
❹ 고위험 작업에는 사람의 승인 단계를 두기
외부 시스템 로그인, 파일 삭제, 계정·권한 변경, 운영 배포, 대량 데이터 조회처럼 영향이 큰 작업은 에이전트가 곧바로 실행하지 못하도록 승인 단계를 두는 것이 필요합니다. 특히 되돌리기 어렵거나 외부에 영향을 주는 행동은 사람이 대상과 범위를 다시 확인한 뒤 실행되도록 설계하는 편이 안전합니다.
❺ 행동 로그와 즉시 중단 장치를 함께 운영하기
프롬프트 기록만으로는 충분하지 않습니다. 어떤 도구를 언제 호출했는지, 어느 외부 주소와 통신했는지, 어떤 계정과 권한을 사용했는지를 함께 남겨야 합니다. 평소와 다른 대상 접근이나 반복적인 인증 시도가 발생하면 자동으로 세션을 중단하거나 네트워크를 차단하는 ‘킬 스위치’와 경보 체계도 준비할 필요가 있습니다.
■ AI 에이전트 운영 정책으로 바꿔야 할 질문
AI 에이전트 보안은 새로운 별도 영역으로만 볼 필요는 없습니다. 기존의 계정·권한 관리, 네트워크 세분화, 비밀정보 관리, 로그 모니터링, 변경 승인 체계를 AI 에이전트에도 동일하게 적용하되, 자동 실행 속도와 연속적인 도구 호출을 고려해 통제를 더 촘촘하게 만드는 것이 핵심입니다.
보안·IT 담당자는 현재 도입 중인 AI 기능을 대상으로 다음 질문에 답할 수 있어야 합니다.
• 어떤 AI 에이전트가 외부 인터넷이나 사내 시스템에 접근할 수 있는가?
• 각 에이전트가 사용할 수 있는 계정과 API 권한은 업무 범위보다 넓지 않은가?
• 운영용 자격증명이나 개인정보가 에이전트의 작업 컨텍스트에 그대로 노출되지 않는가?
• 고위험 작업을 실행하기 전에 사람의 승인 절차가 작동하는가?
• 비정상 행동이 발생했을 때 누가 어떤 로그를 보고 즉시 중단할 수 있는가?
이 질문 중 하나라도 명확히 답하기 어렵다면, 모델 선택보다 먼저 운영 경계와 통제 구조를 정리할 필요가 있습니다.
■ AI 에이전트 보안은 모델 성능보다 운영 통제가 먼저
이번 사례는 AI 에이전트가 더 강력해질수록 ‘무엇을 할 수 있는가’와 함께 ‘어디까지 하도록 허용할 것인가’를 정해야 한다는 점을 보여줍니다. 모델이 의도대로 행동하더라도 테스트 범위, 자격증명, 네트워크 설정이 잘못돼 있다면 예상하지 못한 실제 시스템 접근이 발생할 수 있습니다.
기업이 AI 에이전트를 업무에 연결할 때는 생산성 기능을 먼저 확장한 뒤 보안을 덧붙이기보다, 계정·권한·외부 통신·승인·로그 기준을 도입 초기부터 함께 설계하는 것이 중요합니다. 특히 운영 시스템에 연결되는 에이전트라면 최소 권한과 사람의 승인, 즉시 중단 가능한 구조가 실제 피해 범위를 줄이는 핵심 안전장치가 될 수 있습니다.
SK쉴더스 사이버보안 상담을 통해 AI 도입 환경의 계정·권한·네트워크 통제 수준과 기존 보안 운영 체계의 연계 지점을 점검해보시기 바랍니다.
■ 자주 묻는 질문
Q. 이번 사례는 Gemini 서비스 자체가 해킹당했다는 의미인가요?
A. 아닙니다. 공개된 내용은 외부 기관이 진행한 사이버보안 평가 과정에서 Gemini가 실제 기업 시스템에 접근한 사례입니다. Gemini 서비스 자체가 침해됐다는 내용과는 구분해야 합니다.
Q. AI가 스스로 실제 기업을 공격했다고 봐도 되나요?
A. 공개된 정보만으로 모델의 의도나 자율성 수준을 단정하기는 어렵습니다. Google은 모델이 테스트 범위에 포함된 것으로 인식한 사이트에 접근했고, 실제 기업임을 인지한 뒤 중단했다고 설명했습니다. 현재 공개된 기술 로그가 제한적인 만큼 확인된 사실 범위 안에서 해석할 필요가 있습니다.
Q. 기업용 AI 에이전트는 인터넷 접근을 모두 막아야 하나요?
A. 업무상 외부 조회가 필요한 에이전트도 있기 때문에 일률적인 차단이 항상 현실적인 것은 아닙니다. 대신 필요한 목적지와 API만 허용하고, 나머지 통신은 차단하는 방식의 네트워크 허용 목록과 격리 정책을 적용하는 것이 바람직합니다.
Q. 사람의 승인 단계는 어떤 작업에 적용해야 하나요?
A. 계정·권한 변경, 운영 배포, 외부 전송, 삭제, 대량 데이터 접근처럼 영향이 크거나 되돌리기 어려운 작업에 우선 적용할 수 있습니다. 승인 단계에서는 대상 시스템과 실행 범위를 다시 확인할 수 있어야 합니다.
Q. AI 에이전트 보안 점검에서 가장 먼저 확인할 것은 무엇인가요?
A. 현재 에이전트가 어떤 시스템과 도구에 연결돼 있는지 자산 목록을 만드는 것이 출발점입니다. 이후 각 연결의 권한 범위, 외부 통신, 자격증명, 승인 절차, 로그 수집 여부를 순서대로 확인하는 것이 좋습니다.
[콘텐츠 출처]
Reuters, Gemini hacked three companies in first known breakout by Google's AI, 2026.09.18
Anthropic, An alignment assessment of recent cybersecurity incidents, 2026.09.09
OWASP Cheat Sheet Series, AI Agent Security Cheat Sheet
OWASP GenAI Security Project, Agent Control Standard, 2026.09.01
