에이전트 PoC는 대개 답변 품질에서 멈춘다. 시연장에서는 예약을 찾고, 티켓을 열고, 코드를 고치고, 고객 기록을 요약한다. 그런데 운영 회의로 들어가면 질문이 바뀐다. “그 tool을 정말 호출해도 되는가.” “사용자 의도와 권한이 확인됐는가.” “성공했지만 정책을 어긴 실행은 누가 잡는가.” 이 질문에 답하지 못하면 에이전트는 제품이 아니라 자동화된 우회로다.
안전은 응답 뒤가 아니라 호출 앞에 선다
기존 guardrail은 입력과 최종 출력에 붙었다. 이것만으로는 부족하다. tool-using agent의 위험은 문장보다 side effect에서 터진다. 메일 발송, DB 수정, 결제, 권한 변경, 파일 삭제는 출력 검열로 되돌릴 수 없다.
Runtime safety interceptor는 agent와 tool 사이에 놓는 얇은 판정 계층이다. 모델이 tool call을 제안하면 곧바로 실행하지 않는다. 먼저 risk verdict를 생성한다.
{
"tool": "update_customer_record",
"intent_match": "pass",
"auth_scope": "insufficient",
"data_sensitivity": "high",
"reversibility": "low",
"verdict": "block",
"reason": "사용자 확인 없는 원장성 데이터 변경"
}
핵심은 모델에게 “조심하라”고 말하는 것이 아니다. 실행 경로 자체를 바꾸는 것이다.
에이전트 안전은 모델 성격이 아니라 runtime 계약이다.
unsafe-success를 별도 상태로 기록해야 한다
운영에서 가장 위험한 결과는 실패가 아니다. 실패는 티가 난다. 더 위험한 것은 업무 목표를 달성했지만 금지된 경로로 달성한 성공이다. 이를 unsafe-success로 분리해야 한다.
SafeClawBench 같은 최근 연구도 tool-using agent의 실패를 단순 텍스트 수락으로 보지 않는다. 보호 객체 노출, persistent memory 쓰기, 메시지 발송, DB 수정, harmful code 실행처럼 실제 tool/state harm을 별도 endpoint로 나눈다. 이 관점은 기업 운영에도 그대로 들어온다.
| 상태 | 업무 결과 | 안전 결과 | 운영 판정 |
|---|---|---|---|
| failure | 미완료 | 위반 없음 | 재시도 또는 사람 이관 |
| safe-success | 완료 | 위반 없음 | 정상 |
| unsafe-success | 완료 | 위반 있음 | 사고 후보 |
| blocked-risk | 미실행 | 사전 차단 | 정책 개선 데이터 |
unsafe-success를 성공률에 섞으면 조직은 잘못 배운다. agent가 인증을 건너뛰고도 문제를 해결하면 현업은 “일은 됐다”고 본다. 다음 배포에서 그 경로는 정상 패턴이 된다.
interceptor는 네 가지 입력으로 판정한다
좋은 interceptor는 별도 거대 모델이 아니다. 정책, 권한, context, tool metadata를 묶어 실행 직전 판정을 내리는 harness다.
- intent: 사용자 요청과 tool argument가 같은 목적을 향하는가.
- authority: 호출 주체에게 필요한 scope와 승인 이력이 있는가.
- blast radius: 실행이 읽기인지 쓰기인지, 되돌릴 수 있는지.
- evidence: 식별자, 금액, 대상, 승인 근거가 trace에 남는가.
OpenAI Agents SDK의 tool guardrails 문서는 function tool을 실행 전후로 감싸고, input tool guardrail이 실행 전 call을 skip·replace·tripwire 처리할 수 있다고 설명한다. MCP의 2025-11-25 authorization specification도 scope, token audience validation, HTTPS, PKCE 같은 실행 권한의 하한선을 명시한다. 이 둘을 합치면 방향이 분명하다. agent 설계는 prompt가 아니라 execution boundary 설계로 이동했다.
차단만으로는 운영이 되지 않는다
모든 위험 call을 막으면 안전해 보인다. 하지만 현장은 멈춘다. interceptor는 block 장치가 아니라 routing 장치여야 한다.
낮은 위험은 그대로 실행한다. 중간 위험은 사용자 확인이나 관리자 승인을 붙인다. 높은 위험은 argument를 축소하거나 read-only tool로 대체한다. 정책 위반은 중단하고 사건으로 남긴다. 이 loop가 있어야 agent가 차단 뒤에 다른 위험 경로를 찾아 우회하는 일을 막는다.
운영 로그에는 최소한 네 가지가 남아야 한다. 원래 tool call, risk verdict, 최종 action, 이후 결과다. 이 trace가 있어야 평가가 가능하다. “모델이 왜 그랬는가”보다 “runtime이 왜 허용했는가”를 물어야 한다.
참고
- OpenAI Agents SDK Guardrails, 2026 current docs: https://openai.github.io/openai-agents-python/guardrails/
- OpenAI Agents SDK Tool Guardrails, 2026 current docs: https://openai.github.io/openai-agents-python/ref/tool_guardrails/
- OpenAI Guardrails Python Quickstart, 2026 current docs: https://openai.github.io/openai-guardrails-python/quickstart/
- Model Context Protocol Authorization Specification, 2025-11-25: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
- SafeClawBench, arXiv, 2026-06-16: https://arxiv.org/abs/2606.18356
- AgentGuard: Runtime Verification of AI Agents, arXiv, 2025-09-28: https://arxiv.org/abs/2509.23864
- Combining Cost-Constrained Runtime Monitors for AI Safety, arXiv, 2025-07-19: https://arxiv.org/abs/2507.15886
이제 guardrail을 제품 경계로 올려라
Runtime safety interceptor는 보안팀의 부가 장치가 아니다. agent product의 핵심 UX다. 사용자는 tool call을 보지 않지만, 조직은 tool call의 책임을 진다.
AX Ops에서는 agent 설계를 prompt, tool, policy, approval, trace, eval을 하나의 운영 loop로 묶는다. PoC에서 잘 답하는 agent가 아니라, 운영에서 안전하게 행동하는 agent를 만든다. 이 전환을 시작하려면 tool inventory부터 risk verdict schema까지 한 번에 설계해야 한다: AX Ops 방법론 →