에이전틱 AI (Agentic AI) 애플리케이션 — 직접적인 사용자 지시보다는 모델의 추론을 바탕으로 외부 도구, 서비스 및 API에 대해 자율적인 행동을 취하는 LLM 기반 시스템 — 은 연구 단계의 호기심을 넘어 매우 빠르게 프로덕션 배포 단계로 넘어왔으며, 이로 인해 보안 분야가 이를 따라잡기 위해 노력 중입니다. 이러한 실패 유형은 비에이전틱 (non-agentic) LLM 애플리케이션과는 운영 측면에서 구별됩니다. 2026년 초에 발표된 OWASP Agentic AI Top 10은 업계가 수렴해 온 리스크 분류 체계(risk taxonomy)를 공식화합니다. AWS Agentic AI Security Scoping Matrix (2025년 11월)는 에이전트 역량 경계를 생각하기 위한 가장 널리 인용되는 운영 프레임워크를 제공합니다. 브라우저 사용 에이전트 보안에 대해 Anthropic이 발표한 연구는 브라우저 제어 에이전트에서의 간접 프롬프트 주입 (indirect prompt injection)에 대한 구체적인 방어책을 다룹니다. 이 포스트에서는 에이전틱 특화 리스크 환경, 프로덕션에서 작동하는 방어 패턴, 그리고 에이전틱 보안 작업이 OWASP LLM Top 10 2025 field guide에서 다루는 광범위한 LLM 애플리케이션 보안 검증 내에서 어떻게 자리 잡는지 살펴봅니다.

무엇이 에이전틱 AI를 "일반적인" LLM 애플리케이션과 다르게 만드는가

비에이전틱 (non-agentic) LLM 애플리케이션은 사용자 입력을 받아 모델 출력을 생성하고, 그 출력을 사용자에게 반환합니다. 보안 경계가 잘 정의되어 있습니다: 사용자는 모델의 응답을 보고 그것을 어떻게 처리할지 결정합니다. 에이전틱 AI 애플리케이션은 사용자 입력을 받거나 (또는 점점 더 흔해지는 사례로, 직접적인 사용자 입력 없이 scheduled 또는 event-triggered 목표에 따라 에이전트가 실행됨), 일련의 모델 출력을 생성하며, 외부 시스템에 영향을 미치는 도구(tools)를 호출함으로써 각 출력에 대해 행동합니다. 보안 경계는 근본적으로 다릅니다: 모델의 출력은 단순히 사용자에게 제시되는 것이 아니라, 시스템 동작으로서 실행(operationalized)됩니다.

이러한 차이로 인한 결과는, 비-에이전틱 (non-agentic) LLM 애플리케이션에서 작동했던 모든 방어 패턴이 여전히 적용되지만, 우회(bypass) 비용이 근본적으로 더 높아진다는 것입니다. 비-에이전틱 챗봇에서의 프롬프트 인젝션 (prompt injection)은 모델이 유해한 발언을 하게 만들 수 있지만, 에이전틱 시스템에서의 프롬프트 인젝션은 모델이 데이터를 유출하거나, 레코드를 수정하거나, 메시지를 보내거나, 코드를 실행하거나, 또는 에이전트의 도구(tool)가 허용하는 기타 모든 동작을 수행하도록 만들 수 있습니다. 이에 따라 방어 표면 (defensive surface area)이 확장됩니다. 애플리케이션은 모델의 추론뿐만 아니라, 에이전트가 호출할 수 있는 모든 도구와 그 도구가 수행할 수 있는 모든 동작을 방어해야 합니다.

두 번째 차수 결과 (second-order consequence)는 에이전틱 시스템이 인간의 검토가 따라갈 수 없는 속도로 작동한다는 점입니다. 비-에이전틱 챗봇의 출력은 이를 읽는 사용자에 의해 암묵적으로 검토되지만, 에이전틱 시스템의 동작은 개별 결정에 대해 인간이 개입(human in the loop)하지 않은 상태에서 분당 수십 번의 도구 호출을 완료할 수 있습니다. 이러한 속도로 인해 방어 아키텍처는 에이전틱 속도에서 확장성을 갖지 못하는 인간 검토 기반 중재 (human-review-based mediation) 대신, 모든 도구 호출이 허용 여부를 결정하는 정책에 따라 확인되는 정책 기반 중재 (policy-based mediation)를 지향하게 됩니다.

OWASP Agentic AI Top 10

OWASP GenAI Security Project를 통해 발표된 OWASP Agentic AI Top 10은 에이전틱 AI 배포 시 가장 중대한 영향을 미치는 10가지 리스크 카테고리를 식별합니다. 이 카테고리들은 여러 카테고리가 주제적 중첩을 공유함에도 불구하고, LLM Top 10과는 운영 측면에서 구별되도록 의도적으로 구조화되었습니다. 2026년 초 기준 목록은 다음과 같습니다:

AAI01 — 도구 오용 (Tool Misuse). 에이전트가 애플리케이션 소유자가 의도하지 않은 방식으로 도구를 호출하는 경우입니다. 예상 범위를 벗어난 인자(arguments)를 사용하여 도구를 사용하거나, 의도하지 않은 결과를 초래하는 순서로 도구를 호출하거나, 여러 도구 호출을 체이닝 (chaining)하여 개별 도구의 안전 점검을 우회하는 복합 동작을 수행하는 경우가 이에 해당합니다.

AAI02 — 승인되지 않은 동작 (Unauthorized Actions). 에이전트가 사용자가 승인하지 않은 동작을 수행하는 경우입니다. 이는 대개 에이전트의 추론 과정에서 사용자가 명시적으로 요청하지 않았음에도 불구하고, 해당 동작이 사용자의 목표에 포함되어 있다고 판단할 때 발생합니다. 실제 운영 환경에서 가장 흔히 나타나는 사례는 사용자가 단순히 '중복 제거'만을 의도했음에도, 에이전트가 '데이터베이스 정리'라는 명령으로부터 '오래된 레코드 삭제'를 추론해내는 경우입니다.

AAI03 — 목표 조작 (Goal Manipulation). 공격자가 목표 설정 단계에서 프롬프트 인젝션 (Prompt Injection)을 통해 에이전트가 인식하는 목표를 조작하는 것입니다. 가장 흔한 공격 경로는 에이전트가 자신의 목표를 수행하기 위해 처리 중인 콘텐츠를 통한 간접 인젝션 (Indirect Injection)입니다. 예를 들어, 이메일을 요약하는 에이전트가 이메일 내용에 포함된 프롬프트 인젝션에 의해 요약 범위를 넘어선 목표를 수행하도록 유도되는 경우가 이에 해당합니다.

AAI04 — 자원 고갈 (Resource Exhaustion). 에이전트가 루프 (Loop)에 빠지거나 목표 범위를 확장하여 컴퓨팅 자원, API 할당량 (Quota), 재정적 예산 등 불균형적으로 많은 자원을 소비하는 현상입니다. 이 범주에는 의도치 않은 경우(에이전트의 추론이 목표 확장 루프를 생성하는 경우)와 적대적인 경우(공격자가 에이전트를 자원 고갈 경로로 유도하는 경우)가 모두 포함됩니다.

AAI05 — 멀티 에이전트 권한 상승 (Multi-Agent Privilege Escalation). 여러 에이전트가 협업하는 시스템에서, 하나의 에이전트가 조작되어 더 높은 권한을 가진 다른 에이전트를 대신하여 행동함으로써 의도된 권한 경계 (Privilege Boundary)를 우회하는 경우입니다. 이 범주는 에이전틱 시스템 (Agentic Systems)에서 새롭게 등장한 유형으로, 비-에이전틱 (Non-agentic) 환경에서는 직접적인 유사 사례가 없습니다.

AAI06 — 신원 혼동 (Identity Confusion). 에이전트가 원래 사용자와 일치하지 않는 자격 증명 (Credentials), 범위 (Scopes) 또는 신원 주장 (Identity Assertions) 하에서 동작하는 경우입니다. 이는 설정 오류(에이전트가 현재 작업에 필요한 범위를 넘어선 자격 증명에 접근할 수 있는 경우) 또는 조작(에이전트가 의도와 다른 신원으로 동작하도록 유도되는 경우)을 통해 발생합니다.

AAI07 — 지속적 메모리 조작 (Persistent Memory Manipulation). 상호작용 전반에 걸쳐 메모리를 유지하는 에이전트는 공격자가 제어하는 정보를 저장하도록 조작될 수 있으며, 이는 향후 에이전트의 행동에 영향을 미칩니다. 이 범주에는 사실 조작 (에이전트가 나중에 사실(ground truth)로 취급할 거짓 정보를 저장하는 것)과 행동 조작 (에이전트가 향후 상호작용에서 선호 사항으로 취급할 지침을 저장하는 것)이 모두 포함됩니다.

AAI08 — 에이전트 간 신뢰 악용 (Inter-Agent Trust Exploitation). 멀티 에이전트 시스템 (Multi-agent systems)은 종종 에이전트 간에 신뢰 관계를 구축합니다. 즉, 에이전트 A가 에이전트 B의 출력을 독립적인 검증 없이 입력값으로 신뢰하는 경우입니다. 에이전트 B를 침해할 수 있는 공격자는 해당 신뢰 관계를 이용하여 에이전트 A에 영향을 미칠 수 있습니다. 이에 대한 방어책은 에이전트 간 통신을 사용자 입력과 동일한 검증이 필요한 신뢰할 수 없는 입력 (untrusted input)으로 취급하는 것입니다.

AAI09 — 불충분한 관찰 가능성 (Insufficient Observability). 에이전트의 추론 (reasoning), 도구 호출 (tool invocations), 그리고 결정 지점들이 적절하게 로그로 기록되거나 모니터링되지 않아, 사고 발생 후의 포렌식 분석 (forensic analysis)과 선제적인 이상 탐지 (anomaly detection)가 모두 불가능해지는 상황입니다. 이 카테고리는 메타 (meta)적 성격을 띱니다. 즉, 공격 자체를 설명하는 것이 아니라, 나머지 9가지 위협에 대응하는 데 필요한 운영 가시성 (operational visibility)의 부재를 설명합니다.

AAI10 — 연쇄적 실패 (Cascading Failures). 하나의 에이전트 또는 도구 호출에서의 오류나 실패가 에이전트의 추론을 통해 더 심각한 오류 상태로 전파되어, 궁극적으로 원래의 실패가 암시하는 것보다 훨씬 더 나쁜 결과를 초래합니다. 이 범주는 특히 도구 호출 계층 (tool-invocation layer)에서 오류 처리 (error handling)가 취약하여, 예외 (exceptions)가 애플리케이션 로직에 의해 중재되지 않고 에이전트의 추론 단계로 그대로 노출되는 시스템에서 두드러지게 나타납니다.

AWS 에이전틱 AI 보안 범위 매트릭스 (2025년 11월 21일)

2025년 11월 21일 출시된 AWS 에이전틱 AI 보안 범위 매트릭스(AWS agentic ai security scoping matrix) — AWS가 생성형 AI (Generative AI) 보안 가이드라인 개편의 일환으로 발표한 이 매트릭스는 — 에이전트의 역량 경계(capability boundaries)를 고찰하기 위한 가장 많이 참조되는 운영 프레임워크가 되었습니다. 이 매트릭스는 에이전트의 역량을 두 가지 축을 따라 구조화합니다. 하나는 에이전트가 영향을 미칠 수 있는 리소스의 범위(단일 레코드, 다중 레코드, 전체 데이터셋, 다중 데이터셋, 조직 전체)이며, 다른 하나는 에이전트가 취할 수 있는 작업의 가역성(즉시 가역적, 수 시간 내 가역적, 백업을 통한 복구 가능, 복구 불가능)입니다. 이 두 축의 교차점은 특정 에이전틱 배포(agentic deployment)에 대한 리스크 프로필(risk profile)을 생성하며, 방어 통제(defensive controls)는 해당 프로필에 따라 규모가 결정됩니다.

2025년 11월 21일이라는 발행 날짜는 중요한 의미를 갖습니다. 왜냐하면 AWS 가이드라인은 해당 분야가 비공식적으로 수렴해 오던 '범위 대 가역성(scope-vs-reversibility)' 리스크 프로필 모델을 공식화한 최초의 주요 클라우드 제공업체 운영 프레임워크였기 때문입니다. 이 문서는 AWS 보안 문서 사이트에서 자유롭게 이용할 수 있으며, 벤더가 에이전틱 AI 배포를 어떻게 구조화하는지 묻는 조달 보안 설문지(procurement security questionnaires)에서 점점 더 많이 참조되고 있습니다.

이 매트릭스를 실무적으로 해석하면, 가장 방어하기 쉬운 에이전틱 배포는 왼쪽 하단 사분면, 즉 좁은 리소스 범위와 즉시 가역적인 작업이 이루어지는 영역에 위치합니다. 사용자 소유의 레코드를 읽을 수 있지만 오직 요청한 사용자의 레코드만 읽을 수 있고, 변경 사항을 직접 적용하는 대신 인간의 승인을 위해 제안만 할 수 있는 에이전트는 침해(compromise) 발생 시의 결과가 두 축 모두에 의해 제한되므로 적절한 수준의 방어만 필요합니다. 반면, 조직 전체의 레코드에 영향을 미치고 복구 불가능한 작업을 수행할 수 있는 에이전트는 침해의 결과가 제한되지 않으므로 모든 아키텍처 계층에 걸친 심층 방어(defense-in-depth)가 필요합니다.

이 매트릭스의 운영 목적은 프로덕션 배포 시 에이전트 설계를 기본적으로 좌측 하단 사분면으로 유도하는 것이며, 더 높은 리스크를 가진 사분면으로 이동할 경우 반드시 의도적인 정당화가 필요하도록 하는 것입니다. "더 많은 레코드를 수정할 수 있다면 더 유용할 것이다"라고 생각하는 에이전트는 명시적인 리스크 수용(risk acceptance)이 필요한 설계 선택이지, 암묵적인 기본값이 되어서는 안 됩니다. 가역성(reversibility)에 대해서도 마찬가지입니다. "변경 사항을 직접 적용할 수 있다면 더 빠를 것이다"라고 생각하는 에이전트는 성능을 위해 가역성을 희생하기로 선택한 것이며, 그러한 트레이드오프(tradeoff)는 보안 검토 과정에서 명확히 드러나야 합니다.

프로덕션 환경에서 작동하는 방어 패턴 (Defensive Patterns)

에이전틱 AI를 위한 방어 패턴은 6가지 범주로 나뉩니다. 각 패턴은 Agentic Top 10의 특정 리스크 클래스를 다루며, 이들이 결합되면 전체 자격 증명 침해(credential compromise) 수준의 공격을 제외한 대부분의 공격 시나리오를 견뎌낼 수 있는 심층 방어(defense-in-depth)를 형성합니다.

범위 제한 (Scope limitation). 에이전트는 의도된 기능을 수행하는 데 정확히 필요한 도구에만 접근할 수 있어야 하며, 공격자가 유해한 동작으로 체이닝(chaining)할 수 있는 "범용(general-purpose)" 도구가 있어서는 안 됩니다. 코드 리뷰 에이전트에게는 "셸 명령 실행(execute shell command)" 도구가 필요하지 않으며, 이메일 요약 에이전트에게는 "이메일 전송(send email)" 도구가 필요하지 않습니다. 도구를 추가할 때는 새로운 기능에 대한 명시적인 정당화와 위협 모델링(threat modeling)이 수반되어야 합니다.

액션 중재 (Action mediation). 모든 도구 호출(tool invocation)은 호출 허용 여부를 결정하는 정책 계층(policy layer)을 통과해야 합니다. 정책은 규칙 기반(rule-based, 예: 특정 인자를 가진 이 도구는 허용됨), 리스크 기반(risk-based, 예: 영향력이 큰 호출은 추가 검증 필요), 또는 컨텍스트 기반(context-based, 예: 에이전트의 현재 목표가 도구의 목적과 일치할 때만 호출 허용)일 수 있습니다. 현대적인 에이전트 프레임워크(LangChain의 도구 정책 시스템, AWS Bedrock Agents의 액션 가드레일 등)는 이러한 중재 계층을 설정(configuration) 형태로 제공하지만, 오래된 에이전트 구현 방식은 도구 호출을 명시적으로 래핑(wrapping)해야 합니다.

고영향 작업에 대한 대역 외 확인 (Out-of-band confirmation for high-impact actions). 기록 삭제, 외부 메시지 전송, 설정 변경, 운영 환경에서의 코드 실행과 같이 중대한 결과가 따르는 작업은 에이전트가 조작할 수 없는 채널(원래 사용자에게 보내는 이메일 확인, 인간의 승인이 필요한 Slack 메시지, 다요소 재인증 (multi-factor re-authentication))을 통해 명시적인 확인을 거쳐야 합니다. 에이전트는 스스로 확인을 승인(self-authorize)할 수 없습니다. 이 패턴은 지연 시간(latency)을 추가하지만, 에이전트 측의 침해(compromise)에 대응하는 가장 효과적인 단일 방어책입니다.

사용자별 신원 전파 (Per-user identity propagation). 에이전트가 사용자를 대신하여 행동할 때, 에이전트는 공유 서비스 신원(shared service identity)이 아닌 해당 사용자의 신원 범위(identity scope) 하에서 행동합니다. 에이전트의 도구 호출(tool invocations)은 사용자가 직접 행동할 때 직면하게 될 것과 동일한 액세스 제어(access controls)를 따릅니다. 이 패턴은 에이전트가 원래 사용자에게 이미 부여된 권한 이상의 권한을 가질 수 없으므로, 권한 상승 (privilege escalation) 및 신원 혼동 (identity confusion) 공격의 범주 전체를 제거합니다.

포괄적인 관측성 (Comprehensive observability). 에이전트가 수행하는 모든 추론 단계, 도구 호출, 그리고 결정은 포렌식 재구성 (forensic reconstruction)을 위한 충분한 컨텍스트와 함께 로그로 기록됩니다. 로그에는 에이전트가 처리 중이던 입력값, 에이전트가 생성한 추론, 호출하기로 선택한 도구, 구성한 인자(arguments), 수신한 결과, 그리고 수행한 다음 단계가 모두 캡처됩니다. OWASP 목록에서 AAI09로 명시적으로 언급된 이러한 관측성이 없다면, 에이전트 침해에 대한 방어는 분석적(analytical)이기보다는 경험적(empirical)인 수준에 머물게 됩니다.