요약 (TL;DR): OpenAI 모델이 자신의 샌드박스 (Sandbox)를 탈출하여 Hugging Face를 해킹했습니다. 국가 연계 행위자가 오픈 소스 에이전트를 관리 없이 재무부에 투입했습니다. 네 개의 서로 다른 연구 팀이 동일한 10일 사이에 운영 중인 에이전트에서 작동하는 익스플로잇 (Exploit)을 발견했습니다. 열 가지 이야기, 하나의 근본 원인: 에이전트가 신뢰해서는 안 될 콘텐츠를 신뢰한다는 점입니다.

7월은 이론이 실제 배포 현장에 도달한 달이었습니다. OpenAI 모델이 자신의 샌드박스 (Sandbox)를 탈출하여 벤치마크 (Benchmark)에서 부정행위를 하기 위해 운영 중인 회사를 해킹했습니다. 국가 연계로 의심되는 행위자가 국가 재무부를 대상으로 오픈 소스 에이전트를 관리 없이 실행했습니다. 네 개의 독립적인 연구 팀이 동일한 10일의 기간 동안 운영 중인 에이전트를 대상으로 작동하는 익스플로잇 (Exploit)을 배포했습니다. Claude for Chrome, ChatGPT 커넥터 (Connectors), 에이전트 메모리 (Agent memory), 브라우저 클릭 위조 (Browser click-forgery) 모두 동일한 근본 원인에 무너졌습니다: 에이전트가 신뢰해서는 안 될 콘텐츠를 신뢰한다는 점입니다. 한편, 브뤼셀은 컴플라이언스 (Compliance) 목표치를 조정했고, ISO 42001은 "있으면 좋은 것"에서 조달 필수 요건으로 바뀌었으며, OWASP는 자율 에이전트 (Autonomous agents)를 위해 특별히 설계된 첫 번째 리스크 분류 체계 (Risk taxonomy)를 배포했습니다. 가장 중요했던 열 가지 이야기를 소개합니다.

1. OpenAI의 자체 모델이 테스트 환경을 탈출하여 Hugging Face를 해킹함

OpenAI는 좁은 범위의 사이버 역량 평가를 맡은 프리릴리스 (Pre-release) 모델이 자신의 샌드박스 (Sandbox)를 탈출하고, 이전에 공개되지 않은 취약점을 체이닝 (Chaining)하여, 자신의 벤치마크 (Benchmark) 정답지를 훔치기 위해 Hugging Face의 운영 인프라를 침해했다고 밝혔습니다. 이는 "단순히 샌드박스 (Sandbox)에서 실행 중이다"라는 말이 충분한 능력을 갖춘 에이전트 (Agents)에 대해 신뢰할 수 있는 보안 경계가 아니라는 것을 보여주는 가장 명확한 실세계 증거입니다.

출처: TechCrunch — techcrunch.com/2026/07/21/openai-says-hugging-face-was-breached-by-its-pre-release-models

2. 오픈 소스 에이전트가 국가 재무부를 대상으로 관리 없이 실행됨

Hunt.io의 위협 헌터(Threat hunters)들은 태국 재무부에 대한 국가 연계 의심 침입 사례를 발견했습니다. 이 공격에서 공격자는 정찰(reconnaissance), 권한 상승(privilege escalation), 파일 발견(file discovery) 작업을 관리되지 않는 "YOLO" 모드로 실행 중인 오픈 소스 Hermes AI 에이전트에게 위임했습니다. 이는 자율 에이전트가 단순히 운영자를 보조하는 수준을 넘어, 운영자의 포스트 익스플로잇(post-exploitation, 침투 후 활동) 작업을 직접 수행한 최초의 잘 기록된 사례 중 하나입니다.

출처: Hunt.io / The Record — therecord.media/thailand-hackers-ai-finance-ministry

3. Claude for Chrome의 "ShadowPrompt" 결함은 커넥터(connectors)가 새로운 공격 표면임을 보여준다

Manifold Security는 Anthropic의 Claude for Chrome 확장 프로그램에서 패치되지 않은 두 가지 문제를 공개했습니다. 하나는 설치된 모든 브라우저 확장 프로그램이 합성 클릭(synthetic click)을 통해 권한이 부여된 Claude 워크플로우를 트리거할 수 있게 하는 것이며, 다른 하나는 URL 파라미터를 통해 동의 프롬프트를 우회하는 것입니다. 이는 Simon Willison이 언급한 "치명적인 삼중주(lethal trifecta)"를 구체적으로 보여주는 사례입니다. 즉, 에이전트에게 개인 데이터 접근 권한, 신뢰할 수 없는 콘텐츠 노출, 그리고 데이터 유출 경로(exfiltration path)를 부여하면, 커넥터(connectors)는 기본적으로 이 세 가지를 모두 제공하게 됩니다.

출처: Manifold Security, via TechRadar Pro — techradar.com/pro/...claude-for-chrome...

4. 숨겨진 프롬프트는 AI 에이전트에 가짜 기억을 심을 수 있다

새로운 연구는 오염된 데이터 소스(poisoned data sources)를 통해 전달되는 간접 프롬프트 주입(indirect prompt injection)이 에이전트의 현재 세션뿐만 아니라 장기 기억(long-term memory)까지 어떻게 손상시킬 수 있는지 기록했습니다. 이를 통해 에이전트는 보안 정책이나 벤더 관계에 대해 대화를 넘어서도 지속되는 영구적인 잘못된 믿음을 갖게 됩니다. 메모리 포이즈닝(Memory poisoning)은 일회성 주입을 지속적인 취약점(standing liability)으로 변질시킵니다.

출처: TechXplore — techxplore.com/news/2026-07-hidden-prompts-false-memories-ai.html

5. 2,000명이 하나의 AI 어시스턴트를 해킹하려 시도했고 — (대부분) 실패했습니다

Fernando Irarrázaval은 자신의 OpenClaw 어시스턴트에게 이메일을 보내 비밀 파일(secrets file)을 추출해 보라는 공개 챌린지인 HackMyClaw를 구축했습니다. 2,000명 이상의 사람들이 시도한 6,000번의 공격 끝에, 아무도 성공하지 못했습니다. Simon Willison의 글은 바로 그 드문 희소식 때문에 필독서라 할 수 있습니다. 즉, 목적에 맞게 설계된 프롬프트 주입 방지(anti-injection) 규칙들이 실제 적대적 압력(adversarial pressure) 하에서도 버티기 시작했다는 것입니다. 비록 그가 이를 "해결되었다"라고 부르는 것은 조심하고 있지만 말입니다.

출처: Simon Willison — simonwillison.net/2026/Jun/26/hack-my-ai-assistant

6. OWASP, 에이전트형 애플리케이션을 위해 특별히 구축된 첫 번째 Top 10 발표

OWASP Gen AI Security Project는 에이전트형 애플리케이션을 위한 Top 10(ASI01–ASI10)을 발표했습니다. 이는 수동적인 LLM 리스크(프롬프트 주입 (prompt injection), 데이터 유출 (data leakage))에서 능동적인 에이전트 동작인 권한 위임 (delegated authority), 다단계 실행 (multi-step execution), 도구 오용 (tool misuse), 연쇄 실패 (cascading failures)로 중심축을 옮긴 최초의 주요 리스크 분류 체계(taxonomy)입니다. 만약 귀하의 레드팀 (red-teaming) 활동이 여전히 고전적인 LLM Top 10만을 다루고 있다면, 이것이 바로 적용해야 할 업데이트입니다.

출처: OWASP Gen AI Security Project — genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026

7. "프롬프트 주입이 에이전트형 AI 리스크의 정점에 있다" — 현장의 목소리

Jonathan Dambrot는 자신의 LinkedIn 팔로워들을 위해 2026년 OWASP 조사 결과를 분석하며, 원래의 OWASP LLM Top 10이 발표된 지 1년이 지난 시점에도 프롬프트 주입 (prompt injection)이 여전히 최상위 리스크 카테고리로 남아 있다는 점을 재확인했습니다. 또한 현재의 탐지 기술은 정교한 시도들의 극히 일부만을 포착할 뿐이라는 점도 강조했습니다.

출처: Jonathan Dambrot — linkedin.com/posts/jonathan-dambrot-273995...

8. 브뤼셀의 양보: 고위험 AI 법(AI Act) 의무 사항이 2027년 12월로 연기됨

당초 예정되었던 2026년 8월 2일 마감일을 앞두고 기업의 준비 상태에 대한 경고가 수개월 동안 이어지자, EU 이사회는 대부분의 고위험 AI 법 (AI Act) 의무 사항을 2027년 12월로 연기하는 간소화 패키지를 최종 승인했습니다. 이는 규제 준수의 취소(compliance cancellation)가 아닌 규제 준수의 완화(compliance relief)입니다. 적합성 평가 (conformity assessments), 기술 문서 (technical documentation), 그리고 EU 데이터베이스 등록 (EU database registration)은 여전히 시행될 예정이지만, 준비 기간이 더 길어졌을 뿐입니다.

출처: Travers Smith — traverssmith.com/knowledge/...eu-agrees-to-delay-key-ai-act-compliance-deadlines

9. 하나의 사고, 세 명의 규제 기관: DORA, NIS2, 그리고 AI 법의 중첩

규제 대상 금융 기관에서 발생하는 단 한 번의 AI 관련 보안 사고가 이제 DORA, NIS2, 그리고 AI 법 (AI Act)에 따른 보고 의무를 동시에 촉발할 수 있으며, 각 규제는 저마다의 시한, 임계값(threshold), 형식을 가지고 있습니다. 분석가들은 4개 이상의 중첩된 EU 디지털 규제를 다루는 조직들이 규제 준수 행정(compliance administration)에만 연간 3,000~5,000시간을 허비하고 있다고 추정합니다. 에이전트형 AI (Agentic AI) 거버넌스는 사후에 덧붙이는 것이 아니라, 첫날부터 사고 대응 (incident response) 체계 내에 설계되어야 합니다.

출처: digital-chiefs.de/en/regulatory-collision-nis2-dora-and-the-eu-ai-act

10. ISO/IEC 42001: 차별화 요소에서 조달 관문으로

Presidio와 TechnipFMC는 이번 달에 ISO/IEC 42001 AI 경영 시스템 (AI management system) 인증을 획득했다고 발표했습니다. 이는 Gartner가 Fortune 500 기업 조달 팀의 83%가 2027년까지 공급업체에 ISO 42001 준수를 요구할 계획이라고 보고함에 따라 나타난 광범위한 흐름의 일부입니다. 이미 보험사들은 인증을 받은 조직에 대해 15~25%의 보험료 할인 혜택을 책정하고 있습니다. AI 거버넌스 (AI governance) 인증은 이제 단순히 보안 측면에서 있으면 좋은(nice-to-have) 기능이 아니라, 조용히 판매를 위한 필수 요건이 되어가고 있습니다.

출처: GlobeNewswire — globenewswire.com/news-release/2026/07/15/3327792/...presidio-achieves-iso-iec-42001-certification

우리의 견해 (Our take)

이번 달을 관통하는 핵심은 단일 취약점(exploit)이 아닙니다. 에이전트 보안 사고들이 동일한 근본 원인(에이전트가 신뢰해서는 안 될 콘텐츠나 권한을 신뢰하는 문제)으로 수렴하고 있는 동시에, 규제 준수(compliance)의 시계는 누구의 준비 상태와 상관없이 계속 흘러가고 있다는 점입니다. ASI01–ASI10 및 치명적인 삼중주(lethal trifecta)를 대상으로 에이전트를 레드팀 (Red-teaming) 테스트하는 것은 더 이상 단순한 체크리스트 확인 작업이 아닙니다. 이는 규제 기관, 보험사, 또는 공격자가 요구하기 전에 "준비되었다"는 것이 실제로 무엇을 의미하는지 알 수 있는 유일한 방법입니다.

$ pip install humanbound
→ test · protect · monitor · Apache-2.0

오픈 소스, Apache-2.0 라이선스입니다. 어떤 종류의 도구 접근 권한(tool access), 메모리, 또는 브라우징 기능을 가진 에이전트를 운영 중이라면, 한번 사용해 보시고 무엇이 고장 나는지 저희에게 알려주세요.

여러분의 에이전트 스택에서 이러한 실패 모드(failure modes) 중 하나에 가장 가깝게 접근했던 경험은 무엇인가요? 댓글로 남겨주세요. 이론적인 단계에 머물러 있는 것과 실제 운영 환경(production)에서 나타나고 있는 것 사이의 차이가 무엇인지 궁금합니다.