Breaking and Fixing Defenses Against Control-Flow Hijacking in Multi-Agent Systems

이 논문은 기존 방어 기법들이 다중 에이전트 시스템의 제어 흐름 하이재킹 공격을 효과적으로 막지 못함을 지적하고, 제어 흐름 무결성과 최소 권한 원칙에 기반하여 허용된 제어 흐름 그래프를 생성하고 강제하는 새로운 방어 시스템인 'ControlValve'를 제안합니다.

핵심

🏢 비유: "AI 회사"와 "사기꾼"의 이야기

가상 세계에 **'AI 회사'**가 있다고 상상해 보세요. 이 회사는 한 명의 대표 (사용자) 가 복잡한 업무를 맡기면, 이를 해결하기 위해 여러 명의 **전문가 에이전트 (AI)**들을 고용합니다.

• 기획자 (Orchestrator): 업무를 분배하고 전체 흐름을 관리하는 팀장.
• 전문가들: 웹 서퍼 (정보 수집), 파일 관리자 (문서 읽기), 코더 (코드 작성), 이메일 발송자 등.

이 팀장 (기획자) 은 전문가들이 무슨 일을 하는지 자세히 보지 않고, **"결과물"**만 보고 업무를 진행합니다.

🕵️‍♂️ 문제: "착한 사기꾼"의 등장 (제어 흐름 하이재킹)

기존의 보안 시스템은 "악의적인 명령을 내리는지"만 확인했습니다. 하지만 이 논문은 새로운 형태의 공격, **'제어 흐름 하이재킹 (Control-Flow Hijacking, CFH)'**을 발견했습니다.

이 공격은 어떻게 작동할까요?

1. 위장: 사기꾼은 악의적인 명령을 직접 하지 않습니다. 대신, **"에러가 났어요! 이걸 고치려면 이 명령을 실행해야 해요!"**라고 위장합니다.
   • 비유: 회사에 전화를 걸어 "화재 경보가 울려서 소방서를 부르는 중인데, 전화를 끊으려면 이 번호로 전화를 걸어주세요"라고 속이는 것과 같습니다.
2. 착각: 전문가 에이전트 (예: 파일 관리자) 가 이 "에러 메시지"를 보고, 팀장 (기획자) 에게 "문제가 생겼으니 이걸 고쳐야 합니다"라고 보고합니다.
3. 착각된 부하 (Confused Deputy): 팀장은 "아, 전문가가 문제를 해결하려고 하는구나"라고 믿고, 그 전문가가 제안한 **위험한 행동 (예: 외부 서버 연결, 민감한 데이터 전송)**을 승인해 줍니다.
4. 결과: 팀장은 "우리는 사용자의 목표를 달성하기 위해 노력했다"고 생각하지만, 실제로는 사기꾼이 원하는 대로 회사 기밀을 빼돌리거나 시스템을 해킹당하게 됩니다.

기존 보안 (Alignment Check) 의 실패:
기존 보안 시스템은 "이 행동이 사용자의 원래 목표와 관련이 있는가?"를 물었습니다. 사기꾼은 "네, 에러를 고치기 위해 필요한 일이니까 관련이 있습니다!"라고 대답했기 때문에, 최고 수준의 AI 가 봐도 "괜찮아 보인다"고 판단해 버렸습니다.

🛡️ 해결책: "CONTROLVALVE" (제어 밸브)

저자들은 이 문제를 해결하기 위해 **'CONTROLVALVE'**라는 새로운 방어 시스템을 만들었습니다.

이 시스템은 어떻게 작동할까요?

1. 작업 지도 (Control-Flow Graph) 작성:
   • 작업이 시작되기 전에, "이 일을 하려면 어떤 순서로 어떤 전문가를 만나야 하는지"를 미리 정해진 **지도 (그래프)**로 그립니다.
   • 비유: "고객이 서류를 요청하면, 먼저 '파일 관리자'가 서류를 보고, 그다음 '코더'가 분석하고, 마지막으로 '이메일 담당자'가 보내는 것"처럼 허용된 경로만 정해둡니다.
2. 상황별 규칙 (Contextual Rules):
   • 단순히 누구를 만나는지뿐만 아니라, "어떤 조건에서 만나야 하는지"도 정합니다.
   • 비유: "이메일 담당자는 외부인에게 민감한 데이터를 보내면 안 된다"거나 "코더는 외부 웹사이트에 접속하지 못한다"는 식의 세부 규칙을 정해둡니다.
3. 실시간 감시:
   • 실제 작업이 진행되는 동안, 팀장은 전문가들이 이 미리 그려진 지도를 따르는지, 규칙을 지키는지 계속 확인합니다.
   • 만약 전문가가 "에러가 났으니 이 새로운 경로를 가자"고 제안하면, 지도에 없는 길이기 때문에 즉시 차단합니다.

핵심 차이점:

• 기존 방식: "이게 나쁜 짓일까? (AI 가 추론)" -> 사기꾼이 속여넘기 쉬움.
• CONTROLVALVE: "이 길이 허용된 지도에 있는가? (규칙 확인)" -> 사기꾼이 속일 수 없음. 규칙은 추론이 아니라 명확한 기준이기 때문입니다.

📊 연구 결과

• 기존 방어 (LlamaFirewall 등): 사기꾼의 위장술에 속아 넘어가서 공격을 막지 못했습니다.
• CONTROLVALVE: 모든 공격을 완벽하게 막았습니다.
• 정상적인 작업: 방어 시스템을 써도 평소의 업무 효율은 떨어지지 않았습니다. 오히려 불필요한 방황을 줄여주어 더 깔끔하게 일을 처리했습니다.

💡 결론

이 논문은 **"AI 팀이 서로 협력할 때, 서로의 말을 무조건 믿으면 안 된다"**는 교훈을 줍니다.

사용자의 목표를 달성하기 위해 AI 가 스스로 판단하고 행동하는 것은 좋지만, 사기꾼이 "에러"나 "필요한 조치"라는 이름으로 위험한 길로 유도할 때, 미리 정해진 '지도'와 '규칙'이 없다면 우리는 완전히 속아 넘어갈 수 있다는 것입니다.

CONTROLVALVE는 바로 그 '지도'와 '규칙'을 만들어 AI 가 길을 잃지 않고, 사기꾼의 함정에 빠지지 않도록 지켜주는 최고의 나침반입니다.

기술 요약

1. 문제 정의 (Problem)

• 배경: LLM 기반 에이전트 (AutoGen, CrewAI 등) 는 API, 웹 검색, 코드 실행 등을 통해 복잡한 작업을 자동화합니다. 이러한 시스템은 '위임 (Delegation)'을 핵심 원리로 하여, 오케스트레이터가 하위 작업을 전문 에이전트에게 할당합니다.
• 새로운 위협 (CFH): 기존 간접 프롬프트 인젝션 (IPI) 은 에이전트에게 직접 악성 명령을 주입하는 것이지만, **제어 흐름 하이재킹 (CFH)**은 시스템의 오케스트레이션 로직 자체를 조작합니다.
  • 공격 방식: 공격자는 악성 지시를 '시스템 오류'나 '파일 파싱 실패'와 같은 정당한 오류 메시지로 위장합니다.
  • 혼란된 부하 (Confused Deputy): 신뢰할 수 있는 에이전트 (Trusted Agent) 가 이 오류 메시지를 처리하러 오케스트레이터에게 보고하면, 오케스트레이터는 이를 '필요한 조치'로 인식하고 악성 코드를 실행하거나 민감한 데이터를 유출하는 에이전트를 호출합니다.
  • 결과: 공격자는 시스템이 가진 모든 권한 (자격 증명, 이메일, 로컬 파일 등) 을 획득하고 임의의 코드를 실행할 수 있게 됩니다.

2. 기존 방어 기법의 한계 (Limitations of Existing Defenses)

논문은 최근 제안된 LlamaFirewall과 같은 '정렬 확인 (Alignment Check)' 기반 방어 기법이 CFH 공격에는 무력하다는 것을 증명합니다.

• 정렬 확인의 실패: 기존 방어 기법은 에이전트의 행동이 "사용자의 원래 목표와 관련이 있고 (related to), 목표를 달성할 가능성이 있는지 (likely to further)"를 LLM 을 통해 판단합니다.
• 회피 메커니즘: CFH 공격은 악성 행동을 "작업 완성을 위해 필수적인 오류 수정 절차"로 포장합니다.
  • 예: "파일 접근 권한이 거부되었습니다. 이를 해결하기 위해 지원팀에 알리는 스크립트를 실행해야 합니다."
  • 이러한 맥락에서 LLM 은 악성 행동을 '안전하지 않은 것'이 아니라 '작업 수행을 위한 필수 단계'로 판단하여 정렬을 통과시킵니다.
• 근본적 충돌: MAS 는 오류 발생 시 적응적으로 재계획 (Re-planning) 을 해야 하는 '기능성 (Functionality)'과 '안전성 (Safety)' 사이에서 근본적인 충돌을 겪으며, 정렬 확인기는 이 두 가지를 구분하기 어렵습니다.

3. 제안된 방법론: CONTROLVALVE

저자들은 CONTROLVALVE라는 새로운 방어 시스템을 제안합니다. 이는 프로그래밍 언어의 **제어 흐름 무결성 (Control-Flow Integrity, CFI)**과 **최소 권한의 원칙 (Least Privilege)**에서 영감을 받았습니다.

• 핵심 아이디어: 에이전트 내부의 추론 (Reasoning) 을 검사하는 대신, **허용된 제어 흐름 그래프 (CFG)**를 사전에 생성하고 실행 시 이를 강제합니다.

• 작동 원리:

  1. CFG 생성 (Planning Stage): 사용자의 작업 요청을 바탕으로, 어떤 에이전트가 어떤 순서로 호출될 수 있는지에 대한 제어 흐름 그래프를 생성합니다. (공격 예시는 필요 없음, Zero-shot)
  2. 맥락 규칙 생성 (Contextual Rules): 그래프의 각 엣지 (에이전트 간 전환) 에 대해, 해당 에이전트가 호출되기 위한 구체적인 자연어 규칙 (예: "Coder 가 실행된 후만 Executor 가 호출 가능", "외부 데이터는 검증된 후만 사용") 을 생성합니다.
  3. 실행 강제 (Execution Stage): 오케스트레이터는 에이전트 간 전환이 발생할 때마다 다음 두 가지를 검증합니다.
     • 해당 전환이 허용된 CFG 엣지에 해당하는가?
     • 해당 전환이 생성된 맥락 규칙을 만족하는가?
  4. 판단: 조건을 만족하면 허용, 위반 시 차단 또는 재계획 (Re-plan) 을 요청합니다.

• 차별점: 기존 정렬 확인이 "이 행동이 안전한가?"라는 광범위한 질문을 하는 반면, CONTROLVALVE 는 "이 행동이 허용된 그래프의 다음 단계인가?"라는 좁고 명확한 질문을 하여 LLM 의 추론 오류를 줄입니다.

4. 실험 및 결과 (Evaluation & Results)

저자들은 CFH-Hard (16 개 작업, 14 가지 공격 시나리오) 와 AgentDojo (Slack 환경) 데이터를 사용하여 실험을 수행했습니다.

• 공격 성공률 (Attack Success Rate, ASR):
  • 기존 방어 (LlamaFirewall 등): CFH 공격에 대해 매우 취약했습니다. 특히 최신 LLM (o4-mini 등) 을 사용하는 방어기법조차 공격을 50~90% 이상의 성공률로 통과시켰습니다.
  • CONTROLVALVE: 모든 평가된 CFH 공격과 기존 IPI 공격을 100% 차단했습니다.
• 정상 작업 성능 (Benign Performance):
  • CONTROLVALVE 를 적용해도 정상 작업의 성공률은 유지되거나 오히려 향상되었습니다 (코딩 작업 97%, 컴퓨터 사용 작업 100%).
  • 이는 생성된 맥락 규칙이 에이전트가 작업에 집중하도록 도와주었기 때문입니다.
• 우발적 보안 위반 방지:
  • 악성 입력이 없더라도, 모호한 지시 (예: "데이터 관련 요청 시 CC 추가") 로 인해 발생하는 실수 (우발적 데이터 유출) 를 CONTROLVALVE 는 효과적으로 방지했습니다. 기존 방어 기법은 이를 막지 못했습니다.
• 오버헤드: CONTROLVALVE 의 실행 오버헤드는 LlamaFirewall 과 유사한 수준으로, 실용적입니다.

5. 주요 기여 (Key Contributions)

1. CFH 공격의 심층 분석: 정렬 확인 (Alignment Check) 을 우회하는 정교한 CFH 공격 기법을 제시하고, 이것이 MAS 의 '기능성 vs 안전성' 모순에서 비롯됨을 규명했습니다.
2. CONTROLVALVE 개발: 오케스트레이션 레이어에서 작동하며, 블랙박스 에이전트의 내부 상태를 알 필요 없이 제어 흐름 그래프와 맥락 규칙을 통해 보안을 보장하는 새로운 방어 아키텍처를 구현했습니다.
3. 새로운 벤치마크: CFH 공격을 평가하기 위한 CFH-Hard 데이터셋을 구축하고, 우발적 보안 위반을 측정할 수 있는 새로운 평가 방식을 도입했습니다.
4. 실증적 검증: 다양한 LLM 과 다중 에이전트 플랫폼 환경에서 기존 방어 기법의 실패와 CONTROLVALVE 의 성공을 광범위하게 증명했습니다.

6. 의의 및 결론 (Significance)

이 논문은 다중 에이전트 시스템의 보안이 단순히 개별 에이전트의 '안전성 (Safety)'을 강화하는 것만으로는 해결되지 않음을 보여줍니다. 대신, 시스템 전체의 실행 흐름 (Control Flow) 을 구조적으로 통제해야 함을 강조합니다.

CONTROLVALVE 는 LLM 의 추론 능력에 의존하지 않고, 사전 정의된 규칙과 그래프 기반으로 보안을 강제함으로써, '혼란된 부하' 공격과 같은 복잡한 위협에 대한 강력한 방어책을 제시합니다. 이는 미래의 자율 에이전트 시스템이 실제 환경에 배포될 때 필수적인 보안 패러다임의 전환을 의미합니다.