X-AgentRed: 다중 서비스 에이전트 생태계의 구성적 보안 취약점 탐지 방법

Gmail, Slack, Jira 및 결제 API 전반에 걸쳐 도구 호출을 연결하는 개인 에이전트는 새로운 공격 표면(attack surface)을 만듭니다. 무해한 사용자 요청이라도 여러 서비스 경계를 넘나들며 행동들이 누적되고 상호작용하면서 유해한 결과를 초래할 수 있습니다. X-AgentRed는 도구 의존성(tool dependencies)의 방향 그래프를 구축하고, 공격 경로(attack paths)를 샘플링하며, 실행 피드백을 사용하여 이를 정교화함으로써 이러한 구성적 실패(compositional failures)를 발견하는 레드팀(red-teaming) 프레임워크입니다.

이 논문 (arXiv 2610.13886v1)은 단일 도구 보안 테스트와 다중 서비스 오케스트레이션의 현실 사이의 격차를 다룹니다. 기존의 레드팀 방법들은 LLM(Large Language Model)에게 유해한 시나리오를 생성하도록 프롬프트를 주거나, 알려진 공격 목표를 무해해 보이는 단계로 분해하도록 합니다. 대신 X-AgentRed는 노드가 도구이고 엣지(edge)가 한 도구의 효과가 다른 도구의 선행 조건(preconditions)을 충족하는 방식을 나타내는 그래프를 구성한 다음, 유해한 결과를 초래하는 경로들을 탐색합니다.

구성적 위험 모델 (The Compositional Risk Model)

에이전트가 여러 서비스에 걸친 도구에 접근할 때, 세 가지 조건이 위험을 만듭니다:

효과 누적(Effect accumulation): 한 서비스에서의 행동이 지속되는 상태를 생성하여 다른 서비스의 후속 행동에 영향을 미칩니다.
선행 조건 연결(Precondition chaining): 도구 B는 오직 도구 A가 이미 공유된 상태(캘린더 이벤트, 파일 권한, 결제 승인 등)를 수정했을 때만 실행될 수 있습니다.
무해 의도(Benign intent): 사용자의 원래 요청은 무해해 보이지만, 도구 호출 시퀀스는 사용자가 예상하거나 승인하지 않은 결과를 초래합니다.

예시: 사용자가 에이전트에게

만약 에이전트가 '참석자에게 알림 보내기(notify attendees)'를 잘못 해석하여 외부 메일링 리스트로 메시지를 전송하거나, 또는 잘못된 Jira 티켓을 업데이트하여 프로덕션 배포를 트리거한다면, 개별 도구 호출은 고립적으로 볼 때 합리적으로 보이지만 그 구성적 결과는 유해할 수 있습니다.

X-AgentRed가 의존성 그래프(Dependency Graph)를 구축하는 방법

레드팀 에이전트는 각 도구의 스키마를 분석하여 다음을 추출합니다:

효과 (Effects): 이 도구가 어떤 상태를 변경합니까? (예: email.send()는 전송된 메시지를 생성하고, calendar.update()는 이벤트 시간을 변경함)
전제 조건 (Preconditions): 이 도구가 실행되기 전에 무엇이 참이어야 합니까? (예: payment.authorize()는 파일에 유효한 결제 수단을 요구함)
잠재적 피해 (Potential harms): 기밀성(confidentiality), 무결성(integrity), 또는 가용성(availability)을 위반할 수 있는 결과는 무엇입니까? (예: 데이터 유출(data exfiltration), 무단 접근, 리소스 고갈)

그 다음 이를 방향 그래프(directed graph)로 구성하며:

각 노드는 하나의 도구입니다.
도구 A에서 도구 B로의 엣지(edge)가 존재한다면, A의 효과가 B의 전제 조건을 만족시킨다는 의미입니다.
엣지는 해당 전환이 피해를 발생시킬 가능성으로 가중치가 부여됩니다.

이 그래프에서 경로(path)를 샘플링하면, 순서대로 실행될 때 유해한 결과를 초래할 것으로 예상되는 도구 호출 시퀀스를 얻게 됩니다.

자체 진화형 레드팀 루프 (Self-Evolving Red-Teaming Loop)

X-AgentRed는 그래프 구축에서 멈추지 않습니다. 샘플링된 경로를 실제 또는 시뮬레이션된 에이전트 환경에 실행하고, 실행 피드백을 사용하여 개선합니다:

경로 다양화 (Path Diversification)

경로가 성공적으로 피해를 발생시킬 경우, 프레임워크는 유사한 효과를 가진 도구들로 대체하여 변형을 탐색합니다. 만약 email.send() → slack.post() → payment.authorize()가 성공하면, 공격이 통신 플랫폼 전반에 걸쳐 일반화되는지 확인하기 위해 email.send() → teams.message() → payment.authorize()를 시도해 봅니다.

만약 도구의 전제 조건(preconditions)이 충족되지 않아 경로가 실패하면, 프레임워크는 막힌 단계를 분석하고 누락된 전제 조건을 만족시키기 위해 더 이른 시점의 도구를 삽입합니다. 만약 payment.authorize()가 결제 수단이 존재하지 않아 실패한다면, 체인(chain) 초기에 payment.add_method()를 추가합니다.

이는 피드백 루프(feedback loop)를 생성합니다:

graph TD
    A[의존성 그래프에서 샘플 경로] --> B[에이전트 환경에서 경로 실행]
    B --> C{유해한 결과?}
...

평가 결과 (Evaluation Results)

본 논문은 X-AgentRed를 네 가지 최첨단 에이전트 모델(frontier agentic models)과 테스트했으며, STAC(LLM에게 유해한 시나리오 생성을 프롬프트하는 기준선 레드팀 방식)과 비교했습니다.

지표 (Metric)	X-AgentRed	STAC	개선율 (Improvement)
유해 경로 비율 (Harmful path rate)	1.77배	1.0배	공격 성공률 77% 증가
...

유해 경로 비율은 보안 정책을 위반하는 결과를 생성하는 샘플링된 경로의 분율(fraction)을 측정합니다. 도구 커버리지(Tool coverage)는 성공적인 공격에 관련된 고유한 도구의 수를 측정합니다. X-AgentRed의 그래프 기반 탐색은 LLM 기반 생성이 놓치는, 낯선 도구 조합을 포함하는 공격 경로를 발견합니다.

아키텍처: 보안 경계를 설정할 위치 (Architecture: Where to Draw Security Boundaries)

다중 서비스 에이전트 보안은 여러 계층에서 경계(boundaries)가 필요합니다:

도구 인터페이스 계층 (Tool Interface Layer)

각 도구는 실행 전에 입력값을 검증하고 권한 부여(authorization)를 강제해야 합니다. 이는 개별 도구가 오용되는 것을 방지하지만, 유효한 도구 호출들이 결합하여 해악을 초래하는 구성적 실패(compositional failures) 자체를 막지는 못합니다.

서비스 커넥터 계층 (Service Connector Layer)

에이전트를 외부 서비스(Gmail API, Slack API, Jira API)와 연결하는 커넥터는 속도 제한(rate limits), 감사 로깅(audit logging), 그리고 권한 범위 설정(permission scoping)을 강제해야 합니다. 이는 단일 손상된 도구 호출의 피해 반경(blast radius)을 제한합니다.

에이전트 오케스트레이터 계층 (Agent Orchestrator Layer)

도구 호출 시퀀스를 계획하고 실행하는 오케스트레이터는 다음을 수행해야 합니다:

서비스 전반에 걸쳐 영향을 추적하는 상태 기계(state machine) 유지
불변 조건(invariants) 강제 적용 (예: '명시적인 사용자 확인 없이 외부 도메인으로 이메일을 보내지 않음')
사전 조건이 위험을 나타낼 때 실행을 중단시키는 회로 차단기(circuit breaker) 구현

사용자 권한 부여 계층 (User Authorization Layer)

에이전트가 어떤 도구 호출 시퀀스라도 실행하기 전에, 의도된 영향의 요약본을 제시하고 사용자 승인을 요청해야 합니다. 이는 구성적 실패(compositional failures)를 막는 마지막 방어선입니다.

구현 개요 (Implementation Sketch)

다음은 간소화된 종속성 그래프 빌더를 구현하는 방법입니다:

from typing import Dict, List, Set
from dataclasses import dataclass

...

이것은 예시(toy example)일 뿐입니다. 실제 프로덕션 구현에는 다음 사항들이 필요합니다:

피해 가능성에 기반한 확률적 엣지 가중치(Probabilistic edge weights)
가중치를 업데이트하기 위한 실행 피드백 통합(Execution feedback integration)
부분 경로 전반에 걸친 사전 조건 충족을 모델링하는 상태 추적(State tracking)
성공적인 공격을 다양화하기 위한 도구 대체 논리(Tool substitution logic)

발생 가능한 실패 모드 (Likely Failure Modes)

그래프 불완전성 (Graph Incompleteness)

도구 스키마가 모든 영향과 사전 조건을 포착하지 못하면, 그래프는 엣지를 놓치고 유효한 공격 경로를 발견하는 데 실패합니다. 이는 신중한 스키마 설계와 도구가 진화함에 따라 지속적인 유지보수가 필요합니다.

실행 환경 이탈 (Execution Environment Divergence)

레드팀(red-teaming) 환경이 프로덕션 에이전트 환경과 일치하지 않으면 (다른 API 버전, 다른 권한 모델, 다른 속도 제한 등), 테스트에서 성공했던 공격이 프로덕션에서는 실패할 수 있고 그 반대도 마찬가지입니다.

사전 조건 폭발 (Precondition Explosion)

도구의 수가 늘어날수록 가능한 사전 조건의 수는 조합적으로 증가합니다. 매번 차단되는 단계마다 사전 조건을 정교하게 다듬는 것은, 위험한 결과에 도달하지 못하면서 새로운 사전 조건을 충족시키기 위해 프레임워크가 계속해서 도구를 추가하는 무한 루프를 초래할 수 있습니다.

오탐지 (False Positives)

예상치 못한 결과를 초래하는 모든 경로가 유해한 것은 아닙니다. 이 프레임워크는 피해(데이터 유출, 무단 접근, 리소스 고갈 등)에 대한 명확한 정의와 놀랍지만 무해한 결과와 실제 보안 위반을 구별할 수 있는 방법이 필요합니다.

관측 가능성 요구 사항 (Observability Requirements)

다중 서비스 에이전트를 위한 Red-teaming은 모든 계층에서 계측(instrumentation)을 요구합니다:

도구 호출 로그 (Tool call logs): 입력, 출력 및 타임스탬프를 포함하여 모든 도구 호출을 기록합니다.
상태 스냅샷 (State snapshots): 효과 축적(effect accumulation)을 추적하기 위해 각 도구 호출 전후의 에이전트 내부 상태를 캡처합니다.
서비스 간 트레이스 (Cross-service traces): 분산 추적(distributed tracing, OpenTelemetry, Jaeger)을 사용하여 서비스 전반에 걸친 도구 호출을 연결하고 구성적 경로를 시각화합니다.
피해 감지 신호 (Harm detection signals): 도구 호출이 보안 정책을 위반할 때 이벤트를 방출합니다(예:

이 프레임워크는 에이전트의 도구 세트가 크고, 진화하며, 여러 서비스 경계를 아우를 때 가장 가치가 높습니다. 공격 표면(attack surface)이 수동으로 열거할 만큼 작거나 발견된 경로를 검증할 실행 환경이 부족한 경우에는 활용도가 떨어집니다.