보안 및 거버넌스

Console 사용자의 1.4%, 벤더 키 전부: OpenCode 침해 사고가 말해주는 AI 자격 증명 집중의 위험

글쓴이: IdeaBosque최종 업데이트: 2026年11月2日

핵심 요약

2026년 10월 16일 밤, 공격자가 OpenCode 호스팅 Console 뒤에 있던 레거시 시스템에 침입해 Console 사용자의 1.4%분의 OpenAI·Anthropic·Google API 키가 노출됐습니다 — 팀이 결코 보지 못하도록 사용자들이 저장해 둔 바로 그 키들입니다(OpenCode on X, CSA 조사 노트).
자진 보고된 오용으로 단일 계정에서 OpenAI 281달러, Anthropic 168달러의 청구가 발생했고, 한 건은 1,700달러로 보고됐습니다 — 이 키들은 불기명(bearer) 자격 증명이기에, 복제된 키는 각 프로바이더가 폐기할 때까지 계속 과금됐습니다(TechCrunch).
Console에서 키를 삭제하는 것은 아무 소용이 없었습니다; 이미 유출된 복사본을 무효화할 수 있는 곳은 프로바이더뿐이었습니다 — Anthropic과 Google은 노출된 키를 광범위하게 차단했고, OpenAI는 피해 API 고객에게 환불했습니다(TechCrunch).
사고 수습은 안전 필터에서 막혔습니다: 프런티어 모델들은 응답 도중 악성 페이로드 분석을 거부했고, OpenAI의 Daybreak Blue 프로그램을 통한 심사된 접근이 이뤄지기 전까지 분석이 불가능했습니다 — 이는 7월에 Hugging Face가 기록했던 것과 같은 벽입니다("안전장치는 사고 대응자와 공격자를 구분하지 못합니다")(TechCrunch, Hugging Face).
2026년 11월 2일 기준 — 16일째 — OpenCode는 근본 원인, 사후 보고서, 총 손실액을 아무것도 공개하지 않았고, "대규모 증류 공격"이라는 귀속에는 이견이 남아 있습니다; 사고가 어떻게 마무리되든 집중에 대한 교훈은 유효합니다(StepSecurity, CSA).

OpenAI, Anthropic, Google 키를 OpenCode 호스팅 Console에 저장한 팀이라면 그 개발자들은 모두 같은 그럴듯한 로컬 판단을 내렸습니다: 셸, 도트파일, 채팅 로그에서 키를 옮겨 내고, 호스팅 도구가 팀을 대신해 프로바이더를 호출하게 만든 것입니다. 2026년 10월 16일, 이 판단들이 하나의 공격 표면으로 결합됐습니다. 공격자가 OpenCode Console 뒤의 레거시 시스템 — 팀이 모델 프로바이더를 공유하는 호스팅 계층 — 에 침입했고 Console 사용자의 1.4%분의 키가 함께 유출됐습니다(OpenCode on X, CSA). 몇 시간 안에 개발자들은 세 개의 프로바이더 계정을 동시에 건드린 과금 알림을 올리기 시작했습니다 — 자기 전에 OpenAI 281달러, Anthropic 168달러의 청구를 보고한 사람이 있었고, 총액이 1,700달러를 넘었다고 보고한 사람도 있었습니다(TechCrunch).

이 글은 이 사고가 오늘날 모든 AI 에이전트 배치가 지는 패턴에 대해 무엇을 증명하는지 짚습니다: 프로바이더 자격 증명을 보관하는 호스팅 도구는 곧 당신의 AI 관계를 보관하는 벤더이며, 폐기권은 도구가 아니라 프로바이더에 있다는 것입니다. 이 글은 MCP Events: When a Subscription Becomes a Credential You Cannot Revoke의 뒤를 잇습니다. 앞선 글은 MCP 이벤트를 깨끗이 폐기할 수 없는 자격 증명으로 만드는 구독 수명의 공백을 다뤘습니다; 여기서는 공백의 방향이 반대입니다 — 도구가 자격 증명을 쥐고 있고, 이미 빼돌려진 복사본에 대해 당신이 가진 유일한 지렛대는 그것을 발급한 프로바이더에 있습니다.

검증된 순서로 본 사건 경위

검증 가능한 타임라인이 짧습니다. 벤더가 공개한 것이 거의 없기 때문입니다:

10월 16일 (밤): 공격자가 OpenCode Console 뒤의 오래된 시스템에 침입했습니다 — 회사가 해체를 진행하던 레거시 플랫폼입니다(CSA).
10월 17일: OpenCode가 X에서 침해를 공개했고, 영향 범위를 Console 사용자의 1.4%로 밝혔으며, "Action Required: Potential provider key breach"라는 제목으로 영향받은 모든 사용자에게 이메일을 보냈습니다. 공동창립자 Dax Raad는 경계를 명확히 했습니다 — "이것은 OpenCode Console이지 OpenCode 본체가 아닙니다, 그 키들은 결코 우리에게 오지 않습니다"; 오픈소스 CLI는 영향받지 않았습니다(TechCrunch).
10월 17–18일: Anthropic과 Google은 노출됐다고 판단한 API 키를 차단했습니다(TechCrunch). OpenAI는 OpenCode와 협력해 복구를 진행하고, 공격에 사용된 크레딧에 대해 피해 API 고객에게 환불했습니다.
진행 중: 사용자들이 보고한 청구가 계속 쌓였습니다 — OpenAI 281달러 / Anthropic 168달러, 다른 보고에서는 Anthropic 약 400달러와 Google 약 200유로, 그리고 총액 1,700달러의 자진 보고 건(CSA). OpenCode는 무단 청구에 대한 환불이 진행 중이라고 밝혔습니다.
11월 2일 기준 미공개 사항: 근본 원인, 사후 보고서, 총 손실액, 저장된 키가 암호화됐는지 여부, 정확한 프로바이더 목록 — Cyera 요약은 OpenRouter를 노출된 키 유형에 포함하지만 The Hacker News는 OpenAI, Anthropic, Google을 보도했습니다(CSA, Cyera).

정직 표식이 중요합니다: OpenCode는 이를 "대규모 증류 공격"으로 귀속시켰고, 연구자들은 수 시간 내에 반론했습니다 — Nathan Lambert는 이 프레임을 과장이라 부르며, 침입이 증류 사용이 입증되지 않은 평범한 침해 사고처럼 보인다고 주장했습니다(TechCrunch). 증류 자체는 실재하는 위협입니다 — Anthropic은 약 24,000개의 사기 계정이 1,600만 건이 넘는 교신을 생성해 Claude 출력으로 학습한 캠페인을 문서화한 바 있습니다 — 하지만 OpenCode 침입을 이것과 공개적으로 연결한 이는 아무도 없습니다. 도난 키는 그 시장의 그럴듯한 원재료입니다; 그럴듯함이 곧 귀속은 아닙니다. 규모 맥락: OpenCode는 217,000스타로 GitHub에서 가장 많은 스타를 받은 저장소 중 하나이므로, 노출 표면은 부수적 실험이 아니라 프로덕션에서 사용되는 최대급 오픈소스 AI 프로젝트였습니다.

패턴: 호스팅 에이전트 도구에서의 자격 증명 집중

침해의 구조는 그 규모보다 더 중요합니다. 프로바이더 키를 저장한 각 Console 워크스페이스는 지역적으로 실문제를 해결했습니다 — 키가 개발자의 머신을 통해 새어나가지 않게 한 것입니다. 합산하면, 같은 설계가 하나의 금고를 만들어냈습니다: 서로 관련 없는 여러 벤더의 유효한 자격 증명이, 고객이 관찰할 수 없는 단 한 회사의 보안 경계 뒤에 모인 것입니다. 금고에 도달한 공격자는 OpenAI, Anthropic, Google을 뚫을 필요도, 단 하나의 고객 머신을 침해할 필요도 없습니다; 호스팅 도구 그 자체가, 사용자가 맡겨 모든 벤더 관계에 걸친 단일 노출 지점입니다(CSA).

프로바이더 키는 이를 대부분의 비밀보다 악화시킵니다. 타인 개입 없이 사용되는 느슨한 불기명 자격 증명이어서입니다: 대체로 어느 장치·네트워크·세션에도 묶이지 않고, 더 좁은 프로젝트키와 지출 한도가 설정되지 않으면 고객 계정에서 과금됩니다. 도난 키는 즉시, 어디서든, 당신의 비용으로 동작합니다 — 무단 청구 보고들이 정확히 이를 보여주었습니다(CSA). 같은 구조가 이 달 초, 다른 형태로도 나타났습니다: CSA의 LiteLLM 게이트웨이 취약점 연쇄 분석은 기업의 프로바이더 키를 보관하는 게이트웨이를 기록하며, 한 번의 침해로 그것이 대행하는 모든 상위 서비스의 자격 증명이 노출된다고 합니다. 아키텍처는 다르지만 집중은 같습니다.

레거시 시스템이라는 세부는 단독 한 줄을 값합니다. 공격자가 침입한 시스템은 폐기 진행 중이었습니다 — 폐기 예정 시스템은 대개 더 적은 패치, 더 약한 모니터링, 더 허술한 접근 검토를 받으면서 여전히 프로덕션 데이터를 보관합니다(CSA). 자격 증명 보관소는 "옛 데이터"가 아닙니다. 마이그레이션과 삭제가 끝날 때까지, 폐기 중인 시스템은 현역 금고입니다.

폐기는 비대칭입니다 — 도구가 아니라 프로바이더에 있습니다

운영상의 비대칭이 이 사고의 가장 전이 가능한 교훈입니다. OpenCode Console에서 키를 삭제하는 것은 벤더 쪽 복사본을 제거할 뿐입니다; 10월 16일 새벽 2시에 이미 유출된 복사본에는 아무 효과가 없습니다. 자격 증명을 무효화할 수 있는 것은 발급한 프로바이더뿐입니다 — 이래서 CSA와 Cyera가 같은 절차를 강조합니다: 각 프로바이더의 대시보드에서 폐기하고 재발급하라, 에이전트 도구에서만 하지 말라(CSA, Cyera).

이 비대칭은 아래 다이어그램에서 깔끔하게 나뉩니다:

이 비대칭의 세 번째 층은 시간입니다. 자동화된 오용은 자격 증명이 노출되면 즉시 시작되는 것이 보통이라, 감사는 연관 키를 보관했을 가능성이 있는 모든 프로바이더까지 도달해야 합니다 — 10월 16일 이후 사용량과 청구를, OpenCode 이메일이 왔든 안 왔든, 모든 프로바이더 계정에서 점검하세요(Cyera, CSA). 1.4%라는 수치는 신뢰를 이전하지 않습니다: 도출 방법을 아는 것은 OpenCode뿐이고, 키를 Console에 저장했는데 이메일을 받지 않은 팀은 침묵을 안심으로 여겨서는 안 됩니다. 키 순환은 저렴합니다; 이것이 막는 노출에는 한계가 없습니다.

대응의 벽: 사고 대응이 회사 자체의 안전장치에 걸릴 때

이 사고는 이름이 먼저 생겼던 문제에 두 번째 사례를 하나 추가했습니다. OpenCode 팀이 48시간 연속 공격 시도 기간 동안 방어용 AI 에이전트를 밤낮없이 돌리던 중, 분석에 쓰던 모델들이 악성 코드 검사를 거부하기 시작했습니다 — 페이로드가 안전 필터에 걸린 것입니다. OpenCode는 이후 OpenAI의 Daybreak Blue 프로그램 접근권을 얻었고, 이 프로그램은 심사된 사용자에게 방어 보안 작업을 덜 거부하는 모델을 제공하며, 조사가 나아졌습니다(TechCrunch).

이는 7월 패턴이 더 작은 회사에서 반복된 것입니다. Hugging Face가 자율 AI 에이전트의 인프라 침입을 분석할 때 상용 모델들이 로그 분석을 막았습니다; 그 블로그의 "The asymmetry problem" 섹션은 이 운영상 사실을 정확히 말합니다 — 안전장치는 "사고 대응자와 공격자를 구분하지 못합니다"(Hugging Face). 대응의 벽은 이제 반복되는 사고 변수입니다: 두 회사, 모두 위기 한가운데서, 모두 분석 도구가 분석을 거부하는 것을 발견했습니다. 거버넌스의 시사점은 사고 중에 안전장치를 느리자는 게 아닙니다 — 사고 대응 계획은 AI 보조 트리아지가 안전 필터에서 막힐 것을 가정하고 심사된 접근 경로를 사전에 마련해야 한다는 것입니다. OpenCode가 벽에 걸려 늦어진 뒤에야 하게 된 것처럼요.

대통령 과학기술자문위원회 공동의장 David Sacks는 OpenCode와 Hugging Face 모두 공격 도중 안전장치가 역효과를 낸 점을 공개적으로 지적했습니다(TechCrunch). 정책적 관심은 도달했습니다; 실행 가능한 변화는 아직도 구매자 측에 있습니다.

미해결 질문 어느 것이든 견뎌내는 네 가지 통제

지금까지 공개된 어떤 사실도 구매자에게 Console 키가 암호화됐는지 알려주지 않습니다. 다음 통제를 도입하는 데는 그 답이 필요 없습니다:

어떤 도구가 어떤 프로바이더 키를 보관하는지 목록을 만드세요. 실패는 집중이 침해 전에는 보이지 않는 데서 시작됩니다. 팀이 쓰는 모든 호스팅 AI 도구 — 코딩 에이전트, 챗 플랫폼, 게이트웨이 — 에 어느 벤더 자격 증명을 저장하는지 정확히 물으세요.
실사(due diligence)에서 그 도구들을 자격 증명 벤더로 취급하세요. 프로바이더 키를 쥔 도구는 당신의 AI 관계를 쥔 것입니다. 키 저장 방법, 암호화 여부와 주체, 폐기 경로에 어떤 접근 검토가 이뤄지는지 물으세요 — CSA는 관련 도메인을 AI Controls Matrix에 매핑합니다(신원·접근 관리, 암호학·키 관리, 공급망).
순환을 응급이 아닌 일상으로 만드세요. 프로바이더 키는 정기 일정에, 그리고 호스팅 벤더가 사고를 공표할 때마다 순환하세요 — 벤더 금고의 침해는 벤더가 알리기로 선택한 때에만 당신에게 보입니다.
프로바이더에서 범위와 상한을 정하세요. 프로바이더 대시보드에 설정한 프로젝트 범위 키와 하드 지출 한도만이, 도난 키가 프로바이더에 직접 쓰이는 것을 제한합니다 — 호스팅 도구의 예산은 그렇지 못합니다(Cyera).

같은 목록에 폐기 규칙을 더하세요: 시스템이 저우선으로 취급되기 전에 데이터 마이그레이션과 삭제가 끝나야 합니다. OpenCode가 잃은 시스템은 이미 은퇴 대상이었지만 여전히 고객 키를 보관하고 있었습니다.