AI 에이전트 보안의 필요성
AI 에이전트는 최근 빠르게 발전하면서 인간의 업무를 자동화하고 효율성을 높이는 데 큰 역할을 하고 있습니다. 예를 들어, 이메일을 대신 관리해주는 “Email-Bot”과 같은 에이전트는 받은 편지함을 분석하고, 요약을 제공하며, 사용자를 대신해 답장을 작성할 수도 있습니다. 하지만 이러한 편리함 뒤에는 새로운 형태의 보안 위협이 존재합니다. 특히, 프롬프트 인젝션(Prompt Injection)은 대규모 언어 모델(LLM)의 구조적 약점을 악용할 수 있는 대표적인 공격 방식으로 꼽힙니다.
프롬프트 인젝션이란 신뢰할 수 없는 문자열이나 데이터를 AI의 입력 컨텍스트에 삽입하여, 개발자가 설정한 지침을 무시하게 하거나 비인가 작업을 수행하게 만드는 공격입니다. 예를 들어, 공격자가 악성 명령을 포함한 이메일을 보내면, 이를 처리하는 AI 에이전트가 해킹당할 수 있습니다. 이로 인해 이메일 내용 유출, 피싱 메일 발송, 사용자 데이터 탈취 등의 문제가 발생할 수 있습니다.
Meta는 이러한 보안 문제를 해결하기 위해 "Agents Rule of Two"라는 새로운 프레임워크를 제시했습니다. "Agents Rule of Two" 접근법은 AI 에이전트가 사용자에게 유용하면서도 안전하게 동작할 수 있도록, 위험 요소를 체계적으로 줄이는 실질적인 보안 가이드라인을 제공합니다.
Chromium Rule of 2와 Simon Willison의 ‘Lethal Trifecta’
Meta의 ‘Agents Rule of Two’는 사실 완전히 새로운 개념은 아닙니다. 이 아이디어(와 이름에 대한 아이디어까지)는 Chromium 프로젝트의 보안 정책인 Rule of 2 와, Django의 창시자 Simon Willison이 제시한 Lethal Trifecta(치명적 삼중 구조)에서 영감을 받았습니다.
Chromium의 Rule of 2는 구글이 크로미움(Chromium) 웹 브라우저 개발 과정에서 제정한 핵심 보안 원칙으로, '취약점이 발생하더라도 피해가 제한되도록 시스템을 설계하라'는 철학을 담고 있습니다. 이 규칙은 (1) 코드 실행 권한, (2) 민감한 데이터 접근, 그리고 (3) 외부와의 통신 같은 위험 요소 중 세 가지를 동시에 허용하지 말라는 것입니다. 예를 들어, 신뢰할 수 없는 입력을 처리하는 코드가 동시에 네트워크 접근과 파일 시스템 접근 권한을 가져서는 안 됩니다. 이렇게 두 가지 이하의 위험 요소만 허용함으로써, 설령 공격자가 하나의 취약점을 악용하더라도 시스템 전체가 손상되는 것을 막을 수 있습니다. 이는 브라우저 보안뿐 아니라 현대 소프트웨어 아키텍처 전반에서 '권한 최소화의 원칙(Principle of Least Privilege)'을 실천한 대표적인 사례로 평가받고 있습니다.
Simon Willison의 Lethal Trifecta(치명적 삼중 구조) 는 대규모 언어 모델(LLM)을 활용한 AI 시스템의 근본적인 보안 위험을 지적하는 개념입니다. Willison은 LLM 기반 에이전트가 동시에 세 가지 특성을 가지면 매우 위험하다고 경고합니다. 이 때의 세 가지 특성은 (1) 신뢰할 수 없는 데이터를 처리하는 능력, (2) 민감하거나 개인적인 정보에 접근할 수 있는 권한, (3) 외부 시스템과 상호작용할 수 있는 실행 권한입니다. 이 세 요소가 모두 활성화된 상태에서는 프롬프트 인젝션이나 데이터 조작을 통해 AI가 악의적인 행동을 수행할 가능성이 커집니다. 따라서 LLM을 사용하는 개발자는 이 세 가지 요소가 동시에 충족되지 않도록 시스템을 설계해야 하며, 필요한 경우 반드시 인간의 검증 단계를 포함해야 한다는 것이 그의 핵심 주장입니다.
Meta는 이 두 개념을 통합하여, LLM 기반 AI 에이전트의 보안 리스크를 현실적으로 완화할 수 있는 프레임워크로 발전시켰습니다.
Agents Rule of Two의 핵심 원칙
Meta가 제안한 'Agents Rule of Two'는 간단하지만 매우 강력한 원칙을 제시합니다. 즉, AI 에이전트는 한 세션 내에서 아래 세 가지 속성 중 세 가지 모두를 동시에 만족해서는 안 된다는 것입니다. 이 때의 3가지 속성은 다음과 같습니다:
-
[A] 신뢰할 수 없는 입력(untrusted input)을 처리할 수 있다.
An agent can process untrustworthy inputs
-
[B] 민감한 시스템 또는 개인 데이터(sensitive systems or private data)에 접근할 수 있다.
An agent can have access to sensitive systems or private data
-
[C] 외부와 통신하거나 상태(state)를 변경할 수 있다.
An agent can change state or communicate externally
즉, 에이전트는 위의 조건 중 최대 두 가지까지만 허용되어야 합니다. 이 규칙을 지킴으로써, 프롬프트 인젝션으로 인한 피해를 구조적으로 제한할 수 있습니다.
예를 들어, 이메일 요약 기능만 수행하는 단순한 에이전트는 [A]와 [B]를 동시에 만족([AB])할 수 있습니다. 하지만 이 에이전트가 이메일을 대신 보내는 권한([C])까지 가진다면, 공격자가 프롬프트 인젝션을 통해 사용자의 이름으로 스팸 메일을 보내는 일이 가능해집니다. 따라서 이러한 조합은 허용되지 않습니다.
만약 특정 작업을 수행하기 위해 세 가지 속성 모두가 필요한 경우(예: 자동 응답 및 데이터 업데이트 등)에는 'HITL(Human-In-The-Loop)', 사람의 승인 절차를 반드시 거쳐야 합니다. 이러한 과정을 통해 완전한 자율 작동을 제한하면서, 잠재적 보안 사고를 예방할 수 있습니다.
Agents Rule of Two의 적용 사례
아래에서는 세 가지 가상의 AI 에이전트 예시를 통해 'Agents Rule of Two'를 실제로 어떻게 적용할 수 있는지를 살펴보겠습니다.
A&B 적용 사례, 여행 보조 에이전트 (Travel Agent Assistant)
여행 보조 에이전트(Travel Agent Assistant)는 사용자 대신 여행 계획을 세워주고, 항공권이나 숙소를 예약하는 등, 대외적으로 활동하는 여행 비서형 에이전트입니다. 여행 관련 최신 정보를 얻기 위해 웹을 검색해야 하므로 신뢰할 수 없는 입력(A) 을 처리해야 하며, 예약을 위해 사용자의 개인 정보나 결제 정보를 활용하므로 민감한 데이터 접근(B) 도 필요합니다.
이 경우, Agents Rule of Two에 따라 [C] (외부와의 직접 통신 및 상태 변경) 은 제한되어야 합니다. 이를 위해 다음과 같은 통제가 적용돼야 합니다:
-
예약 또는 결제 같은 중요한 행동은 항상 인간의 확인(Human confirmation) 을 거쳐야 합니다.
-
웹 요청 시, 에이전트가 임의로 URL을 생성하는 대신 검증된 신뢰 가능한 출처(whitelisted sources)만 탐색 가능하도록 제한합니다.
즉, 에이전트가 자동으로 행동하지 않도록 하여, 공격자가 악의적인 링크나 명령을 주입하더라도 피해가 최소화됩니다.
A&C 적용 사례, 웹 탐색 리서치 에이전트 (Web Browsing Research Assistant)
웹 탐색 리서치 에이전트(Web Browsing Research Assistant)는 사용자를 대신해 웹을 탐색하고 정보를 수집하는 리서치 자동화형 AI 에이전트입니다. 검색 결과를 기반으로 계획을 조정해야 하므로 신뢰할 수 없는 입력(A) 을 처리하고, 웹 브라우저를 조작하며 폼을 제출하거나 데이터를 송신하므로 외부 통신(C) 기능도 필요합니다.
하지만 이 에이전트는 민감한 데이터 접근(B) 을 금지해야 합니다. 이를 위해 다음과 같은 통제 방식이 필요합니다:
-
에이전트가 작동하는 브라우저 환경은 격리된 샌드박스(sandbox) 내에서 실행되며, 세션 쿠키나 로그인 정보가 미리 포함되지 않도록 합니다.
-
개인 정보나 사내 데이터에 접근하지 못하도록 제한하고, 사용자가 자신의 데이터가 어떻게 사용되는지를 명확히 알 수 있도록 투명성을 제공해야 합니다.
이렇게 하면 외부 웹의 비신뢰성은 허용하면서도, 내부 데이터가 유출될 위험은 최소화할 수 있습니다.
B&C 적용 사례, 내부 개발용 코딩 에이전트 (High-Velocity Internal Coder)
내부 개발용 코딩 에이전트(High-Velocity Internal Coder)는 조직 내 개발 인프라에서 코드를 작성하고 실행하여 엔지니어링 문제를 해결하는 고속 자동화형 에이전트입니다. 업무의 특성상 일부 프로덕션 시스템에 접근해야 하므로 민감한 데이터 접근(B) 이 필요하고, 코드를 실행하거나 저장소를 업데이트하므로 상태 변경(C) 도 필수적입니다.
이 경우, 신뢰할 수 없는 입력(A) 을 원천적으로 차단하는 것이 중요합니다. 이를 위해서는 다음과 같은 보안 대책이 필요합니다:
-
에이전트가 처리하는 모든 데이터 소스는 작성자 계보(author-lineage) 를 기반으로 검증하여, 신뢰할 수 있는 내부 소스만 허용하도록 합니다.
-
오탐(false positive)을 수동으로 검토할 수 있는 인간 검증 프로세스를 마련하여, 안전한 데이터 접근을 지속적으로 유지하도록 합니다.
이렇게 하면 대규모 내부 자동화 에이전트가 자율적으로 운영되더라도, 외부에서 악성 입력이 유입되어 내부 시스템이 손상되는 것을 방지할 수 있습니다.
세션 전환과 안전한 구성 변경
Agents Rule of Two는 절대적인 제약이 아니라, 세션 단위에서 유연하게 전환될 수 있습니다. 예를 들어, 한 에이전트가 처음에는 [A&C] 구성(웹 접근 및 통신 가능) 으로 동작하다가, 내부 시스템에 접근해야 하는 단계에서는 [B] 구성으로 전환하며 외부 통신 기능을 비활성화하는 식입니다.
이를 위해서는 '세션(session)'을 잘 정의하고 중요하게 다뤄야 합니다. AI 에이전트는 일반적으로 하나의 대화 컨텍스트 윈도우 내에서 모든 정보를 유지합니다. 하지만 이 세션이 새롭게 초기화되지 않으면, 이전 대화의 컨텍스트가 공격에 이용될 수 있습니다.
따라서 모든 세 가지 속성을 동시에 요구하는 경우에는 반드시 새로운 세션을 시작하거나 사람의 검증 절차를 포함해야 합니다. 이는 단순한 보안 패치가 아닌, LLM 기반 시스템의 아키텍처 자체에서 안전성을 확보하는 구조적 접근이라 할 수 있습니다. 즉, 공격자가 신뢰할 수 없는 입력을 통해 민감한 데이터에 접근하고, 그 결과를 외부로 전송하는 일련의 체인이 완성되지 못하게 구조적으로 설계해야 한다는 뜻입니다.
Agents Rule of Two의 한계와 Meta의 보안 보완 솔루션
한계(Limitation)
Agents Rule of Two는 AI 에이전트의 구조적 보안 위험을 줄이는 데 매우 실용적인 프레임워크지만, 이 규칙만으로 모든 보안 문제를 해결할 수 있는 것은 아닙니다. 이 원칙은 주로 프롬프트 인젝션(prompt injection)으로 인한 심각한 피해(예: 데이터 유출, 무단 행위 등)를 방지하는 데 초점을 맞추고 있습니다. 하지만 AI 에이전트에는 이 외에도 다양한 위협 벡터(threat vector)가 존재합니다.
예를 들어, 다음과 같은 위험 요소들은 여전히 Agents Rule of Two만으로는 충분히 방어되지 않습니다:
-
공격자 상승(Attacker Uplift): 공격자가 시스템 권한을 점차 확장하거나, AI를 활용해 더 큰 공격을 설계할 수 있는 상황.
-
스팸 확산(Proliferation of Spam): 자율적 에이전트가 의도치 않게 대량의 콘텐츠를 생성하거나 외부에 배포하는 문제
-
AI 에이전트의 실수 또는 환각(Hallucination): 모델이 잘못된 정보를 사실처럼 제시하거나, 부정확한 판단을 내리는 경우
-
과도한 권한 부여(Excessive Privilege): AI가 필요 이상으로 높은 수준의 시스템 권한을 부여받아 통제 범위를 벗어나는 문제
-
경미한 프롬프트 인젝션 결과(Misinformation): 공격자가 에이전트의 답변을 왜곡시켜 사용자에게 잘못된 정보를 전달하는 상황
즉, Agents Rule of Two는 위험 완화를 위한 '기초 설계 원칙'일 뿐, 완벽한 방어책은 아닙니다. 이 규칙을 적용했다고 해서 보안이 완성된 것은 아니며, 반드시 다른 보안 계층과 병행해야 합니다.
Defense in Depth(심층 방어)의 중요성
AI 보안을 설계할 때는 Defense in Depth(심층 방어) 개념이 필수적입니다. 이는 단일한 방어 계층에 의존하지 않고, 여러 단계의 방어 메커니즘을 중첩시켜 위험이 하나의 실패로 연결되지 않도록 하는 보안 전략입니다.
예를 들어, 에이전트가 “사용자 승인” 절차를 거치도록 설계되었다고 하더라도, 사용자가 경고를 무시하고 그대로 승인을 눌러버릴 가능성이 있습니다. 이러한 인간적 실수를 고려하면, 추가적인 검증 절차나 자동 차단 규칙이 반드시 병행되어야 합니다.
따라서 Agents Rule of Two는 최소 권한의 원칙(Principle of Least Privilege) 같은 기존의 보안 철학을 대체하는 것이 아니라 보완(supplement)할 수 있음을 명심해야 합니다. 즉, Rule of Two는 보안의 종착점이 아니라, AI 에이전트를 보다 안전하게 설계하기 위한 출발점이자 토대라는 점을 인지해야 합니다.
Meta의 추가 보안 프레임워크: Llama Protections
Meta는 Agents Rule of Two를 보완하기 위한 방법으로 Llama Protections를 함께 읽어보시길 권장합니다. Llama Protections는 Llama 모델을 기반으로 한 AI 시스템 전반에 적용되는 다층 보안 아키텍처로, 에이전트 보호를 조정하는 라마 방화벽, 잠재적인 프롬프트 주입을 분류하는 프롬프트 가드, 불안전한 코드 제안을 줄이는 코드 쉴드, 잠재적으로 해로운 콘텐츠를 분류하는 라마 가드 등을 제공하여 에이전트의 신뢰성과 안전성을 높이는 역할을 합니다.
앞으로의 방향 (What's Next)
이번에 공개한 Agents Rule of Two는 현재 시점에서 개발자들에게 실질적인 보안 프레임워크로 사용할 수 있으며, 앞으로 대규모 안전한 에이전트 개발(secure development at scale)을 가능하게 할 것으로 기대합니다.
특히, 최근 확산되고 있는 MCP(Model Context Protocol)와 같은 에이전트 도구 호출 표준은 여러 도구들을 플러그-앤-플레이(Plug-and-Play) 방식으로 연결할 수 있게 하지만, 동시에 새로운 보안 위험도 수반합니다. 따라서 Meta는 MCP에 Rule of Two 인식 기능을 내장하여 보안을 기본값으로 설계(Security-by-Default)하는 방향을 제안합니다. 예를 들어, 도구 호출 시 에이전트의 Rule of Two 구성([A / B / C] 중 어떤 조합인지)를 명시하도록 하여, 자동 승인 / 실패 / 추가 검증 요청 여부 등을 사전에 정책적으로 제어할 수 있다는 것입니다.
또한, AI 에이전트가 점점 더 강력해짐에 따라, 일부 고급 사용 사례(예: 인간 개입이 어려운 백그라운드 자동화 프로세스)에는 Rule of Two 원칙에 완전히 부합하지 않을 수도 있습니다. 이런 상황에서는 여전히 전통적 보안 장치(Guardrails) 와 인간 승인 절차(Human-In-The-Loop) 가 가장 신뢰할 수 있는 방법으로 채택해야 할 것입니다.
따라서 앞으로는 이러한 승인 절차까지 완전 자동화하기 위한 연구를 계속할 예정이며, 감독 에이전트(Oversight Agents)나 LlamaFirewall 같은 오픈소스 보안 플랫폼을 활용해 Rule of Two의 감독 기능을 강화할 계획입니다.
Meta가 공개한 Agents Rule of Two 원문 블로그
이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다. 
파이토치 한국 사용자 모임
이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일
로 보내드립니다! (기본은 Weekly지만 Daily로 변경도 가능합니다.)
아래
쪽에 좋아요
를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~ 