내부 에이전트를 위한 AI 레드팀, 공격자보다 먼저 Tool Poisoning을 시험하는 법

여전히 많은 팀이 프롬프트만 레드팀하고 에이전트 뒤의 도구는 무시합니다. 순서가 거꾸로입니다. 내부 에이전트는 독성 도구 출력, 오해를 부르는 문맥, 과도한 자격 증명 때문에 더 자주 망가집니다.

데모가 아니라 신뢰 경계부터 보라

가장 멋진 데모가 가장 못생긴 가정을 숨깁니다. 어떤 도구가 데이터를 쓸 수 있는지, 어떤 도구가 비밀에 닿는지, 어떤 도구가 샌드박스 밖 부작용을 일으키는지부터 그려야 합니다. 이 지도가 또 하나의 탈옥 프롬프트 목록보다 훨씬 중요합니다.

모델이 다른 시스템이 이미 신뢰하는 도구를 호출할 수 있다면, 그것은 전이 신뢰 문제입니다. 레드팀은 채팅창이 아니라 그 신뢰 사슬을 따라가야 합니다.

Tool Poisoning은 결국 컨텍스트 공격이다

독성 도구는 shell 접근이 없어도 충분히 위험합니다. 잘못된 요약을 주거나, 경고를 긴 출력 속에 묻거나, 위험한 작업을 무해한 유지보수처럼 포장할 수 있습니다. 모델은 이를 컨텍스트로 받아들이고 자신 있게 잘못 행동합니다.

에이전트가 모순을 감지하는지, 파괴적 단계 전에 확인을 요구하는지, 도구 출력이 수상하거나 지나치게 설득적일 때 안전하게 감속하는지 시험해야 합니다.

일반 업무처럼 보이는 테스트 케이스를 설계하라

노골적으로 악성인 문자열만 던지지 마세요. 현실적인 티켓, 낡은 문서, 잘못된 런북, 은근히 위험한 도구 응답을 사용하세요. 내부 에이전트는 만화 같은 공격보다 평범해 보이는 나쁜 입력에 더 잘 속습니다.

좋은 테스트 세트는 조용한 데이터 유출, 승인 우회, 메모리 오염, 인간 지시와 도구 지시의 혼선을 모두 다룹니다.

승리 조건은 우아한 거부다

모델이 대담하다는 것을 증명하려는 것이 아닙니다. 멈추고, 묻고, 피해를 제한하고, 원래 없어야 했던 권한 연쇄를 거부한다는 증거가 필요합니다.

최고의 내부 에이전트는 항상 행동하는 에이전트가 아닙니다. 언제 도움을 멈춰야 하는지 아는 에이전트입니다.