Saram Consulting2026년 4월, 마이크로소프트는 Agent Governance Toolkit을 오픈소스로 공개했습니다. MIT 라이선스가 적용된 이 7개의 패키지는 밀리초 미만(sub-millisecond)의 정책 집행 능력을 통해 OWASP Agentic AI의 10대 위험을 모두 해결한다고 명시했습니다. 이어 5월에는 Google Cloud Next ’26에서 Agent Identity, Agent Gateway, Model Armor를 일급 플랫폼 서비스(first-class platform services)로 전격 공개했습니다. 한편, AWS는 이미 2025년 12월에 Cedar 기반의 결정론적 정책 집행을 갖춘 Bedrock AgentCore를 출시한 바 있습니다.
지구상에서 가장 거대한 인프라 기업 3곳이 이제 동일한 질문을 두고 각자의 입지를 확고히 다졌습니다. 바로 **“자율적으로 추론하고, 계획을 세우며, 행동하는 AI 에이전트의 주변에 어떻게 보안 경계를 구축하고 집행할 것인가?”**라는 질문입니다. 이들이 내놓은 답은 아키텍처적으로 상이하고 일부 영역에서는 철학적으로 대립하며, 올해 프로덕션 환경에 에이전트를 배포하려는 모든 팀이 직면한 가장 중요한 인프라 결정 사항입니다.
본 글에서는 이 세 가지 접근 방식을 면밀히 분석하고, 이를 OWASP Agentic Top 10에 매핑하며, 조직에 적합한 플랫폼을 선택할 수 있는 의사결정 프레임워크를 제공합니다.
지금 이 문제가 중요한 이유
AI 에이전트는 더 이상 단순한 챗봇이 아닙니다. 비행기 표를 예매하고, 거래를 체결하며, 코드를 작성해 배포하고, 인프라를 관리하며, 데이터베이스를 조회하고, 이메일을 발송하며, 금융 거래를 유발합니다. LangChain, AutoGen, CrewAI, Microsoft Agent Framework와 같은 프레임워크 덕분에 이러한 에이전트를 구축하는 일은 놀라울 정도로 쉬워졌습니다. 하지만 거버넌스 인프라는 이러한 발전 속도를 따라가지 못했습니다.
두 가지 규제 기한으로 인해 이 문제는 매우 시급한 과제가 되었습니다:
- EU AI 법안(EU AI Act) 고위험 의무 조항이 2026년 8월부터 발효됩니다.
- **콜로라도 AI 법안(Colorado AI Act)**이 2026년 6월부터 시행됩니다.
OWASP GenAI Security Project는 2025년 12월, 자율 에이전트 위험에 대한 최초의 공식 분류 체계인 ’에이전트 애플리케이션을 위한 10대 보안 위험(Top 10 for Agentic Applications)’을 발표했습니다. 여기서 논의되는 모든 플랫폼은 이를 해결할 수 있다고 주장합니다. 이제 관건은 그 해결책이 얼마나 심층적이며 얼마나 진실한가입니다.
OWASP Agentic Top 10: 우리가 방어해야 할 위험
플랫폼을 비교하기 전에, 먼저 이들이 무엇을 해결하려 하는지 이해해야 합니다. OWASP Agentic Top 10은 자율 AI 에이전트에 특화된 10가지 위험 범주를 정의합니다:
| ID | 위험 (Risk) | 한 줄 요약 |
|---|---|---|
| ASI01 | 에이전트 목표 하이재킹 (Agent Goal Hijack) | 공격자가 에이전트가 달성하려는 본래 목표를 탈취 및 변경함 |
| ASI02 | 도구 오용 및 악용 (Tool Misuse & Exploitation) | 에이전트가 정상적인 도구를 안전하지 않거나 의도치 않은 방식으로 사용함 |
| ASI03 | 신원 및 권한 남용 (Identity & Privilege Abuse) | 위임 체인(delegation chains) 및 캐시된 자격 증명이 악용됨 |
| ASI04 | 에이전트 공급망 위험 (Agentic Supply Chain) | 악성 플러그인, MCP 서버 또는 서드파티 에이전트의 유입 |
| ASI05 | 예기치 않은 코드 실행 (Unexpected Code Execution) | 에이전트가 의도치 않은 코드를 생성하거나 실행함 |
| ASI06 | 메모리 및 컨텍스트 오염 (Memory & Context Poisoning) | 여러 세션에 걸쳐 저장된 컨텍스트가 오염됨 |
| ASI07 | 안전하지 않은 에이전트 간 통신 (Insecure Inter-Agent Communication) | 에이전트 간 주고받는 메시지가 도청되거나 위조됨 |
| ASI08 | 연쇄 장애 (Cascading Failures) | 한 에이전트의 오류가 전체 시스템으로 전파됨 |
| ASI09 | 인간-에이전트 신뢰 악용 (Human-Agent Trust Exploitation) | 에이전트를 매개로 한 사회공학적 공격 |
| ASI10 | 제어 불능 에이전트 (Rogue Agents) | 에이전트가 의도된 매개변수 범위를 벗어나 자율적으로 동작함 |
OWASP 프레임워크는 중대한 개념 하나를 도입합니다. 바로 **최소 에이전시(Least-Agency)**입니다. 이는 불필요한 곳에는 에이전트적 자율성을 부여하지 말아야 한다는 논리로, 전통적인 최소 권한(Least-Privilege) 원칙을 확장한 것입니다. 불필요한 자율성은 어떠한 가치도 더하지 못한 채 공격 표면만 넓히기 때문입니다. 이는 모든 거버넌스 플랫폼이 반드시 응답해야 하는 철학적 뼈대입니다.
Microsoft Agent Governance Toolkit: 운영체제 커널 메타포
출시: 2026년 4월 2일 | 라이선스: MIT | 지원 언어: Python, TypeScript, Rust, Go, .NET
마이크로소프트는 AI 에이전트를 바라보며, 수십 년 전 운영체제가 해결했던 것과 똑같은 문제를 발견했습니다. 즉, 신뢰할 수 없는 여러 프로그램이 자원을 공유하고, 결정을 내리며, 제한적인 중재 하에 외부 세계와 상호작용하는 문제입니다. 마이크로소프트의 해답은 지난 40년간 검증된 커널, 권한 링(privilege rings), 프로세스 격리 패턴을 차용하여 이를 에이전트에 적용하는 것이었습니다.
이 툴킷은 독립적으로 설치 가능한 7개의 패키지로 구성되어 있습니다:
Agent OS는 핵심 엔진으로, 실행 전에 모든 에이전트 액션을 가로채는 무상태(stateless) 정책 엔진입니다. 세 가지 정책 언어(YAML 규칙, OPA Rego, Cedar)를 지원하며 0.1ms 미만의 p99 지연 시간을 자랑합니다. AI 에이전트를 위한 시스템 콜 인터셉터(system call interceptor)라고 이해하시면 됩니다.
Agent Mesh는 Ed25519 서명이 적용된 탈중앙화 식별자(DID)를 사용하여 암호학적 신원을 제공합니다. 에이전트 간 신뢰 프로토콜(Inter-Agent Trust Protocol, IATP)은 안전한 에이전트 간 통신을 처리합니다. 동적 신뢰 점수(Dynamic trust scoring)는 5개 행동 등급을 기준으로 0~1000점 척도로 산정되며, 신뢰는 한 번 부여되고 끝나는 것이 아니라 지속적으로 획득되고 감쇠(decay)됩니다.
Agent Runtime은 CPU 권한 레벨에서 영감을 얻은 실행 링(execution rings)을 구현합니다. 더 높은 권한의 작업은 더 높은 링의 승인을 요구합니다. 비상용 킬 스위치(kill switch)를 통해 에이전트를 즉각 종료할 수 있으며, 사가 오케스트레이션(Saga orchestration)은 롤백을 포함한 다단계 트랜잭션을 처리합니다.
Agent SRE는 SLO, 에러 버짓, 서킷 브레이커, 카오스 엔지니어링, 점진적 배포(progressive delivery) 등 프로덕션 안정성 엔지니어링 실무를 에이전트 시스템에 도입합니다. 이 패키지는 구글이나 AWS가 직접적으로 다루지 않는 ASI08(연쇄 장애)을 직접 해결합니다.
Agent Compliance는 EU AI 법안, HIPAA, SOC2 및 OWASP Agentic Top 10 전반에 대한 컴플라이언스 등급 평가와 규제 프레임워크 매핑을 통해 거버넌스 검증을 자동화합니다.
Agent Marketplace는 Ed25519 서명, 검증, 신뢰 등급 기반 기능 제어(capability gating), 공급망 보안을 바탕으로 플러그인 라이프사이클을 관리하며, 이는 ASI04에 대한 직접적인 해답입니다.
Agent Lightning은 정책이 강제된 러너와 보상 형성(reward shaping)을 통해 강화학습(RL) 훈련을 통제하여, RL 훈련 도중 정책 위반이 전혀 발생하지 않도록 보장합니다.
차별화 요소
마이크로소프트의 접근 방식에서 두드러지는 세 가지 특징은 다음과 같습니다:
진정한 오픈소스입니다. MIT 라이선스, 9,500개 이상의 테스트, SLSA 호환 빌드 출처 증명(build provenance), OpenSSF Scorecard 추적, ClusterFuzzLite 퍼징을 갖추고 있습니다. 마이크로소프트는 이를 비영리 재단으로 이관할 계획을 가지고 있습니다. 다른 어떤 벤더도 이러한 수준의 개방성을 제공하지 않습니다.
OWASP 10개 전 항목 대응을 표방합니다. Agentic Top 10의 모든 위험에 대해 전용 완화 메커니즘을 갖추고 있습니다. 구글과 AWS는 많은 위험을 플랫폼 서비스를 통해 간접적으로 다루지만, 마이크로소프트는 각 위험에 대응하는 구체적인 패키지 컴포넌트를 명시적으로 제공합니다.
프레임워크에 구애받지 않습니다(Framework-agnostic). 이 툴킷은 LangChain의 콜백 핸들러, CrewAI의 태스크 데코레이터, Google ADK의 플러그인 시스템, Microsoft Agent Framework의 미들웨어 파이프라인에 직접 연결됩니다. 어떤 클라우드에서도 동작합니다. Dify 마켓플레이스에 등록되어 있으며, LlamaIndex, OpenAI Agents SDK, Haystack, LangGraph, PydanticAI 모두와 연동을 지원합니다.
잠재적 위험 및 한계
오픈소스라는 것은 관리형 SLA가 없다는 뜻이기도 합니다. 거버넌스 인프라를 개발팀이 직접 운영해야 합니다. 모든 트래픽을 자동으로 라우팅해주는 구글 스타일의 Agent Gateway가 없으므로, 에이전트 코드에 직접 통합해야 합니다. 전담 플랫폼 엔지니어링 조직이 없는 팀에게는 실질적인 도입 장벽이 될 수 있습니다.
Google Cloud: 에이전트를 위한 ID 우선 제로 트러스트
발표: Google Cloud Next ’26, 2026년 5월 | 플랫폼: Google Cloud 서비스
구글의 핵심 가설은 **“신원이 모든 것의 기초”**라는 점입니다. 에이전트가 누구인지—단순히 사칭하는 신원이나 임시로 빌려온 서비스 계정이 아니라, 암호학적으로 검증된 일급 신원—를 증명할 수 있다면, 권한 부여, 모니터링, 컴플라이언스는 자연스럽게 뒤따라온다는 접근입니다.
에이전트 신원(Agent Identity): 새로운 주체(Principal) 유형
Google Cloud의 AI 에이전트는 이제 인간 사용자나 범용 서비스 계정과 완전히 구별되는 일급 주체 유형인 전용 Agent Identity를 부여받을 수 있습니다. SPIFFE(Secure Production Identity Framework For Everyone) 표준을 기반으로 구축된 이 신원은 암호학적으로 보호되고, 강력하게 증명(attest)되며, 자동으로 프로비저닝됩니다.
이는 아키텍처적으로 대단히 중요합니다. 전통적인 IAM 시스템은 사람과 서비스 계정만을 위해 설계되었습니다. 사용자를 대신해 행동하다가, 자율적으로 판단하고, 다시 다른 에이전트에게 작업을 위임하는 에이전트는 기존의 두 범주 어디에도 깔끔하게 들어맞지 않습니다. 구글의 해답은 완전히 새로운 범주를 정의하는 것이었습니다.
현재 프리뷰 상태인 Agent Identity Auth Manager는 사용자를 대신해 행동하는 에이전트의 복잡한 OAuth 흐름을 간소화하고 자격 증명과 토큰을 안전하게 처리합니다. Certificate Manager 역시 이제 Agent Identity 인증서를 지원합니다.
에이전트 게이트웨이(Agent Gateway): 정책 집행의 관문
Google Cloud의 모든 에이전트 트래픽은 이제 모든 에이전트-에이전트 및 에이전트-도구 연결의 중앙 집중식 집행 지점인 Agent Gateway를 통해 라우팅될 수 있습니다. 이곳이 바로 정책 결정이 일어나는 아키텍처의 핵심 린치핀(linchpin)입니다.
**에이전트를 위한 Identity-Aware Proxy (IAP)**는 Agent Gateway와 통합되어 에이전트 신원과 Model Context Protocol(MCP)의 컨텍스트 속성을 기반으로 IAM을 사용해 세분화된 접근 제어 정책을 강제합니다. **Context-Aware Access (CAA)**는 접근 권한을 부여하기 전에 에이전트 신원의 디바이스 상태, IP 주소 및 위치를 종합적으로 평가합니다.
에이전트 접근 관리 (Agent Access Management)
구글은 기존 IAM 인프라를 확장하여 에이전트 전용 정책을 지원합니다:
- Agent Identity를 위한 IAM 허용(Allow) 및 거부(Deny) 정책 (정식 출시, GA)
- Principal Access Boundary (PAB): 상속된 권한과 무관하게 에이전트가 절대로 접근할 수 없는 리소스에 대해 하드 리밋(hard limits) 설정 (프리뷰)
- Unified Access Policy (UAP): 도구, API, 리소스에 대한 에이전트의 접근을 정밀하게 제어하며, 민감한 작업에 대해 인간 개입 승인(Human-in-the-loop, HITL)을 강제 가능 (출시 예정)
런타임 방어: Model Armor
Model Armor는 프롬프트 인젝션, 도구 오염, 민감한 데이터 유출로부터 사용자, 모델, 에이전트 간의 상호작용을 실시간으로 보호합니다. 이제 Agent Gateway, Agent Runtime, Google Cloud MCP 서버에 대해 인라인(inline) 보호를 제공합니다.
여기서 구글의 접근 방식은 마이크로소프트와 크게 갈립니다. Model Armor는 AI 모델을 활용해 공격을 탐지하는 확률론적(probabilistic) 방어 계층입니다. 반면 마이크로소프트의 Agent OS는 순수하게 결정론적(deterministic)입니다. 구글은 심층 방어(defense in depth)를 위해 결정론적 제어(IAM, PAB, VPC-SC)와 확률론적 제어(Model Armor)를 결합하여 다층 구조로 운용합니다.
Agent Security 대시보드
새롭게 프리뷰로 제공되는 기능들: 에이전트리스(agentless) 자산 탐색, 취약점 스캐닝, 런타임 위협 탐지, 그래프 기반 위험 분석. 조직 내에서 승인되지 않은 채 실행 중인 섀도우 AI 에이전트(shadow AI agents)를 탐지하는 기능도 포함됩니다.
구글의 연구 백서
구글은 “보안 AI 에이전트를 위한 구글의 접근 방식 소개(An Introduction to Google’s Approach for Secure AI Agents)“를 발표하며 세 가지 핵심 원칙을 제시했습니다:
- 에이전트는 **명확히 정의된 인간 제어자(controller)**를 가져야 한다.
- 에이전트의 권한은 신중하게 제한되어야 한다.
- 에이전트의 행동과 계획은 **관찰 가능(observable)**해야 한다.
구글은 결정론적 보안 제어와 동적 추론 기반 방어를 결합하는 하이브리드 전략을 옹호합니다. 이는 철학적으로는 마이크로소프트의 접근 방식과 일치하지만, 오픈소스 패키지가 아닌 완전 관리형 플랫폼 서비스 형태로 구현되었다는 점에서 차이가 있습니다.
잠재적 위험 및 한계
모든 기능이 오직 Google Cloud 환경에만 종속되어 있습니다. AWS나 온프레미스, 혹은 멀티 클라우드 환경에서 에이전트를 구동하고 있다면 구글의 거버넌스 솔루션은 해당 환경까지 확장되지 못합니다. 또한 마이크로소프트 툴킷에 비해 에이전트 간 신뢰 점수 산정이나 연쇄 장애 방지에 대한 공개된 상세 정보가 부족합니다.
AWS Bedrock AgentCore: LLM 외부의 결정론적 정책 방벽
발표: AWS re:Invent 2025 (2025년 12월) | 플랫폼: Amazon Bedrock
AWS는 프로덕션 에이전트 거버넌스 계층을 시장에 가장 먼저 선보였습니다. 이들의 접근 방식은 아키텍처적으로 가장 보수적이며, 동시에 감사관(auditor)에게 가장 친화적입니다.
“에이전트 박스(Agent Box)” 멘탈 모델
AWS는 문제를 단순하게 정의합니다. 에이전트를 외부 세계로부터 격리하는 것입니다. 에이전트 주변에 벽을 둘러 에이전트가 무엇에 접근할 수 있고, 무엇과 상호작용할 수 있으며, 어떤 영향을 미칠 수 있는지 명확히 정의합니다. 잘 정의된 벽이 없다면 이메일을 발송하고, DB를 조회하며, 코드를 실행하고, 금융 거래를 발생시키는 에이전트는 그 자체로 거대한 부채(liability)가 됩니다.
Cedar: 정책 언어
AgentCore Policy는 기계적 효율성과 인간 감사 용이성을 모두 만족하도록 설계된 인가(authorization) 언어인 Cedar를 사용합니다. 각 정책은 주체(principal, 누가), 액션(action, 무엇을), 리소스(resource, 어디서)를 지정하며, when 절을 통해 조건을 명시합니다:
permit(
principal == Agent::"appointment-scheduler",
action == Action::"view-patient-record",
resource in PatientRecords::"clinic-42"
) when { context.readOnly == true };Cedar의 시맨틱은 의도적으로 단순하고 지루하게 설계되었습니다. 기본 거부(default deny), 허용보다 거부 우선(forbid wins over permit), 순서에 무관한 평가(order-independent evaluation), 부작용(side effects) 없음, 루프(loops) 없음. 신뢰할 수 없는 작성자가 작성한 정책이라도 샌드박싱 없이 안전하게 평가될 수 있습니다. 프롬프트 인젝션 공격으로 에이전트가 프로덕션 데이터를 삭제하지 않기만을 기도하는 상황과 비교하면, 이것이야말로 엔지니어가 진정으로 바라는 정책 엔진입니다.
자연어를 Cedar 정책으로 변환
가장 흥미로운 기능은 비즈니스 규칙을 자연어로 서술하면 AgentCore가 이를 정형화된 Cedar 정책으로 변환해 준다는 점입니다. “이 에이전트는 프로덕션 S3 버킷의 객체를 삭제할 수 없다”는 지침이 기계가 강제할 수 있는 정책으로 바뀝니다. 규제 준수(compliance) 팀에게 이는 애플리케이션 코드를 뒤지는 것과 명확히 감사 가능한 정책 정의서를 읽는 것만큼의 큰 차이를 만들어냅니다.
AgentCore Gateway
모든 에이전트-도구 트래픽은 게이트웨이를 통과하며, 게이트웨이는 도구 호출이 실행되기 전에 모든 요청을 가로채 Cedar 정책과 대조하여 평가합니다. 이러한 집행은 완전히 결정론적입니다. 에이전트가 어떤 프롬프트를 받았든, 어떻게 조작되었든, 에이전트 코드에 어떤 버그가 있든 상관없습니다. 게이트웨이는 조건에 관계없이 정책을 강제 집행합니다.
AgentCore Evaluations
정확성, 유용성, 안전성 등을 포괄하는 13개의 사전 구축된 평가기(evaluators)가 실제 에이전트 상호작용을 대상으로 지속적으로 구동됩니다. 행동 퇴행(regression)에 대한 알림과 시간에 따른 지표 추적을 제공하여, 에이전트 감독을 수동 현장 점검에서 DevOps 라이프사이클로 전환시킵니다.
AgentCore Memory
에피소딕 메모리(Episodic memory)를 통해 에이전트는 장기간에 걸쳐 자신이 수행한 작업, 실패한 내역, 발생한 결과를 기억할 수 있습니다. 이는 에이전트를 “호출할 때만 쓰는 똑똑한 도구”에서 “프로세스를 책임지는 신뢰할 수 있는 작업자”로 탈바꿈시킵니다.
잠재적 위험 및 한계
AWS의 거버넌스 스토리는 이미 Bedrock 생태계에 안착한 팀에게 가장 강력합니다. 자체 인프라에서 LangChain으로 에이전트를 구축하고 있다면, AgentCore의 거버넌스는 해당 배포 환경으로 자동으로 확장되지 않습니다. Cedar 언어 자체는 오픈소스이지만, 이를 관리형으로 집행하는 계층은 AWS 전용입니다. OWASP 측면에서는 도구 오용(ASI02)과 신원(ASI03)에 대한 대응은 강력하지만, 메모리 오염(ASI06), 연쇄 장애(ASI08), 제어 불능 에이전트(ASI10)에 대한 대응은 상대적으로 덜 명시적입니다.
종합 비교
아키텍처
| 비교 항목 | Microsoft AGT | Google Cloud | AWS AgentCore |
|---|---|---|---|
| 메타포 | 운영체제 커널 | 제로 트러스트 네트워크 | 담장 둘러쳐진 정원 / 샌드박스 |
| 핵심 메커니즘 | 정책 엔진 (Agent OS) | Agent Identity (SPIFFE) | 정책 언어 (Cedar) |
| 배포 방식 | 자체 호스팅, 모든 클라우드 | Google Cloud 전용 | AWS 전용 |
| 오픈소스 여부 | 예 (MIT) | 아니오 | Cedar는 오픈소스, 플랫폼은 비공개 |
| 멀티 클라우드 지원 | 예 | 아니오 | 아니오 |
| 정책 언어 | YAML, OPA Rego, Cedar | IAM 정책, VPC-SC 규칙 | Cedar |
| 집행 지연 시간 | p99 <0.1ms (공개치) | 미공개 | 미공개 (최소 수준으로 설명됨) |
신원 및 신뢰
| 비교 항목 | Microsoft AGT | Google Cloud | AWS AgentCore |
|---|---|---|---|
| 신원 모델 | DID + Ed25519 | SPIFFE 기반 Agent Identity | IAM 역할 + Cedar 주체 |
| 신뢰 점수 산정 | 0~1000 척도, 5개 등급, 행동 기반 감쇠 | CAA 컨텍스트 신호 | 미공개 |
| 에이전트 간 신뢰 | IATP 프로토콜 | Agent Gateway + IAP | AgentCore Gateway |
| 자격 증명 수명주기 | 작업당 단기 발급 | Agent Identity Auth Manager | 작업당 단기 발급 |
OWASP Agentic Top 10 대응 범위
| OWASP 위험 | Microsoft AGT | Google Cloud | AWS AgentCore |
|---|---|---|---|
| ASI01: 목표 하이재킹 | 직접 대응 — 시맨틱 의도 분류기 | 부분 대응 — Model Armor PI 탐지 | 부분 대응 — Guardrails PI 탐지 |
| ASI02: 도구 오용 | 직접 대응 — 기능 샌드박싱 + MCP 게이트웨이 | 부분 대응 — IAP + 접근 정책 | 직접 대응 — 게이트웨이 Cedar 집행 |
| ASI03: 신원 남용 | 직접 대응 — DID + 신뢰 점수 산정 | 직접 대응 — Agent Identity + PAB + UAP | 부분 대응 — IAM + Cedar 주체 |
| ASI04: 공급망 위험 | 직접 대응 — Ed25519 플러그인 서명 | 부분 대응 — 취약점 스캐닝 | 직접 대응 없음 |
| ASI05: 코드 실행 | 직접 대응 — 실행 링 | 부분 대응 — VPC-SC 경계 제어 | 부분 대응 — 에이전트 박스 개념 |
| ASI06: 메모리 오염 | 직접 대응 — CMVK 다수결 투표 | 직접 대응 없음 | 직접 대응 없음 |
| ASI07: 안전하지 않은 통신 | 직접 대응 — IATP 암호화 | 부분 대응 — Agent Gateway 라우팅 | 부분 대응 — Gateway (암호화) |
| ASI08: 연쇄 장애 | 직접 대응 — 서킷 브레이커 + SLO | 직접 대응 없음 | 직접 대응 없음 |
| ASI09: 인간-에이전트 신뢰 | 직접 대응 — 정족수 승인 워크플로우 | 부분 대응 — UAP HITL 의무화 (예정) | 직접 대응 없음 |
| ASI10: 제어 불능 에이전트 | 직접 대응 — 링 격리 + 킬 스위치 | 부분 대응 — Agent Security 대시보드 | 직접 대응 없음 |
마이크로소프트는 10개 전 항목 직접 대응을 표방합니다. 구글과 AWS는 34개 위험을 직접 해결하고 플랫폼 서비스를 통해 또 다른 34개를 간접 해결합니다. 메모리 오염, 연쇄 장애, 인간-에이전트 신뢰, 제어 불능 에이전트와 같은 나머지 격차는 업계에서 가장 난이도가 높은 과제이며, 아직 그 누구도 완벽히 정복하지 못했습니다.
기술의 수렴: 세 기업 모두 동의하는 핵심 원칙
아키텍처의 차이에도 불구하고, 세 플랫폼 모두 동일한 핵심 원칙으로 수렴하고 있습니다:
1. LLM 외부에서의 결정론적 정책 집행. 세 기업 모두 모델 스스로가 자신의 가드레일을 강제 집행할 수 있다고 신뢰하지 않습니다. 정책 평가는 모델의 추론이 아니라 인프라 엔진에 의해 수행됩니다. 이는 프로덕션 배포에서 타협할 수 없는 기본 전제입니다.
2. 에이전트 신원의 일급 객체화. 에이전트가 인간의 자격 증명이나 범용 서비스 계정을 임시로 차용하던 시대는 끝났습니다. DID(마이크로소프트), SPIFFE(구글), IAM 주체(AWS) 등 어떤 형태이든 에이전트는 자체적인 권한 경계를 갖춘 독립적인 신원을 가져야 합니다.
3. 게이트웨이 아키텍처. 세 곳 모두 에이전트 트래픽을 Agent OS, Agent Gateway, AgentCore Gateway와 같은 단일 집행 관문으로 라우팅합니다. 정책 결정은 작업이 실행된 후가 아니라, 실행되기 전에 이루어집니다.
4. 최소 에이전시(Least Agency). OWASP가 주창한 개념이 전면 채택되었습니다. 에이전트에게 필요한 최소한의 권한만 부여해야 합니다. 파급력이 큰 작업에는 인간 승인을 요구하고, 굳이 자율성이 필요하지 않은 곳에는 에이전트 동작을 배포하지 말아야 합니다.
5. 관찰 가능성(Observability)은 기본 전제 조건. 볼 수 없는 것은 통제할 수 없습니다. 세 플랫폼 모두 에이전트 행동에 대한 로깅, 모니터링, 알림 기능을 기본으로 제공합니다.
아직 아무도 완전히 해결하지 못한 사각지대
아무리 정교한 툴킷이라 하더라도 아직 풀리지 않은 난제들이 남아 있습니다:
**메모리 오염(ASI06)**은 이제 막 연구가 시작된 분야입니다. 마이크로소프트의 다수결 투표 기반 교차 모델 검증 커널(Cross-Model Verification Kernel, CMVK)은 참신하지만 대규모 환경에서 검증되지 않았습니다. 구글과 AWS는 이 문제를 직접적으로 다루지 않습니다.
멀티 에이전트 시스템에서 **연쇄 장애 방지(ASI08)**는 아직 상당 부분 이론의 영역에 머물러 있습니다. 마이크로소프트의 서킷 브레이커와 SLO는 마이크로서비스 기법을 차용했지만, 에이전트 시스템은 근본적으로 다른 실패 양상을 보입니다. 환각을 일으키는 에이전트는 500 에러를 반환하는 웹 서비스와는 전혀 다릅니다.
**인간-에이전트 신뢰 악용(ASI09)**은 가장 다루기 힘든 난제입니다. 이는 AI를 매개로 한 사회공학적 공격입니다. 사용자가 에이전트의 출력을 맹신해서는 안 되는 상황에서 에이전트를 무비판적으로 신뢰하는 문제를 온전히 해결할 수 있는 정책 엔진은 존재하지 않습니다.
**제어 불능 에이전트 탐지(ASI10)**는 정교한 행동 모니터링을 요구합니다. 마이크로소프트의 감쇠형 신뢰 점수 산정이 가장 발전된 접근이지만, 정상적인 변동성으로 인한 오탐(false positive)을 발생시키지 않으면서 의도된 행동에서 미세하게 벗어나는 에이전트를 탐지하는 것은 여전히 열려 있는 연구 과제입니다.
의사결정 프레임워크
| 상황 / 요구사항 | 추천 플랫폼 | 선택 이유 |
|---|---|---|
| 멀티 클라우드 또는 벤더 중립적 거버넌스가 필요한 경우 | Microsoft AGT | 오픈소스, 프레임워크 무관, 모든 환경에서 구동 |
| Google Cloud를 전사 표준으로 사용하는 경우 | Google Cloud Agent Security | 심층 통합, 강력한 신원 기반, 완전 관리형 서비스 |
| AWS를 전사 표준으로 사용하는 경우 | Bedrock AgentCore | Cedar 정책, 완전 관리형 서비스, 감사 친화적 |
| 현시점에서 가장 폭넓은 OWASP 대응이 필요한 경우 | Microsoft AGT | 전용 메커니즘을 통해 10개 전 항목 대응을 표방하는 유일한 툴킷 |
| 가장 빠른 프로덕션 전환 경로가 필요한 경우 | AWS AgentCore | 2025년 12월부터 정식 출시(GA), 관리형 서비스로 운영 부담 최소화 |
| 오픈 표준에 기여하고 생태계를 주도하려는 경우 | Microsoft AGT + OWASP | MIT 라이선스, 재단 이관 추진, OWASP와의 긴밀한 협업 |
| 강력한 플랫폼 엔지니어링 역량을 보유한 조직 | Microsoft AGT | 자체 운영 필요하나 최고의 유연성과 대응 범위 제공 |
| 플랫폼 엔지니어링 역량이 제한적인 조직 | AWS 또는 Google 관리형 서비스 | 유연성은 다소 낮으나 인프라 운영 부담 대폭 경감 |
이번 주에 착수해야 할 작업
프로덕션 환경에 에이전트를 배포하고 있다면: 조직에서 가장 우선순위가 높은 OWASP 위험 항목을 정리하십시오. 해당 위험을 직접 해결하는 플랫폼을 선택해야 합니다. 결정론적 정책 집행을 요구하십시오. 규제 준수 환경에서는 확률론적 가드레일만으로는 불충분합니다.
규제 대상 산업에 속해 있다면: OWASP Agentic Top 10을 기본 위협 모델로 삼으십시오. 선택한 플랫폼이 각 위험을 어떻게 완화하는지 문서화해야 합니다. EU AI 법안 준수 기한은 2026년 8월로, 불과 7주밖에 남지 않았습니다.
플랫폼을 평가 중이라면: 마이크로소프트 툴킷을 설치해 보고(pip install agent-governance-toolkit[full]), AWS에서 AgentCore Gateway를 구성해 보며, Google Cloud에서 Agent Identity를 활성화하십시오. 플랫폼 간의 차이를 이해하는 가장 빠른 방법은 실제 조직의 에이전트 워크로드를 각 환경에 올려 직접 테스트해보는 것입니다.
“프롬프트를 믿는다”는 방식이 거버넌스 전략이 되던 시대는 끝났습니다. 자율 에이전트 주변에 실질적인 보안 경계를 세울 수 있는 인프라가 이제 모두 갖추어졌습니다. 이제 질문은 도입 여부가 아니라, 귀사의 아키텍처에 어떤 철학이 부합하는가입니다.
연구 노트 및 OWASP Top 10 전체 분석은 옵시디언(Obsidian) 볼트에 저장되어 있습니다. 출처: Microsoft Open Source Blog (2026년 4월), Google Cloud Blog (2026년 5월), AWS ML Blog (2026년 3월), OWASP GenAI Security Project (2025년 12월), Google Research (2025).