에이전트 가드레일(Guardrail)에서 동일한 "차단됨(blocked)" 에러를 반환하는 것을 중단하세요

AI 에이전트에 대해 기본 차단(deny-by-default) 도구 가드(tool guards)를 실행한다면, 거부(refusal)는 단순한 로깅 사후 처리 사항이 아니라 보안 결정입니다.

저는 한 소스가 주말 동안 프로덕션 에이전트를 대상으로 잘못된 형식의 도구 호출(malformed tool call)을 약 1,400번 변형하며 시도하는 것을 목격했습니다. 매번 동일한 BLOCKED 응답은 공격자의 자동화된 탐색을 위한 피드백이 되었습니다: 동일한 입력 형태 → 동일한 거부 → "더 차가운(colder)", 형태 변경 → 응답 변경 → "더 따뜻한(warmer)".

Keysight의 논문(arXiv:2606.20470)은 이를 수치화합니다: 결정론적인 탐지 및 차단(deterministic detect-and-block) 방식은 쿼리 예산(query budget)이 증가함에 따라 공격 성공률(ASR)이 1에 가까워지게 만듭니다. 예측 가능한 거부가 모델 가이드 탐색(model-guided search)에 피드백을 제공하기 때문입니다. 그들의 탐지 및 오도(detect-and-misdirect) 접근 방식은 ASR 상한선을 최대 ~2 자릿수(orders of magnitude)까지 낮춥니다.

의사코드(pseudocode)로 표현한 저렴한 해결 방법은 다음과 같습니다:

​

# 이전: 안정적인 거부 = 공격자 탐색을 위한 레이블
def on_blocked(call):
    return {"error": "TOOL_CALL_BLOCKED", "code": 4031}  # 매번 동일함
...

이를 프로덕션에서 적용할 때의 주의사항:

1. 이는 여러분의 디버깅을 더 어렵게 만듭니다(여러분의 오탐(false positives) 또한 노이즈처럼 보일 것입니다) — 실제 이유는 내부적으로 로깅하고, 외부 응답만 다양하게 만드세요.
2. 지연 시간(latency)이 여전히 유출된다면 텍스트를 다양화하는 것만으로는 충분하지 않습니다. 타이밍(timing) + 에러 형태(error-shape)를 응답 표면(response surface)의 일부로 취급하세요.
3. 제가 명확한 답을 가지고 있지 않은 열린 질문: 오도(misdirection)가 단순히 오라클(oracle)을 사이드 채널(side channels)의 한 단계 위로 이동시키는 것뿐일까요?

저는 에이전트 도구 호출을 위한 오픈 소스 기본 차단 방화벽(agent-airlock)을 유지 관리하고 있으며, 이를 통해 이 로그를 포착할 수 있었습니다. 이 교훈은 모든 가드레일(guardrail)에 일반화될 수 있습니다: 거부된 호출의 응답은 공격 표면(attack surface)입니다.