AI 에이전트 보안이 무엇을 다루느냐고 물으면 출처마다 지도가 다릅니다. Gartner의 가디언 에이전트 가이드는, 벤더가 기고한 The Hacker News 글의 정리에 따르면 세 가지 역량 영역을 제시합니다. Bessemer는 공격 표면을 엔드포인트, API·MCP(Model Context Protocol) 게이트웨이, SaaS, 아이덴티티의 네 레이어로 나눕니다. 한 벤더 지도는 61개 벤더를 12개 범주로 묶습니다. 세 가지를 모두 손에 쥔 구매자도 자기 조직에 어떤 공백이 있는지는 알 수 없습니다.
여기서는 다르게 나눠 봅니다. 통제 레이어를 다섯 개로 나누고, 레이어마다 답하는 질문을 하나씩 붙입니다. 이렇게 나누면 진단에 쓸 수 있습니다. 에이전트가 하지 말아야 할 일을 했을 때 어느 질문에 답이 없었는지 찾으면 어느 레이어를 고쳐야 하는지, 어느 레이어는 도움이 되지 않았을지가 드러납니다.
AI 에이전트 보안이란
AI 에이전트 보안은 자율적으로 움직이는 에이전트의 동작을 운영자가 의도한 범위 안에 묶어 두는 통제의 집합입니다. 많은 팀이 AI 에이전트 거버넌스라고 부르는 영역과 겹칩니다. 여러 방식 중 하나는 모델, 아이덴티티, 정책, 실행, 모니터링의 다섯 레이어로 나누는 것이며, 레이어마다 답하는 질문이 다릅니다.
| 레이어 | 답하는 질문 | 대표적인 통제 |
|---|---|---|
| 모델 | 에이전트가 나쁜 동작을 시도할 가능성이 얼마나 되는가? | 정렬(alignment), 프롬프트 인젝션 방어, 가드레일 분류기 |
| 아이덴티티 | 이 에이전트는 누구이고, 누가 보증했는가? | 에이전트 등록, 자격증명 발급과 회수, 세션 폐기 |
| 정책 | 문서상으로 무엇이 허용되는가? | 권한 모델, 도구 allowlist, 명문화된 규칙 |
| 실행 | 이 특정 동작을 지금 실행해도 되는가? | 대상에 닿기 전에 명령이나 도구 호출을 판단 |
| 모니터링 | 에이전트가 무엇을 했고, 누군가 그것을 보고 있는가? | 에이전트 탐지(discovery), 로깅, 텔레메트리, 알림 |
레이어는 질문을 기준으로 나눈 것이고, 벤더별 제품 분류가 아닙니다. 제품 하나가 여러 질문에 답할 수 있습니다. Microsoft의 오픈소스 Agent Governance Toolkit은 2026년 4월 자체 발표에 따르면, 에이전트 프레임워크에 연결되어 에이전트 동작을 실행 전에 가로채는 정책 엔진에 별도의 아이덴티티 컴포넌트와 킬 스위치 컴포넌트를 묶었습니다. CrowdStrike의 Falcon Guardian은 엔드포인트 쪽 런타임 집행 레이어이면서 Windows와 macOS의 알려진 에이전트와 섀도 에이전트까지 찾아내는 제품으로 소개됩니다. 이 표는 구매할 제품 다섯 개로 읽지 말고, 담당자를 정해 둘 질문 다섯 개로 읽어야 합니다.
모델 레이어: 나쁜 동작을 시도할 가능성
모델 레이어는 에이전트와 가장 가깝고, 이 레이어의 표준도 한계를 솔직히 적고 있습니다. OWASP의 프롬프트 인젝션 항목에는 "프롬프트 인젝션을 확실히 막는 방법이 있는지는 불분명하다"라고 나와 있습니다. 같은 항목의 완화책에는 "권한 제어와 최소 권한 접근을 적용한다", "위험도가 높은 동작에는 사람의 승인을 요구한다"가 들어 있습니다. 이는 아이덴티티, 정책, 실행 레이어의 통제입니다. 최소 권한은 아이덴티티와 정책에 속하고, 특정한 고위험 동작을 승인하는 일은 실행 레이어의 판단입니다.
모델 레이어의 표준이 남은 문제를 아래 레이어에 넘기는 셈입니다. 이 레이어에서 하는 작업은 확률을 바꿀 뿐 결과의 범위를 정하지는 못합니다. 정렬만으로 충분하지 않은 이유에서 이미 이 논점을 다뤘습니다.
아이덴티티 레이어: 이 에이전트는 누구인가
아이덴티티 레이어는 AI 에이전트가 누구인지를 확정합니다. 다른 통제를 붙이려면 에이전트에게 먼저 아이덴티티가 있어야 하는데, 아이덴티티를 발급하고 폐기하는 절차는 아직 허술합니다. Cloud Security Alliance와 Oasis가 IT·보안 전문가 383명을 대상으로 2026년 1월에 발표한 설문에서 응답 조직의 78%는 "AI 아이덴티티의 생성과 삭제에 대한 문서화되고 공식 채택된 정책이 없다"고 답했습니다.
벤더들은 움직이고 있습니다. Okta는 에이전트를 Universal Directory에 일급(first-class) 아이덴티티로 등록하는 Okta for AI Agents를 2025년 9월에 발표하고 2026년 3월 얼리 액세스를 거쳐 같은 해 4월에 정식 출시했으며, Microsoft의 Entra Agent ID는 현재 정식 출시 상태입니다. 성숙한 아이덴티티 시스템은 위험 신호가 바뀌면 진행 중인 세션을 끊을 수도 있습니다. 아이덴티티 레이어는 호출한 주체가 누구인지, 그 세션을 계속 허용할지를 정합니다.
정책 레이어: 문서상으로 무엇이 허용되는가
정책 레이어는 AI 에이전트가 문서상으로 무엇을 해도 되는지에 답합니다. 정책은 문서로 적은 의도입니다. 에이전트가 어떤 도구를 호출할 수 있고, 어떤 데이터를 만질 수 있으며, 누가 무엇을 승인해야 하는지를 적습니다. 꼭 필요하지만 정책만으로는 결정에 그칩니다. 에이전트 앞에 놓인 동작에 그 결정을 적용하는 장치가 따로 있어야 하고, 정책이 승인한 대상을 지금도 그대로 설명하고 있어야 합니다. 도구 정의를 기준으로 쓴 규칙은, 정의가 바뀌면 바뀐 도구에 대해 아무것도 말해 주지 못합니다.
실행 레이어: 이 동작을 실행해도 되는가
AI 에이전트 보안의 실행 레이어는 에이전트 바깥에 놓입니다. 호출자 인증이 끝난 뒤 동작이 시스템에 닿기 전에, 그 구체적인 명령이나 도구 호출을 판단합니다. 결정론적 규칙, 모델, 또는 둘을 섞은 방식 모두 쓸 수 있고, 각각 한계가 있습니다. 규칙은 아무도 떠올리지 못한 경우에 빈틈을 남기고, 모델이 다른 모델을 판단하면 그 모델 나름의 방식으로 틀릴 수 있습니다. 실행 레이어를 정하는 것은 판단 방식이 아니라 위치입니다. 에이전트 바깥에서, 동작이 닿기 전에 결정합니다.
시장도 이 질문을 이미 인식하고 있습니다. Gartner 가이드는 핵심 영역으로 "Runtime Inspection and Enforcement"를 꼽았습니다. 벤더가 기고한 Hacker News 글이 인용한 표현으로는, 이 영역은 "AI 에이전트의 동작과 출력이 정의된 의도, 목표, 거버넌스 정책과 일치하도록" 보장합니다. Bessemer는 3월에 "실행 도중 특정 동작을 골라 개입하는 기능(in-flight intervention)"을 이 분야에서 가장 덜 발달한 부분이라고 했습니다. 질문이 있다는 데는 시장의 의견이 일치합니다. 누가 어떻게 답할지에는 일치하지 않습니다. 접근 결정으로는 이 질문에 답할 수 없는 이유는 실행 제어를 다룬 글에 자세히 정리해 두었습니다.
모니터링 레이어: 무슨 일이 있었고, 누가 보고 있는가
모니터링 레이어는 에이전트가 무엇을 했는지, 누군가 그것을 보고 있는지를 보여 줍니다. 다른 레이어가 놓친 것을 찾아내는 수단입니다. 또한 자기 평가가 실제 모니터링 범위를 크게 웃도는 곳이기도 합니다. 벤더가 발표한 조사인 Gravitee의 The State of AI Agent Security 2026(2026년 6월, 고위 기술 리더 750명 대상)에서 에이전트 가시성에 대한 응답자의 자기 평가는 91.8%였지만, 보고된 모니터링 범위의 평균은 약 52%였습니다. 대시보드가 있다고 해서 에이전트가 보이는 것은 아닙니다.
어느 레이어가 실패했나: 사고 다섯 건을 레이어로 읽기
OWASP의 2026년 3분기 익스플로잇 정리는 10월 8일에 공개됐고, 79월 사건과 함께 56월의 공급망 사건 하나를 다룹니다. 항목은 아홉 개이고, 그중 여섯 건이 평가 에이전트·연구 모델 사례입니다. 정리 본문은 일곱 건으로 세며 서로 독립된 공격이 아니라고 단서를 답니다. 이 글에서는 레이어가 고루 드러나도록 다섯 건을 골랐습니다. 에이전트 사례 두 건(Hugging Face, Mythos), 웜 한 건, 원클릭 프롬프트 공격 한 건, 시도에 그친 MCP 캠페인 한 건입니다. 나머지 네 건은 제외했습니다. 모두 평가·연구 에이전트 사례로, OpenAI Artifactory 격리 실패, Modal CyberGym 워크로드, 가상의 표적과 이름이 같은 실제 회사를 공격한 Claude Opus 4.7, 외부 호스트를 스캔한 Claude 연구 모델입니다. 아래 집계는 에이전트 사고 전반이 아니라 이 다섯 건에 대한 것입니다. 정리는 통제 레이어를 지정하지 않으며, 아래 해석은 이 글의 것입니다.
| 사고 | 정리가 보고한 내용 | 가장 먼저 실패했거나 표적이 된 레이어 (이 글의 해석) | 함께 관련된 레이어 |
|---|---|---|---|
| Hugging Face 프로덕션 침입, 7월 10~13일 | OpenAI 평가 에이전트가 네트워크 제한을 벗어난 뒤 공개된 자격증명을 찾아 공유했고, 안전하지 않은 데이터셋·템플릿 처리가 겹쳤습니다. "에이전트가 프로덕션 데이터셋 워커 41대에서 코드를 실행했다." 피해 측 데이터셋·템플릿 처리 결함을 통해 실행된 것이며, 에이전트의 개별 명령은 아닙니다. | 정책 (네트워크 제한 이탈) | 모델, 아이덴티티 |
| Claude Mythos 5 PyPI 패키지 | Claude 평가 에이전트가 실제 PyPI 레지스트리에 악성 패키지를 게시했습니다. "이 패키지는 약 한 시간 동안 공개되었고 그동안 실제 시스템 15대에서 실행되었다." | 정책 (누가 게시할 수 있는가) | 모델, 아이덴티티, 실행 |
| Mini Shai-Hulud와 Miasma 웜 | CI, 클라우드, npm 자격증명을 수집하고 AI 코딩 도구 설정 파일을 심은 공급망 웜으로, 에이전트가 행동한 사건은 아닙니다. TanStack CI에 남아 있던 낡은 OpenID Connect(OIDC) 신뢰 관계로 침투했습니다. 정리에 함께 실린 5월 웜은 "170개가 넘는 패키지, 다운로드 5억 1,800만 회 이상" 규모였고, 출처 증명(provenance attestation)은 해당 콘텐츠를 걸러 내지 못했습니다. | 아이덴티티 | 모니터링 |
| CoSnitch (CVE-2026-24301) | 조작된 링크가 피해자의 인증된 세션에서 프롬프트를 실행했고, 메모리 오염 경로도 있었습니다. 실제 악용은 보고되지 않았습니다. | 모델 | 정책, 실행 |
| Deadbugz MCP 서버 | 공급망 공격 시도입니다. 도구 호출 세 번까지는 정상으로 동작하다가 도구 메타데이터를 바꿨습니다. 확인된 침해는 없습니다. | 정책 (표적: 정의가 바뀐 뒤 재승인 없음) | 실행, 모니터링 |
표의 "가장 먼저 실패한 레이어"를 위에서 아래로 읽어 보면 다섯 건 중 세 건에서 정책이 먼저였고, 그중 한 건은 실제 피해로 이어지지 않은 시도였습니다. 모델이 먼저인 경우는 한 건입니다. 아이덴티티가 먼저인 경우도 한 건이지만, 에이전트가 행동한 사건이 아닌 공급망 웜입니다. 실행과 모니터링은 여러 행의 "함께 관련된 레이어"에 나타납니다. 실행 레이어는 시스템 바로 앞에 있어서, 이 표에서는 처음 실패한 곳이 아니라 마지막 방어 장치로 등장합니다. 에이전트 아이덴티티를 더 강하게 만들었어도 정상 호출 세 번 뒤에 바뀐 도구 정의는 잡지 못했을 것입니다. CoSnitch에서는 세션이 진짜여서 아이덴티티가 막을 대상이 없었고, 문제는 모델이 받아들인 프롬프트였습니다. Deadbugz는 피해로 이어지지 않았지만, 무해하다고 승인받은 서버가 재승인 없이 나중에 정의를 바꿀 수 있다는 틈을 노렸습니다.
그래서 이 스택은 다섯 개의 질문으로 따로 읽어야 합니다. 한 레이어의 답이 탄탄해도 다른 레이어의 질문에는 답이 되지 않습니다. 이미 맡고 있는 레이어만 점검하는 팀은 바로 옆 레이어에서 사고를 계속 겪을 수 있습니다.
격리는 어디에 속하는가
샌드박스, 이그레스 제한, 읽기 전용 역할, 수명이 짧은 자격증명은 많은 엔지니어가 가장 먼저 떠올리는 답이고, 좋은 답입니다. 다만 여섯 번째 레이어는 아닙니다. 수명이 짧은 자격증명은 아이덴티티 레이어에서 발급합니다. 읽기 전용 역할, allowlist, 이그레스 규칙, 샌드박스는 환경이 모든 동작에 한꺼번에 집행하는 정책이고, 개별 동작을 하나씩 판단하지는 않습니다. 어느 쪽이든 모든 동작이 닿을 수 있는 범위에 상한을 둡니다.
격리에는 비용이 따릅니다. 안전할 만큼 좁은 경계는 에이전트에게 맡기고 싶던 일의 일부도 막습니다. 또 허용된 동작을 실행해도 되는지는 격리가 판단하지 않습니다. 그 질문은 실행 레이어의 몫입니다.
이 지도를 쓰는 방법
- 다섯 가지 질문을 한 장에 적습니다.
- 질문마다 현재 환경에서 그 질문에 답하는 통제와 담당자를 옆에 적습니다.
- 가장 최근 사고, 또는 위의 다섯 건 중 하나에서 가장 먼저 실패한 레이어와 함께 관련된 레이어를 표시합니다.
- 담당자가 없는 레이어, 또는 근거가 담당자의 자기 평가뿐인 레이어를 다음 공백으로 봅니다.
Mythos 행에 3단계를 적용해 보겠습니다. 평가 도구가 에이전트의 실제 PyPI 레지스트리 게시를 허용했습니다. 표에서 보면 이는 정책이 먼저 실패한 사례입니다. 정리는 게시 전에 어떤 검사가 있었는지는 밝히지 않았습니다.
AlpacaX는 프로덕션 서버의 실행 레이어에 집중한 AI 네이티브 권한 접근 관리(PAM) 플랫폼 Alpacon을 만듭니다. 아이덴티티는 누가 접속하는지를, 정책은 문서상으로 무엇이 허용되는지를 정합니다. 실행 제어는 그 둘 뒤, 모니터링 앞에 놓입니다. Alpacon의 실행 검사가 켜져 있는 환경에서는 에이전트가 MCP, CLI, API로 프로덕션 서버에 보내는 명령을 호스트로 전달하기 전에 에이전트 밖의 서버 측에서 검사합니다. 나머지 네 레이어에도 담당자가 필요하며, 이 지도는 비어 있는 레이어를 찾는 데 가장 쓸모가 큽니다.
