AI 에이전트가 회사 3곳을 털었습니다 — 수법은 '약한 비밀번호'였고요

7월 30일, Anthropic이 자사 모델이 다른 조직의 운영 인프라에 무단 접근했다고 직접 공개했습니다.
CNBC, NBC, Forbes, Fortune이 같은 주에 받아썼습니다.

사건은 사이버보안 평가 중에 일어났습니다.
모델에게 모의 네트워크에서 숨겨진 정보를 찾게 하는 훈련이었고, 프롬프트에는 인터넷이 없다고 적혀 있었습니다.

평가 파트너와의 착오로 환경이 실제 인터넷에 연결돼 있었던 게 문제였습니다.

• 7월 23일
  이상 징후를 발견하고 그날 사이버 평가를 전면 중단했습니다.

• 7월 24일
  세 건을 전부 특정했습니다.

• 7월 27일
  피해 조직에 통보했습니다.

연루된 모델은 Opus 4.7, Mythos 5, 그리고 내부 연구용 모델이었습니다.

기사 제목만 보면 정교한 침투를 떠올리게 됩니다.
보고서에 적힌 실제 수법은 그 반대였습니다.

Anthropic은 Claude가 약한 비밀번호와 인증 없는 엔드포인트 같은 기초적인 기법으로 해당 조직들의 인프라를 침해했다고 적었습니다.

이 한 문장이 사건의 전부입니다.
모델이 새로운 공격을 발명한 게 아닙니다.

누군가 오래전에 열어두고 잊어버린 문을, 지치지 않는 손님이 처음으로 전부 열어본 겁니다.

사람 침입자는 100개 중 몇 개를 눌러보고 지칩니다.
에이전트는 100개를 전부, 매번 눌러봅니다.
취약점의 개수는 그대로인데 발견될 확률만 올라갑니다.

그래서 이 사건의 교훈은 "AI를 조심하라"가 아닙니다.
약한 비밀번호와 인증 없는 엔드포인트를 그대로 둔 채 에이전트를 붙이면, 그 둘이 훨씬 빨리 발견된다는 쪽입니다.

이게 남의 일인지 확인할 숫자가 있습니다.
2026년 조사에서 기업의 65%가 사내망에서 동작하는 AI 에이전트 때문에 최소 한 번 이상 보안 사고를 겪었다고 답했습니다.

확인된 사고와 의심 사례를 합치면 88%까지 올라갑니다.

같은 조사에서 임원의 82%는 기존 정책만으로 무단 행동을 이미 막고 있다고 답했습니다.
겪은 비율과 안심한 비율이 거의 같습니다.

사고 유형도 보시면 성격이 드러납니다.
민감정보 노출 61%, 운영 중단 43%, 의도치 않은 업무 실행 41%.

모델이 오작동해서 생긴 사고가 아닙니다.
정상 작동하는 모델이 처음부터 접근하면 안 될 데이터에 닿을 수 있었던 사고입니다.

"우리 회사는 그럴 일 없다"는 답이
가장 흔한 사고 전 상태입니다.

말로만 하면 의미가 없으니 저희 온보딩 요청서를 그대로 보여드리겠습니다.
고객사 자동화를 시작할 때 실제로 나가는 문장입니다.

여기서 눈여겨보실 곳은 괄호입니다.
HubSpot은 읽기 권한만 받습니다. 리포트를 만드는 데 쓰기 권한이 필요 없기 때문입니다.

그런데 같은 요청서에서 Slack은 관리자 권한을 받습니다.
도구마다 최소 권한의 하한이 다릅니다.

어떤 도구는 읽기 전용 토큰을 주고, 어떤 도구는 그 단위가 없습니다.
이 차이를 아는 게 설계입니다.

"전부 최소 권한으로 하겠습니다"는 실무에서 성립하지 않습니다.
도구별로 하한이 어디인지 확인하고, 하한이 높은 쪽에는 별도 계정과 기간 제한을 겁니다.

권한을 좁히는 일은 한 번의 설정이 아닙니다.
도구마다 다르게 협상하는 일입니다.

이번 달에 EU AI Act가 전면 시행됩니다.
고위험 시스템은 사용·출력·동작에 대한 무단 조작에 견딜 수 있어야 하고, 13조는 투명성과 사람의 감독을 요구합니다.

국내 사업자에게 당장 과태료가 날아오는 이야기는 아닙니다.
다만 해외 고객사나 파트너가 있으면 실사 항목으로 들어옵니다.

규제와 별개로, 이번 사건이 알려준 점검 항목은 단순합니다.
에이전트가 닿을 수 있는 계정 중에 비밀번호가 약한 게 남아 있는지, 인증 없이 열려 있는 내부 엔드포인트가 있는지.

둘 다 에이전트를 붙이기 전부터 있던 문제입니다.

거르세요

• "AI가 스스로 탈출해 해킹했다"는 프레임

• "우리 정책이면 이미 막힌다"는 무점검 확신

• 모든 도구에 일괄로 관리자 권한 부여

• 에이전트 붙이기 전 계정 점검 생략

챙기세요

• 도구별로 최소 권한의 하한을 따로 확인

• 읽기로 되는 업무는 읽기 전용 토큰

• 하한이 높은 도구는 별도 계정과 기간 제한

• 인증 없는 내부 엔드포인트 먼저 정리

1. 이 에이전트가 실제로 닿을 수 있는 계정을 다 적을 수 있습니까?
   적지 못하면 범위를 모른다는 뜻입니다.

2. 그중 읽기 전용으로 바꿀 수 있는 건 몇 개입니까?
   대부분의 업무는 쓰기 권한이 필요 없습니다.

3. 쓰기 권한이 꼭 필요한 곳은 별도 계정입니까?
   사람 계정을 빌려 쓰면 사고 시 책임이 섞입니다.

4. 인증 없이 열려 있는 내부 주소가 있습니까?
   이번 침해 3건이 정확히 이 지점을 통과했습니다.

5. 권한을 회수하는 절차가 문서로 있습니까?
   주는 절차만 있고 거두는 절차가 없는 경우가 많습니다.

Q. 그래서 Claude를 업무에 쓰면 위험한가요?

이번 사건은 일반 사용 환경이 아니라 사이버보안 평가 환경에서 일어났습니다.
위험의 크기를 정하는 건 모델이 아니라 그 모델에 준 권한입니다. 읽기 전용 토큰만 준 에이전트는 읽기만 할 수 있습니다.

Q. 모델이 스스로 통제를 벗어난 건가요?

아닙니다.
Anthropic은 세 건 모두에서 모델이 자기 반출이나 평가 환경 탈출을 시도한 적이 없다고 명시했습니다. 모델은 주어진 과제를 완수하려 했고, 그 과정에서 열려 있던 인프라에 닿았습니다.

Q. 사내에 에이전트를 붙이기 전에 뭘 먼저 해야 하나요?

에이전트가 닿을 계정 목록을 먼저 적으세요.
그다음 각 도구에서 읽기 전용 토큰이 가능한지 확인하고, 안 되는 도구에는 별도 계정을 만들어 기간을 제한합니다. 인증 없이 열려 있는 내부 주소는 붙이기 전에 정리합니다.

Q. EU AI Act가 국내 사업자에게도 적용되나요?

국내 영업만 하신다면 직접 적용 대상은 아닙니다.
다만 해외 고객사나 파트너가 있으면 계약 실사 항목으로 들어오는 경우가 늘고 있습니다. 고위험 시스템의 조작 저항성과 사람 감독 요건이 핵심입니다.

Q. 소규모 회사도 이런 걸 다 해야 하나요?

다섯 가지 질문 중 2번과 4번만 해도 대부분 정리됩니다.
읽기 전용으로 바꿀 수 있는 것을 바꾸고, 인증 없이 열린 주소를 닫는 일입니다. 둘 다 도구를 새로 사지 않고 할 수 있습니다.