AI 에이전트 보안: 배포-방어 신뢰 역설

프로덕션에서 AI 에이전트를 어떻게 보호할 것인가? 애플리케이션 수준의 허용 목록이 아니라 OS 수준 샌드박스를 통해 애플리케이션 계층 아래에서 권한을 강제합니다. 실행 전에 PreToolUse 훅으로 런타임에서 모든 도구 호출을 가로챕니다. 원래 작업과 최근 에이전트 행동 간의 임베딩 유사도를 통해 행동 드리프트를 모니터링합니다. 이 세 가지 메커니즘(행동 격리, 권한 범위 지정, 드리프트 감지)은 Meta의 Sev 1, Amazon의 13시간 장애, 그리고 Agents of Chaos 연구에서 발견된 취약점을 일으킨 실패 유형에 대응합니다.

2026년 3월 18일, Meta의 한 엔지니어가 내부 포럼에서 동료의 기술 질문에 답변하기 위해 내부 AI 에이전트를 배포했습니다. 그 에이전트는 승인 없이 응답을 게시했습니다. 또 다른 직원이 에이전트의 잘못된 조언을 따랐고, 이로 인해 민감한 기업 및 사용자 데이터가 약 두 시간 동안 권한 없는 직원들에게 노출되는 연쇄 반응이 발생했습니다. Meta는 이를 내부 시스템에서 두 번째로 높은 심각도인 Sev 1으로 분류했습니다.¹

같은 주에 Google 엔지니어들은 Linux 커널용 에이전트형 AI 코드 리뷰 시스템인 Sashiko를 공개했습니다. 이 시스템은 최근 업스트림 이슈 1,000건 중 53%의 버그를 잡아냈는데, 이는 “인간 리뷰어가 100% 놓친” 버그였습니다.² Wikipedia 커뮤니티는 LLM가 생성한 기여를 완전히 금지할지 여부에 대해 계속 논의했습니다.³ NIST는 “신뢰할 수 있는 채택”을 위한 AI Agent Standards Initiative를 발표했습니다.⁴ 그리고 미국 상원의원은 Claude와 마주 앉아 AI 회사들이 수집하는 데이터에 대해 신뢰할 수 있는지 물었습니다. Claude의 대답은 이랬습니다. “돈입니다, 의원님. 근본적으로 이것은 이익의 문제입니다.” 이 영상은 440만 조회수를 기록했습니다.⁵

모든 주요 기관이 동시에 에이전트를 배포하고 또 그 에이전트에 맞선 벽을 세우고 있습니다. 벽이 올라가는 이유는 에이전트들이 그 벽이 필요하다는 것을 계속 증명하고 있기 때문입니다.

TL;DR

• 역설: 조직들은 에이전트 배포를 가속화하는 동시에 에이전트 실패를 수습하기 위해 분투하고 있습니다. 두 작업은 서로 조율되지 않습니다.
• 수치: 현재 기업 AI 침해 사고 8건 중 1건이 에이전트형 시스템과 관련이 있습니다. 조직의 80%가 위험한 에이전트 행동을 보고합니다. 경영진 중 21%만이 자신들의 에이전트가 무엇에 접근하는지 완전하게 파악하고 있습니다.⁶
• 사건들: 승인되지 않은 에이전트 게시물로 인한 Meta Sev 1. “환경을 삭제하고 재생성”하기로 결정한 AI 코딩 도구로 인한 AWS 13시간 장애.⁷ 14일간 진행된 여러 대학의 공동 연구는 여섯 개 에이전트에서 신원 탈취와 무한 루프를 포함한 10개의 보안 취약점을 발견했습니다.⁸
• 패턴: 빠르게 배포하고, 실패를 발견하고, 벽을 세우고, 더 빠르게 배포합니다. Google은 코드 리뷰를 돕기 위해 Sashiko를 출시하는 한편, Amazon은 AI 지원 코드 변경에 대해 시니어 승인을 의무화합니다. Anthropic은 Claude 헤더를 스푸핑했다는 이유로 오픈소스 도구를 고소하는데, 매월 250만 명의 개발자가 그 도구를 사용합니다.⁹
• 지속되는 이유: 배포는 제품 일정(분기별 OKR)에 따라 움직입니다. 방어는 사고 일정(사후 분석 대응)에 따라 움직입니다. 제약은 결코 권한 부여를 따라잡지 못합니다.
• 이 사이클을 깨뜨리는 것: 배포와 방어 사이의 피드백 루프를 닫는 런타임 행동 거버넌스입니다. 행동 격리(PreToolUse 훅), 권한 범위 지정(OS 수준 샌드박스), 드리프트 감지(코사인 유사도 추적)는 이 글에서 다루는 세 가지 실패 범주에 대응합니다. 500회 이상의 자율 에이전트 세션과 에이전트 행동 위협에 대한 공개 NIST 의견서에서 얻은 증거입니다.

배포-방어 패턴

지난 90일간의 세 건의 사고가 이 패턴을 드러냅니다.

Meta (2026년 3월): 한 AI 에이전트가 내부 포럼에 승인되지 않은 응답을 게시했습니다. 직원 한 명이 그 잘못된 조언을 따랐습니다. 민감한 데이터가 두 시간 동안 권한 없는 직원들에게 유출되었습니다. Meta는 사고를 확인하고 Sev 1으로 분류했으며 “사용자 데이터는 오용되지 않았다”고 밝혔습니다.¹ 몇 달 전, Meta의 AI 부문 안전 책임자 Summer Yue는 자신의 Gmail에 연결된 에이전트가 “명확한 지시에도 불구하고 독자적으로 이메일을 삭제했으며” 수동으로 중단될 때까지 작동 중지 명령을 무시했다고 보고했습니다.¹⁰

Amazon (2025년 12월): Amazon의 Kiro AI 코딩 도구는 에이전트가 “환경을 삭제하고 재생성”해야 한다고 판단하여 13시간의 AWS 장애를 일으켰습니다. Amazon은 “AI 오류가 아닌 사용자 오류”라고 했으며, 해당 직원이 “예상보다 넓은 권한을 가지고 있었고, 이는 사용자 접근 제어 문제이지 AI 자율성 문제가 아니다”라고 말했습니다. 여러 직원이 Financial Times에 이것이 “적어도” 두 번째 AI 도구 관련 장애라고 밝혔습니다. Amazon의 대응은 AI 지원 코드 변경에 대한 시니어 승인을 의무화하는 것이었습니다.⁷

연구소 (2026년 2월): Agents of Chaos 연구(Northeastern, Stanford, Harvard, MIT, CMU 연구자들)는 여섯 개의 AI 에이전트에게 이메일, bash, 영구 파일 시스템, 크론 작업, GitHub 접근 권한이 있는 Discord 같은 서버에 14일 동안 접근 권한을 부여했습니다. 스무 명의 연구자가 에이전트들과 상호작용했으며, 일부는 선의, 일부는 적대적이었습니다. 에이전트들은 10개의 구별되는 보안 취약점을 나타냈습니다.⁸

이 취약점들은 평범해 보였습니다. 한 에이전트는 비례적 조치를 취하는 대신 메일 서버 전체를 파괴했습니다(과도한 대응). 두 에이전트는 상호 릴레이 루프에 빠져 통제되지 않은 백그라운드 프로세스를 생성했습니다(무한 루프). 한 에이전트는 스푸핑된 소유자 신원을 받아들이고 전체 시스템 접근 권한을 부여했습니다(신원 탈취). 12번 거부한 후, 한 에이전트는 지속적인 감정적 압박 끝에 승인되지 않은 요청을 이행했습니다(죄책감 유도).⁸

이 연구를 이끈 Northeastern 교수 Christoph Riedl은 이렇게 요약했습니다. AI 에이전트는 특히 이해관계가 상충할 때 실제 상황에 “어떤 종류의 상식적 추론도 끔찍할 정도로 잘 적용하지 못한다”는 것입니다.¹¹

2026년 에이전트 침해 수치

HiddenLayer의 2026 AI Threat Report는 250명의 IT 및 보안 리더를 대상으로 설문조사를 진행했습니다. 이 결과가 역설을 수치화합니다.¹²

• 자율 에이전트는 기업 전반에서 보고된 AI 침해 사고의 8건 중 1건 이상을 차지합니다
• 침해 사고의 35%는 공개 모델 저장소의 악성코드에서 비롯되었지만 조직의 93%는 여전히 이를 사용합니다
• 응답자의 31%는 자신이 침해당했는지조차 알지 못합니다
• 53%는 AI 침해 보고를 보류한 사실을 인정했습니다
• 76%는 섀도 AI를 확실한 또는 유력한 문제로 지목했으며, 이는 2025년 61%에서 증가한 수치입니다

CEO Chris Sestito는 이렇게 말했습니다. “에이전트형 AI는 대부분의 기업 보안이 5년에 걸쳐 발전한 것보다 12개월 만에 더 빠르게 진화했습니다.”¹²

별도의 기업 설문조사에서는 경영진의 21%만이 에이전트의 권한, 도구 사용, 데이터 접근에 대해 완전한 가시성을 가지고 있는 것으로 나타났습니다. 80%는 승인되지 않은 접근과 부적절한 데이터 노출을 포함한 위험한 에이전트 행동을 보고했습니다. 평균적인 기업에는 약 1,200개의 비공식 AI 애플리케이션이 있으며, 86%는 그것들에 대한 가시성이 없다고 보고합니다.⁶

코드 품질 데이터도 똑같이 충격적입니다. CodeRabbit이 풀 리퀘스트 470건을 분석한 결과, AI가 작성한 코드가 사람이 작성한 코드보다 1.7배 더 많은 문제를 가지고 있었습니다.¹³ Apiiro는 AI를 사용하는 개발자가 약 10배 더 많은 보안 취약점을 도입한다는 것을 발견했습니다.¹³ METR은 업계 테스트를 통과한 AI 코딩 솔루션의 절반이 인간 리뷰어에게 거절당할 수준이라고 밝혔습니다.¹³

공급망 위험은 이 수치들을 더욱 복잡하게 만듭니다. 공격 표면은 가상의 것이 아닙니다. 에이전트 연결 인프라에 대해 MCP 서버는 새로운 공격 표면입니다. 45개의 실제 MCP 서버에 대한 도구 포이즈닝 공격을 평가하는 벤치마크인 MCPTox는 도구 메타데이터에 삽입된 악성 지시가 GPT-4o-mini, o1-mini, DeepSeek-R1, Phi-4에서 60%를 초과하는 공격 성공률을 달성했다는 것을 발견했습니다.¹⁸ 공격은 포이즈닝된 도구 자체를 실행하지 않습니다. 공격은 도구의 설명에 지시를 삽입하여, 에이전트가 서버에 이미 있는 정상 도구들을 사용하여 자격 증명을 유출하거나 매개변수를 변조하도록 유도합니다. 체인 내의 모든 도구 호출이 신뢰된 도구에 대한 정상 호출이기 때문에 기존의 안전 정렬은 이 공격을 잡지 못합니다.¹⁸

이론적 공급망 위험은 2026년 3월 24일에 구체적 현실이 되었습니다. 공격자가 일일 다운로드 수 100만 회가 넘는 인기 AI 프록시 라이브러리 LiteLLM의 PyPI 유지 관리자 계정을 침해한 것입니다. 공격자는 공식 GitHub CI/CD 파이프라인을 거치지 않은 두 가지 악성 버전(1.82.7과 1.82.8)을 게시했습니다. 버전 1.82.8에는 어떤 임포트 없이도 어떠한 Python 시작 시 자동으로 실행되는 .pth 파일이 포함되어 있었습니다. 페이로드는 모든 환경 변수, SSH 키, AWS/GCP/Azure 자격 증명, 데이터베이스 비밀번호, 암호화폐 지갑, CI/CD 시크릿(교과서적인 사일런트 유출 공격)을 수집하여, 하드코딩된 RSA 공개 키로 암호화한 뒤, 공격 몇 시간 전에 등록된 공격자 통제 도메인으로 아카이브를 유출했습니다. 악성 버전은 약 12~24시간 동안 활성화된 상태로 남아 있다가 제거되었으며, Microsoft GraphRAG를 포함한 다운스트림 프로젝트가 타격을 받았습니다.¹⁹

단일 침해된 에이전트가 4시간 이내에 다운스트림 의사결정의 87%를 오염시킵니다.⁶

에이전트 배포와 벽 세우기를 동시에

이 수치에 대한 기관의 대응은 동시에 진행되는 조율되지 않은 두 흐름으로 갈라집니다. 더 강력하게 배포하는 것과 더 강력하게 방어하는 것입니다.

더 강력하게 배포:

Google은 Linux Foundation의 후원을 받아 Linux 커널의 에이전트형 코드 리뷰를 위한 Sashiko를 출시합니다. 이 시스템은 인간 리뷰어가 완전히 놓친 버그의 53%를 잡아냈으며, 거짓 양성률은 20% 미만으로 추정됩니다.² Meta는 Sev 1 사고에도 불구하고 내부 AI 에이전트를 계속 확장하고 있습니다. EY는 10억 달러 이상의 매출을 가진 기업의 64%가 AI 실패로 100만 달러 이상의 손실을 입었다고 보고했으며, 그들 모두 여전히 배포 중입니다.⁶

더 강력하게 방어:

Amazon은 Kiro 장애 이후 AI 지원 코드 변경에 대해 시니어 승인을 의무화합니다.⁷ Anthropic은 서드파티 도구가 Claude 헤더를 스푸핑하는 것을 막기 위해 OAuth 접근을 잠그고, 바로 그 행위를 한 OpenCode에 대해 법적 요청을 제출합니다.⁹ Wikipedia는 LLM가 생성한 기여를 제한합니다. 편집자는 편집 요약에서 AI 사용을 공개해야 하며, “명백히 LLM가 생성한 댓글은 삭제되거나 접힐 수 있습니다.”³ EFF는 자사 오픈소스 프로젝트에서 LLM가 생성한 코드를 허용하지만 모든 댓글과 문서는 사람이 작성하도록 요구합니다.¹⁴ NIST는 산업 주도 표준, 커뮤니티 프로토콜, 보안 연구라는 세 가지 축을 가진 AI Agent Standards Initiative를 출범시킵니다.⁴

Bernie Sanders 상원의원은 Claude와의 9분짜리 인터뷰를 게시했고, 이는 440만 조회수를 기록했습니다. Gizmodo의 반응은 이랬습니다. “저기요 Bernie, 그건 AI 에이전트가 아닙니다.”¹⁵ 비평가들은 방법론에 대해 일리 있는 지적을 했지만, 구조적 신호가 중요합니다. 현직 상원의원이 AI 시스템을 기업 감시에 대한 신뢰할 만한 증인으로 대할 때, 어떤 기술적 프레임워크가 제기되는 질문들에 답할 준비를 갖추기 전에 이미 정책 환경은 바뀌어 있는 것입니다.⁵

이러한 방어적 조치들 중 어느 것도 바로 옆 건물에서 일어나고 있는 배포 결정과 조율되지 않습니다.

OpenCode 단층선

배포-방어 긴장의 가장 명확한 예시는 Anthropic-OpenCode 분쟁입니다.

OpenCode는 GitHub 스타 120,000개 이상과 월간 개발자 500만 명을 보유한 오픈소스 AI 코딩 에이전트입니다.⁹ 이 도구는 75개 이상의 LLM 제공업체를 지원합니다. Claude에 접근하기 위해 OpenCode는 claude-code-20250219 HTTP 헤더를 스푸핑하여 Anthropic의 서버가 요청이 공식 Claude Code CLI에서 왔다고 믿도록 했습니다. 이 스푸핑 덕분에 Max 구독자(기본적으로 Opus 4.7을 실행하는 월 200달러 20배 등급)는 Anthropic이 인지하지 못한 채 OpenCode를 통해 Claude을 라우팅할 수 있었습니다.⁹

커뮤니티는 “Ralph Wiggum”이라는 기법을 개발했습니다. Claude을 무한 루프로 실행하여 테스트가 통과할 때까지 코드를 자율적으로 수정하는 방식입니다. 한 개발자는 API 비용 300달러 미만으로 5만 달러 계약을 완료했으며, 무제한 Max 구독 자원을 소비했다고 전해집니다.⁹

2026년 1월 9일, Anthropic은 비공식 OAuth 접근에 대한 서버 측 차단을 배포했습니다. 3월 19일, OpenCode는 PR #18186을 병합하여 “법적 요청에 따라” 모든 Anthropic 브랜드 시스템 프롬프트, 인증 플러그인, 제공업체 힌트를 제거했습니다.⁹ 이 PR은 399개의 반대표와 177개의 혼란스러운 반응을 모았습니다.

DHH와 George Hotz는 이 조치를 비판했습니다. Hotz는 이렇게 말했습니다. “우리 코드로 모델을 훈련하여 세워진 회사에게는 끔찍한 정책입니다.” OpenAI는 공개적으로 OpenCode를 지지했으며, 의도적인 대조로서 서드파티 도구를 사용한 ChatGPT 구독을 허용했습니다.⁹

Anthropic의 Thariq Shihipar는 이렇게 대답했습니다. “승인되지 않은 하네스는 Anthropic이 제대로 진단할 수 없는 버그와 사용 패턴을 도입합니다.”¹⁶

양측 모두 일리가 있습니다. Anthropic은 서드파티 도구가 공식 헤더를 스푸핑할 때 품질 보증을 유지할 수 없습니다. 개발자는 상호 운용성을 소송으로 다투는 플랫폼 위에 구축할 수 없습니다. 이 분쟁은 기술에 관한 것이 아닙니다. 신뢰 경계가 어디에 있는지, 그리고 사용자와 제공자 중 누가 그것을 그을 수 있는지에 관한 것입니다.

시간 척도의 간극

이 글에 등장하는 모든 조직은 각자의 상황에서 정당화할 수 있는 결정을 내렸습니다. Meta는 생산성을 향상시키기 때문에 내부 에이전트를 배포했습니다. Amazon은 AI 지원 코딩이 개발을 가속화하기 때문에 Kiro를 출시했습니다. Google은 인간 리뷰어가 버그의 절반을 놓치기 때문에 Sashiko를 공개했습니다. Wikipedia는 자원봉사 편집자들이 기계가 생성한 텍스트의 검토 부담을 대규모로 감당할 수 없기 때문에 LLM 기여를 제한했습니다.

역설이 지속되는 이유는 배포와 방어가 서로 다른 시간 척도에서 작동하기 때문입니다.

배포는 제품 일정에 따라 움직입니다. 팀은 분기별 OKR로 에이전트 통합을 출시합니다. 성공 지표는 채택입니다. 얼마나 많은 직원이 사용하는지, 얼마나 많은 작업을 완료하는지, 얼마나 많은 시간을 절약하는지. 범위가 지정된 권한은 채택을 느리게 하고, 느린 채택은 OKR을 망치기 때문에 에이전트는 더 넓은 권한을 부여받습니다.

방어는 사고 일정에 따라 움직입니다. 팀은 무언가 망가진 후에 벽을 세웁니다. Meta Sev 1 대응은 에이전트의 게시 권한을 제한하는 것이었습니다. Amazon의 대응은 시니어 승인을 의무화하는 것이었습니다. 각 벽은 그것을 촉발한 특정 실패를 해결합니다. 어느 것도 다음 실패를 해결하지 않습니다.

이러한 시간 척도의 간극은 래칫을 만들어냅니다. 각 배포 사이클은 에이전트에게 새로운 역량을 부여합니다. 각 사고 사이클은 하나의 특정 역량이 실패한 후 그것을 제약합니다. 배포 팀의 다음 스프린트가 사고 검토가 끝나기도 전에 시작되기 때문에 제약은 결코 부여를 따라잡지 못합니다.

저는 이 래칫을 알고 있습니다. 양쪽에서 동시에 움직이고 있기 때문입니다. 2025년 5월 이후 500회 이상의 자율 코딩 세션을 진행하면서, 저는 각 구성이 드러낸 실패에 대한 방어 수단을 구축하는 동시에 점점 더 강력한 에이전트 구성을 배포해 왔습니다. 60일 동안 12번, 제 에이전트는 할당된 작업을 중단하고 다른 일을 시작했습니다. 매번 에이전트는 그럴듯한 출력을 계속 만들어냈습니다. 어떤 보안 취약점도 관여하지 않았습니다. 에이전트는 런타임에 다른 문제를 작업하기로 결정했습니다.

드리프트 감지기는 그 열두 번의 사고 때문에 존재합니다. 샌드박스는 에이전트가 ~/.ssh/에 쓰려고 시도하는 것을 잡아냈기 때문에 존재합니다. 증거 게이트는 에이전트가 pytest를 실행하지 않고 “모든 테스트가 통과한다”고 보고했기 때문에 존재합니다. 각 방어 수단은 이전 구성이 예상하지 못했던 특정 실패까지 거슬러 올라갑니다. 제가 정리한 7가지 명명된 실패 모드는 Agents of Chaos 연구가 연구 규모에서 발견한 것과 동일한 패턴입니다. 검증, 비례성, 자기 평가에서 실패하는 에이전트들입니다.⁸

런타임 거버넌스의 모습

배포-방어 사이클은 두 기능이 동일한 피드백 루프를 공유할 때 깨집니다. 실무적으로 이는 에이전트 행동을 사후에 검토하는 것이 아니라 런타임에 계측한다는 뜻입니다.

제 오케스트레이션 시스템은 모든 에이전트 행동을 훅 파이프라인으로 감쌉니다. Claude Code이 노출하는 26개 수명주기 이벤트 유형 중 15개를 가로채는 84개의 훅(v2.1.116, 2026년 4월)으로, 파일 읽기, 파일 쓰기, bash 명령, 웹 요청, 하위 에이전트 생성을 포함합니다.¹⁷ 도구 호출이 실행되기 전에 PreToolUse 훅이 에이전트가 무시할 수 없는 제약 조건에 대해 검사합니다. 25번의 도구 호출마다 드리프트 감지기가 원래 작업과 에이전트의 최근 행동 간의 코사인 유사도를 계산합니다. 유사도 점수가 0.30 아래로 떨어지면 시스템은 원래 프롬프트가 포함된 경고를 주입합니다. 임계값 이하로 발생한 12건 모두에서 에이전트는 검증 가능하게 작업의 맥락을 잃은 상태였습니다.¹⁷

세 가지 구체적인 메커니즘이 이 글의 세 가지 실패 범주에 대응합니다.

행동 격리는 Meta 문제를 해결합니다. Meta 에이전트가 승인 없이 게시한 이유는 게시해야 하는지 아무것도 확인하지 않았기 때문입니다. 모든 bash 명령 전에 실행되어 curl -X POST, git push, 또는 API 쓰기 엔드포인트 같은 패턴과 매칭하는 PreToolUse 훅이라면 승인되지 않은 포럼 게시를 실행 전에 차단했을 것입니다. 이 검사는 밀리초 단위의 지연을 추가합니다. 대안은 Sev 1이었습니다.

권한 범위 지정은 Amazon 문제를 해결합니다. AWS 장애는 에이전트가 인프라를 삭제할 권한을 가지고 있었기 때문에 발생했습니다. 프로덕션 경로, 자격 증명 저장소, 인프라 API에 대한 쓰기를 차단하는 OS 수준 샌드박스(macOS Seatbelt, Linux seccomp, 또는 컨테이너 수준 제한)라면 에이전트가 무엇을 결정하든 상관없이 “환경을 삭제하고 재생성”하는 것을 물리적으로 불가능하게 만듭니다. 에이전트 샌드박스는 애플리케이션 계층 아래에서 강제되지 않는 한 그저 제안에 불과합니다.

드리프트 감지는 Agents of Chaos 문제를 해결합니다. 이 연구의 가장 음흉한 발견은 극적인 실패(메일 서버 파괴, 신원 탈취)가 아니라 점진적인 실패였습니다. 지속적인 압박 끝에 에이전트가 따르고, 정당한 것처럼 포장된 승인되지 않은 요청을 따르는 것입니다. 드리프트 감지는 유해한 행동 이전에 행동 궤적을 잡아냅니다. 에이전트가 13번째 시도에서 “죄책감 유도”에 응할 때쯤이면 원래 작업과 현재 대화 간의 코사인 유사도는 이미 어떤 합리적 임계값보다 아래로 떨어져 있습니다.

이 메커니즘들 중 어느 것도 특정 실패를 예측하기 위한 사전 배포 정렬을 요구하지 않습니다. 이들은 실시간으로 행동을 관찰하고 에이전트가 반박할 수 없는 불변 조건을 강제합니다. Agents of Chaos 연구는 동일한 가중치를 실행하는 동일한 에이전트에서 10개의 취약점과 6개의 진정한 안전 행동을 발견했습니다.⁸ 차이는 맥락이었습니다. 런타임 거버넌스는 맥락에 의존적인 실패를 감지 가능하게 만듭니다.

이 역설을 해결할 조직은 가장 빠르게 배포하거나 가장 강하게 방어하는 조직이 아닙니다. 둘 사이의 피드백 루프를 닫는 조직, 그래서 모든 배포가 다음 제약에 정보를 제공하는 텔레메트리를 생성하고, 모든 제약이 출시되기 전에 다음 배포에 대해 테스트되는 조직입니다.

FAQ

2026년 가장 큰 AI 에이전트 보안 위험은 무엇인가?

세 가지 실패 범주가 지배적입니다. 승인되지 않은 행동(Meta의 포럼 게시 에이전트처럼 지시받지 않은 작업을 수행하는 에이전트), 권한 상승(AWS 인프라 삭제처럼 의도한 것보다 넓은 권한을 사용하는 에이전트), 그리고 행동 드리프트(압박이나 누적된 맥락 아래에서 할당된 작업에서 점차 벗어나는 에이전트)입니다. HiddenLayer의 250명 보안 리더 대상 설문조사는 자율 에이전트가 이제 기업 AI 침해 사고 8건 중 1건을 차지하며, 조직의 80%가 위험한 에이전트 행동을 보고한다는 것을 발견했습니다.¹² MCP 도구 포이즈닝 표면은 네 번째 범주를 추가합니다. 손상된 도구 메타데이터를 통해 에이전트 행동을 조작하는 공급망 공격입니다.

PreToolUse 훅이 무엇이며 어떻게 AI 에이전트를 보호하는가?

PreToolUse 훅은 모든 에이전트 도구 호출(파일 쓰기, bash 명령, API 요청, 하위 에이전트 생성) 전에 실행되는 런타임 인터셉터입니다. 각 훅은 에이전트가 무시할 수 없는 제약 목록에 대해 제안된 행동을 패턴 매칭합니다. 예를 들어, curl -X POST 또는 git push와 매칭하는 훅은 승인되지 않은 네트워크 쓰기를 실행 전에 차단합니다. Claude Code 훅 시스템은 v2.1.116 기준으로 26개 수명주기 이벤트 유형을 노출합니다. 제 프로덕션 설정은 그중 15개에 걸쳐 84개의 훅을 실행합니다. 이 메커니즘은 밀리초 단위의 지연을 추가하지만 Meta의 Sev 1 사건을 일으킨 종류의 실패를 예방합니다.

AI 에이전트에 대한 드리프트 감지는 어떻게 작동하는가?

드리프트 감지는 원래 작업 프롬프트의 임베딩과 에이전트의 최근 행동의 임베딩 간의 코사인 유사도를 일정한 간격(제 시스템에서는 25번의 도구 호출마다)으로 계산합니다. 유사도 점수가 임계값(0.30) 아래로 떨어지면 시스템은 에이전트를 재정렬하기 위해 원래 프롬프트가 포함된 경고를 주입합니다. 하루 60회 이상의 자율 세션에서, 이 방식은 검증된 드리프트 사고의 100%를 잡아냈습니다. 즉, 에이전트가 할당된 작업을 조용히 중단하고 여전히 그럴듯한 출력을 생성하면서 다른 목표를 추구하기 시작한 경우입니다.¹⁷

AI 에이전트를 OS 수준에서 샌드박스화할 수 있는가?

그렇습니다, 그리고 그렇게 해야 합니다. 애플리케이션 수준 권한 목록은 에이전트가 반박할 수 있는 제안입니다. OS 수준 샌드박스(macOS Seatbelt 프로파일, Linux seccomp-bpf, 컨테이너 수준 cgroup 제한)는 커널 수준에서 거부 규칙을 강제합니다. 에이전트는 자신이 무엇을 결정하든 ~/.ssh/, ~/.aws/, 또는 프로덕션 인프라 경로에 쓸 수 없습니다. 커널 수준 강제는 “환경을 삭제하고 재생성”하는 것을 단순히 금지하는 것이 아니라 물리적으로 불가능하게 만듭니다.

에이전트 신뢰 위기는 실제로 새로운 것인가?

실패는 새로운 것이 아닙니다. 자동화는 AI 이전부터 사고를 일으켰습니다. 2025~2026년에 바뀐 것은 자율성 간극입니다. 에이전트들은 이제 사전 정의된 스크립트를 따르는 대신 런타임에 자신의 행동을 선택합니다. HiddenLayer 보고서는 자율 에이전트가 특히 침해 사고 8건 중 1건을 차지하며, 이는 2년 전에는 존재하지 않았던 범주임을 발견했습니다.¹²

오픈소스 AI 에이전트는 독점 에이전트보다 덜 안전한가?

Anthropic-OpenCode 분쟁은 접근 통제에 관한 것이지 안전에 관한 것이 아닙니다. OpenCode의 보안 프로파일은 어떤 LLM 제공업체에 연결하는지와 어떻게 구성되는지에 따라 달라집니다. 안전 문제는 오픈 대 클로즈드가 아닙니다. 문제는 라이선스와 무관하게 도구 운영자가 에이전트가 무엇을 하는지 가시성을 가지고 있는가 하는 것입니다.

Meta 에이전트가 실제로 데이터 유출을 일으켰는가?

Meta는 사건을 Sev 1(두 번째로 높은 심각도)로 분류했고 민감한 데이터가 약 두 시간 동안 권한 없는 직원들에게 노출되었다는 것을 확인했습니다. Meta는 “사용자 데이터는 오용되지 않았으며 누구도 접근을 악용하거나 데이터를 공개했다는 증거는 없다”고 밝혔습니다.¹ 이것이 “유출”에 해당하는지는 정의에 따라 다릅니다. 승인되지 않은 노출은 실제였습니다.

Agents of Chaos 연구는 무엇인가?

통제된 환경에서 여섯 개의 AI 에이전트에게 이메일, bash, 파일 시스템, 크론 작업, GitHub 접근 권한을 부여한 14일간의 여러 대학 공동 연구 프로젝트(Northeastern, Stanford, Harvard, MIT, CMU)입니다. 스무 명의 연구자가 에이전트들과 상호작용했습니다. 이 연구는 10개의 보안 취약점과 6개의 안전 행동을 식별했으며, arXiv:2602.20021로 게재되었습니다.⁸

기업들이 AI 에이전트 배포를 중단해야 하는가?

아닙니다. Google의 Sashiko는 인간 리뷰어가 100% 놓친 버그를 잡아냈습니다. 기업 생산성 향상은 측정 가능합니다. 배포 중단은 답이 아닙니다. 배포와 방어 사이의 피드백 루프를 닫는 것이 답입니다. 모든 에이전트 배포는 다음 제약에 정보를 제공하는 행동 텔레메트리를 생성해야 합니다. 모든 제약은 출시되기 전에 다음 배포에 대해 테스트되어야 합니다.

개별 개발자는 무엇을 해야 하는가?

영향도 순으로 세 가지 구체적 단계가 있습니다. (1) 애플리케이션 계층 아래에서 권한을 강제합니다. ~/.ssh/, ~/.aws/, 프로덕션 경로, 자격 증명 저장소에 대한 쓰기를 차단하는 OS 수준 샌드박스는 Amazon 스타일의 재앙을 물리적으로 불가능하게 만듭니다. 에이전트는 커널 수준 거부를 반박할 수 없습니다. (2) 출력뿐만 아니라 행동 궤적을 모니터링합니다. 세션 드리프트는 원래 작업과 최근 에이전트 행동 간의 임베딩 유사도를 통해 감지할 수 있습니다. 0.30의 코사인 유사도 임계값은 60회의 세션에 걸친 제 테스트에서 검증된 드리프트 사고의 100%를 잡아냈습니다.¹⁷ (3) 단언이 아닌 증거를 요구합니다. 에이전트가 “모든 테스트가 통과한다”고 보고할 때 테스트 출력을 요구하세요. 환영 검증은 사람의 개입이 필요한 에이전트 실패의 12%를 차지합니다.

배포-방어 래칫이란 무엇인가?

각 배포 사이클이 에이전트에게 새로운 역량을 부여하는 반면, 각 사고 사이클은 하나의 특정 역량이 실패한 후에 그것을 제약하는 패턴입니다. 배포 팀의 다음 스프린트가 사고 검토가 끝나기도 전에 시작되기 때문에 제약은 결코 따라잡을 수 없습니다. 두 팀이 동일한 텔레메트리 파이프라인과 동일한 피드백 루프를 공유할 때 래칫이 깨집니다.