에이전트 행동 방어
에이전트 행동 방어
에이전트형 AI에서는 단순히 '무슨 내용이 흐르는가'를 검사하는 것만으로는 부족해요. 에이전트가 실제로 무엇을 하고 있는지까지 봐야 안전해요. 에이전트 행동 방어는 런타임에 에이전트의 행동을 보호하는 장치로, 도구 사용이 사용자 의도에 부합하는지, 그리고 호출하는 도구 자체가 허용된 것인지를 검사해요. 프롬프트 방어·콘텐츠 모더레이션·데이터 유출 방지가 에이전트를 흐르는 콘텐츠를 감시한다면, 에이전트 행동 방어는 그 위에 행동이라는 한 층을 더 쌓는 개념이에요. 두 가지 기능으로 구성되고, 모두 정책에서 설정하고 Guard API 검사 요청을 통해 실행돼요.
Dangerous Deviation 감지기 (베타)
현재 베타로 제공되는 Dangerous Deviation 감지기는 에이전트의 신뢰 범위를 벗어난 위험한 행동을 감지해요. 조작, 환각, 과도한 행동 등 원인이 무엇이든 동일하게 잡아내요. 에이전트에서는 같은 행동이 어떤 순간엔 정당하고 다른 순간엔 해로울 수 있어요. 예를 들어 send_email은 사용자가 보고서 공유를 요청했을 때는 문제없지만, 독이 든 도구 응답이 원인이 됐다면 위험하죠. 그래서 이 감지기는 고정된 규칙이 아니라 대화 기록 대비로 각 도구 호출을 판단해요.
도구 호출이 플래그로 표시되려면 다음 두 조건이 모두 성립해야 해요.
- 행동이 위험하다. 감지기는 오늘 세 가지 위험 유형을 인식해요.
- 데이터 유출: 승인되지 않은 대상에 민감 데이터가 전송되거나 저장됨.
- 접근·권한 상승: 리소스의 공개 공유, sudo나 admin 부여, ACL 확대, 샌드박스를 넘어선 권한 상승 시도.
- 시스템 파괴: 영구 리소스의 삭제·초기화.
- 행동에 근거(warrant)가 없다. 신뢰할 수 있는 메시지(
user,system역할) 어디에도 그 호출을 정당화할 내용이 없음.tool응답이나 외부 콘텐츠로 들어온 지시는 신뢰할 수 없는 지시가 섞여 있을 수 있으므로, 근거로 절대 인정되지 않아요.
위험 유형 하나가 감지됐는데 근거가 없을 때만 플래그가 올라가요. 두 조건 중 하나라도 충족되지 않으면 통과해요. 예를 들어 사용자가 주문 상태를 물은 대화에서 get_order_status 호출은 요청에 부합하므로 감지되지 않고, 외부 주소로 export_customer_records를 호출하는 것은 요청에 근거가 없고 데이터를 유출하므로 감지되며, load_branding_theme 같은 엉뚱하지만 위험하지 않은 호출은 감지되지 않아요.
사용하려면 정책에서 Dangerous Deviation 감지기를 켜고, Guard API 요청의 마지막 assistant 메시지에 도구 호출을 담아 대화 기록과 함께 보내면 돼요. 최상위 tools 필드에 도구 정의도 함께 전달해야 해요 — 정의가 없으면 예측 품질이 떨어지고 감지기가 내는 설명도 제한될 수 있어요.
설명(Explanations)
요청에 "breakdown": true를 설정하고 도구 정의를 제공하면, 각 감지 결과에 독자별로 쓰인 explanation 객체가 포함돼요.
reason_code: 위험 유형을 나타내는 기계가 읽을 수 있는 안정적인 코드 — 라우팅, 대시보드, 자동화에 사용.reason: 에이전트 사용자를 위한 자연어 설명.agent_guidance: 에이전트 자신을 위한 자연어 지시 — 에이전트 컨텍스트에 다시 넣어 위험한 행동에서 벗어나도록 유도.debug_info.dev_tips: 통합·치유를 위한 개발자용 안내.
감지 이벤트는 이유 텍스트와 함께 로그에 나타나고 분석(analytics)에 집계돼요. 이 감지기는 보수적인 설정으로 출시돼서, 극단적인 사례를 잡는 것보다 낮은 오탐률을 우선해요. 운영 트래픽에서 먼저 Detect 모드로 돌려 검토한 뒤 Enforce 모드로 전환하는 것을 권장해요.
Tool Allow/Deny List
Tool Allow/Deny List는 에이전트가 런타임에 호출할 수 있는 도구를, 실제 도구 호출 시점에 강제해요.
- 허용 목록(Allow list): 목록에 없는 도구에 대한 호출을 감지해요. 에이전트가 항상 쓸 도구 집합이 고정돼 있는 경우에 유용해요.
- 거부 목록(Deny list): 목록에 있는 도구 호출을 감지해요. 특정 고위험 도구만 차단하고 나머지는 제한 없이 열어둘 때 쓰기 좋아요.
결과는 결정적이에요. 거부된 도구 호출은 내용과 무관하게 감지되고, 이유 텍스트가 해당 도구와 어떤 목록 때문에 감지됐는지 밝혀요. 그래서 거부된 도구를 호출하면 감지되는지, 허용된 도구를 호출하면 감지되지 않는지 확인하는 식으로 배포 검증을 할 수 있어요. 이 목록은 에이전트가 호출할 수 있는 도구를 통제하며, 특정 검사 콘텐츠의 판정을 덮어쓰는 콘텐츠 허용/거부 목록과는 별개예요.
도구 응답 검사
에이전트를 향한 프롬프트 공격은 사용자가 아니라 도구를 통해 들어오는 경우가 많아요. 독이 든 도구 응답이 그 대표적 경로예요. Guard API 요청에서 도구 결과를 tool 역할 메시지로 전달하면, 도구 메시지는 신뢰할 수 없는 콘텐츠로 검사돼서 정책에 따라 프롬프트 방어와 데이터 유출 감지가 함께 적용돼요.
강제 배포 절차
다른 가드레일과 같은 단계적 접근을 따라요.
- 먼저 관찰: Detect mode로 런타임 보호를 돌려 차단 없이 감지만 기록하고, 실제 트래픽의 감지 내용을 검토해요. 평가 단계에서 Detect mode를 쓰면 코드 변경 없이 나중에 강제로 전환할 수 있어요.
- 조정: 정책과 감지기 임계값을 트래픽·데이터 패턴에 맞추고, 오탐을 보고해서 모델이 사용 사례에 맞게 보정되도록 해요.
- 강제: 감지 정확도가 검증되면 대시보드에서 프로젝트를 Enforce mode로 전환해요.
운영 규모에서 보정을 거치면 오탐률은 보통 0.5% 미만이에요. 작거나 튜닝되지 않은 설정에서 측정한 정확도는 대표성이 없으니, 정책 튜닝과 보정 주기를 거치면 초기 결과가 크게 개선된다는 점을 기억하세요. 감지 결과는 Guard API 응답으로 반환되고("breakdown": true 사용 시 감지기별 결과), 로그와 분석에 나타나며 SIEM으로 내보낼 수 있어요.