[기술 요약] 멀티 에이전트 보안에서 아키텍처의 중요성

1. 문제 정의 (Problem Statement)

최근 AI 시스템은 단일 모델(Single LLM)에서 벗어나, 여러 자율 에이전트가 협력하여 복잡한 작업을 수행하는 **멀티 에이전트 시스템(MAS, Multi-Agent Systems)**으로 진화하고 있습니다. 그러나 기존의 AI 보안 연구는 주로 단일 에이전트의 탈옥(Jailbreak)이나 프롬프트 주입(Prompt Injection)에 집중되어 왔습니다.

본 논문은 **"개별 에이전트가 보안적으로 견고하더라도, 이들을 연결하는 아키텍처 설계(협업 방식, 역할 분담, 통신 구조 등)가 새로운 공격 표면(Attack Surface)을 생성하고 보안 취약점을 증폭시킬 수 있다"**는 점을 지적합니다. 즉, 시스템의 구조적 결정이 작업 성능(Performance)과 공격 저항성(Attack Resistance) 사이의 트레이드오프를 결정한다는 것이 핵심 문제입니다.

2. 연구 방법론 (Methodology)

연구진은 아키텍처 설계의 세 가지 핵심 차원을 설정하고, 이를 세 가지 실제적인 에이전트 환경에서 체계적으로 실험했습니다.

A. 세 가지 설계 차원 (Design Choices)

1. 역할 구성 (Role Configuration): 권한과 책임을 어떻게 분배하는가? (예: 계획자, 실행자, 검토자 등으로 역할 분담)
2. 통신 토폴로지 (Communication Topology): 에이전트 간 상호작용 구조는 어떠한가? (예: 중앙 집중형 Star, 순차적 Chain, 피어 투 피어 Mesh)
3. 메모리 및 상태 가시성 (Memory & State Visibility): 각 에이전트가 어떤 정보(자신의 사고 과정, 타 에이전트의 기록 등)에 접근할 수 있는가?

B. 실험 환경 (Agentic Environments)

기존의 단일 에이전트 벤치마크를 멀티 에이전트 환경에 맞게 변형하여 사용했습니다.

• BrowserART: 웹 브라우저 제어 (클릭, 입력, 스크롤 등)
• OS-Harm: 데스크톱 운영체제 사용 (픽셀 기반 제어)
• RedCode-Gen: 샌드박스 내 코드 생성 (악성 코드 생성 등)

C. 평가 지표 (Metrics)

단순한 성공/실패를 넘어, 공격이 어느 단계에서 차단되거나 실행되는지를 구분하는 **단계별 평가(Stage-wise Evaluation)**를 도입했습니다.

• Planning Refusal: 계획 단계에서의 거부
• Execution-stage Interception: 실행 단계에서의 차단
• Partial Harmful Execution: 부분적 유해 실행
• Successful Attack Completion (Harmful Task, HT): 공격 성공 (최종 목표 달성)

3. 주요 기여 (Key Contributions)

1. 멀티 에이전트 보안 벤치마크 구축: 기존 단일 에이전트 벤치마크를 멀티 에이전트 설정으로 확장하고 단계별 지표를 도입하여 공개했습니다.
2. 아키텍처 효과의 실증적 규명: 13가지 아키텍처 구성과 다양한 모델을 통해 설계 결정이 보안에 미치는 영향을 정량화했습니다.
3. 보안-성능 트레이드오프 측정: 성능(Benign Accuracy)은 향상되면서 보안성(Attack Success Rate)은 급격히 악화되는 현상을 입증했습니다.

4. 주요 연구 결과 (Key Results)

① 역할 분담의 역설 (Role Specialization)

• 취약성 증폭: 역할을 세분화할수록(Specialization) 공격 성공률이 높아지는 경향이 있습니다. 이는 "유해한 의도의 파편화(Fragmentation of harmful intent)" 때문입니다. 계획자는 전체 맥락을 모르고, 실행자는 단순한 명령만 수행하므로, 개별 에이전트는 자신이 유해한 행동을 하고 있다는 것을 인지하지 못하게 됩니다.
• 성능과 보안의 괴리: BrowserART 실험 결과, 전문가 구성(Specialists)은 단일 에이전트보다 작업 성능은 높았으나, 공격 성공률은 최대 3.8배까지 높았습니다.

② 통신 구조의 영향 (Topology)

• 환경에 따른 상이한 결과:
  • BrowserART에서는 중앙 집중형인 Star 구조가 가장 위험했습니다.
  • RedCode-Gen에서는 순차적인 Chain 구조가 가장 위험했습니다(설계 $\rightarrow$ 코드 $\rightarrow$ 검토 $\rightarrow$ 테스트 과정이 자연스러운 워크플로우처럼 보여 유해한 요청이 정당한 사양처럼 위장됨).
• Mesh 구조의 이점: Mesh 구조는 에이전트들이 전체 목표를 공유할 가능성이 높아, 개별적으로 유해성을 인지하고 거부할 확률이 높았습니다.

③ 메모리 가시성 (Memory)

• 투명성이 항상 안전을 보장하지 않음: 메모리 공유(Shared Memory)가 보안을 개선할 것이라는 직관과 달리, 실험 결과는 환경과 모델에 따라 결과가 달랐습니다. 공유된 정보가 유해한 패턴을 탐지하는 데 도움을 주기도 하지만, 공격자가 더 풍부한 공격 맥락을 제공하는 수단이 되기도 합니다.

5. 결론 및 시사점 (Significance)

본 논문은 **"멀티 에이전트 시스템의 보안은 개별 모델의 안전성(Alignment)만으로는 보장될 수 없다"**는 강력한 메시지를 전달합니다.

• 설계 시 주의사항: 성능 향상을 위해 도입한 '역할 분담'이나 '효율적 통신 구조'가 시스템의 보안 구멍이 될 수 있음을 인지해야 합니다.
• 평가 패러다임의 전환: AI 시스템의 성능을 평가할 때, 단순히 작업 성공률만 볼 것이 아니라 아키텍처 변화에 따른 보안 취약성 변화를 반드시 병행 평가해야 합니다.
• 방어 전략의 다각화: 보안 검증을 계획 단계(Planning)뿐만 아니라 실행 단계(Execution)에서도 수행할 수 있도록 아키텍처 차원의 방어 설계가 필요합니다.