X-AgentRed가 도구 의존성 그래프로 개인 에이전트의 교차 서비스 위험을 찾는다

무엇인가

개인 에이전트가 GitHub, Notion 같은 서비스의 도구를 엮어 여러 단계 작업을 처리하면서, 정상적인 사용자 요청을 수행하는 과정에서 서비스 간 효과가 누적·상호작용해 의도치 않거나 유해한 결과가 발생할 수 있다. 논문은 이런 실패가 정보·권한·상태 변화가 서비스 사이를 어떻게 전파되는지에 달려 있다고 본다. 기존 레드팀 방법은 LLM에게 작업·환경 설명으로부터 위험 경로를 제안하게 하거나, 인간 또는 LLM이 지정한 유해 목표를 겉보기엔 무해한 행동 조합으로 분해하게 한다. 문제는 이 생성이 학습 시 익힌 패턴에 편향돼 익숙한 도구 조합에 탐색이 몰리고, 학습 데이터에 잘 없는 새로운 교차 서비스 상호작용은 충분히 탐색되지 않는다는 점이다. 논문은 시나리오를 x=(u, s0, h)로 정의하는데, u는 안전한 완료가 가능한 정상 요청이어야 하고 h는 사용자가 요청하거나 승인하지 않은 목표다. 평가 지표는 후보 시나리오 중 실제로 유해 결과가 확인된 비율인 유해 경로율(HPR)이다.

어떻게 동작하나

제안 방법의 핵심은 HarmFlow 그래프다. 레드팀 에이전트가 각 도구 t에 대해 실행 전제조건 P_t, 효과 E_t, 잠재적 유해 H_t를 분석해 C(t)=(P_t, E_t, H_t)라는 구조적 표현을 만든다. 효과는 도구가 만들어내는 상태 변화나 정보, 전제조건은 필요한 입력·자원·접근 권한, 잠재적 유해는 그 효과가 교차 서비스 워크플로에서 가능하게 할 수 있는 유해 결과다. 예를 들어 파일 공유 도구는 기존 문서, 지정된 수신자, 공유 설정을 바꿀 권한이 있는 계정을 전제조건으로 요구하고, 수신자에게 문서 접근 권한을 부여하는 효과를 내며, 권한 없는 사람에게 민감 정보가 노출되는 유해를 가능하게 한다. 에이전트는 한 도구의 효과가 다른 도구의 전제조건을 만족시킬 수 있는지(효과-전제조건 쌍 집합 R)를 판정해 t_i에서 t_j로 향하는 간선을 만들고, 이렇게 복잡한 도구 시퀀스 구성을 단순한 쌍별 의존성 검사로 분해한다. 문서 생성 도구는 공유 도구의 '기존 문서' 전제조건을 만족시키지만, 문서 읽기는 공유 설정 변경 권한을 주지 않는다는 식이다. 간선은 실행을 보장하는 것이 아니라 지원 의존성을 나타내며, 그래프 순회가 이 의존성들을 긴 도구 경로로 결합한다.

무엇과 다른가

레시피 샘플링은 역방향 랜덤 워크로 이뤄진다. 목표 유해 h를 가진 도구 집합 T_h에서 시작해, 각 단계에서 들어오는 이웃 N^-(t_i)을 따라 앞선 도구를 뽑고, 미리 정한 최대 길이까지 샘플링한 뒤 순서를 뒤집어 경로 π를 얻는다. 레시피는 이 경로와 목표 유해의 쌍 r=(π, h)이다. 이어서 유해 유발 요인 분류(12개 범주)에서 요인 c를 하나 고르고, 정상 사용자 요청 u와 초기 환경 s0를 생성해 시나리오로 인스턴스화한다. 유해 결과 범주는 10개로 정리돼 있다.

어떻게 쓰나

자기 개선은 실행 피드백으로 이뤄진다. 타깃 에이전트가 시나리오를 실행한 궤적에서 유해가 발생하면(H(τ)=1), 유해 결과 산출에 핵심적이지 않은 도구 노드를 HarmFlow 그래프의 인접 노드로 교체해 레시피를 다양화하되 유해 유발 요인 c는 유지한다. 같은 취약점을 다른 서비스 조합에서 시험할 수 있게 하려는 것이다. 유해가 나오지 않으면(H(τ)=0), 막힌 단계 t_j에서 충족되지 않은 전제조건을 식별해 그래프의 P_tj와 해당 의존성 간선을 정제하고, 그 전제조건을 만족시키도록 앞선 단계를 재구성한다(π' = π̃_<j ∥ π_≥j). 이 그래프·레시피 갱신이 이후 샘플링을 이끈다. 시나리오 인스턴스화와 사용자 프롬프트 생성은 판정 피드백으로 직접 최적화되지 않는다.

전제와 한계

실험은 ToolSimulator로 30개 서비스, 914개 도구를 갖춘 다중 서비스 생태계를 시뮬레이션해 진행했다. 레드팀 에이전트는 Claude Opus 4.8, 타깃 모델은 GPT-5.6 Sol, GLM-5.2, DeepSeek-V4-Pro, Claude Opus 4.8 네 개다. 판정은 Claude Opus 5와 GPT-5.6 Sol 두 LLM이 맡고, 두 판정 모두 유해 결과와 그럴듯한 유해 유발 조건, 정상 사용자 요청 시퀀스를 확인해야 인정한다. 베이스라인은 STAC과 TRACE이며, 타깃당 250개 후보 시나리오를 생성해 비교했다.

결과에서 X-AgentRed의 HPR은 네 타깃 평균으로 STAC의 1.77배, TRACE의 10.36배였다. 도구 커버리지는 STAC의 2.99배, TRACE의 1.84배다. 네 에이전트 합산 성공 시나리오는 192개로 STAC 105개, TRACE 27개를 앞섰다. 도구 레지스트리 기준 커버리지는 평균 41.5%로 STAC 13.9%, TRACE 23.7%보다 넓다. 에피소드당 평균 13.1개 도구와 5.0개 서비스를 쓰며, STAC은 4.6개/2.7개, TRACE는 2.0개/1.9개다. 실행된 워크플로의 도구 호출 수는 평균 23.2회로 STAC 7.8회, TRACE 3.3회보다 길다. 성공 레시피의 계획 길이 중앙값은 타깃별 8~9단계, 최대 12단계이고, 192개 성공 중 190개가 서로 다른 계획 경로였다. 상위 10개 도구가 전체 도구 사용에서 차지하는 비중은 24.3%로 STAC 43.2%, TRACE 48.9%보다 낮아 사용이 분산돼 있다. 자기 개선 효과도 측정됐는데, 레시피 다양화는 HPR 27.7%로 랜덤 샘플링 18.0%를 웃돌고, 정제는 이전에 유해를 내지 못한 경로에서 15.5%를 기록했으며 두 전략이 확인된 유해 결과의 평균 32.8%를 담당했다. 시나리오 준비·생성·검증에 드는 API 호출은 시나리오당 22.10회로 STAC 55.00회, TRACE 103.24회보다 적다. 판정 민감도 실험에서는 두 판정 중 하나만 인정하는 OR 집계가 합의(AND)보다 HPR을 15.2~30.4%포인트 높였다.

개발자 관점에서 이 논문은 도구 레지스트리가 계속 커지는 에이전트 제품에서 어떤 조합이 위험한지 사전에 훑는 방법을 제시한다. LLM의 기억에 의존하는 대신 도구별 전제조건·효과를 명시적으로 적어 두고 그래프로 연결하므로, 새 서비스가 붙을 때 그 도구의 속성만 갱신하면 탐색 범위를 넓힐 수 있다는 것이 설계 의도다. 다만 여기서의 HPR은 시뮬레이터 환경에서 LLM 판정 두 개가 합의한 '유해 시나리오 비율'이지 실제 배포 환경의 공격 성공률이 아니며, 도구 커버리지와 경로 다양성 같은 지표도 인과적 실패 메커니즘의 다양성을 분리해 측정한 것이 아니라고 저자들은 명시한다. 도구 호출 수 같은 길이 지표도 경로 길이와 적응 정책이 섞인 값이다.

저자들이 밝힌 한계는 다음과 같다. 서비스가 진화하면 HarmFlow 그래프 유지에 추가 계산 비용이 들고, 새로 추가되거나 수정된 도구는 도구 표현을 갱신하고 영향을 받는 의존성을 다시 평가해야 한다. 또한 계획 경로가 길다고 유해 결과가 일관되게 늘지는 않았는데, 긴 경로는 중간 행동이 안전 검사에 더 노출돼 탐지나 개입 가능성을 높일 수 있기 때문이다. 실패한 에피소드에는 추가 후속 턴이 주어지므로 실행 길이는 워크플로 자체와 적응 정책을 함께 반영한다. 저자들은 네 타깃에 걸쳐 유해로 라벨된 192개 궤적을 수동 검토해 보상 해킹의 증거를 찾지 못했다고 밝혔고, 각 설정은 고정된 시뮬레이션 생태계에서 한 번만 실행해 평가했다.