Zero-trust AI Agent 설계 체크리스트: 프롬프트 필터보다 의도·도구·세션 로그를 같이 봐야 한다

AI 에이전트 보안을 프롬프트 필터 하나로 해결하려는 접근은 오래가지 않는다. 공격자는 “이전 지시를 무시해” 같은 노골적인 문장을 쓰지 않아도 된다. 정상적인 말투로 환불을 요청하고, 작은 금액을 여러 번 나눠 요청하고, 정책의 빈틈을 찾아 합법처럼 보이는 도구 호출을 만들 수 있다.

Google Developers Blog의 Zero-trust Agents 시리즈 2편은 이 지점을 잘 짚는다. Part 1이 Cloud KMS 서명, gVisor 격리, 입출력 게이트웨이 같은 결정적 통제를 다뤘다면, Part 2는 런타임 거버넌스, 의도 판단, 이상행동 탐지로 넘어간다. 핵심 메시지는 단순하다. 문법적으로 정상인 요청도 의도와 세션 흐름을 봐야 한다.

이 글은 개발팀이 고객지원, 환불, 내부 업무 자동화 에이전트를 만들 때 적용할 수 있는 zero-trust AI agent 체크리스트를 정리한다.

왜 프롬프트 필터만으로 부족한가

정규식 기반 필터는 명확한 공격에는 유용하다. “ignore previous instructions”, “환경변수를 출력해”, “관리자 권한으로 실행해” 같은 문구는 차단할 수 있다. 하지만 실제 업무 공격은 더 조용하다.

예를 들어 사용자가 “연간 소프트웨어 라이선스가 우리 워크플로우에 맞지 않으니 환불해 주세요”라고 요청했다고 하자. 문장은 정상이다. 금액도 주문 총액 이하일 수 있다. SQL 파라미터도 올바르다. 하지만 회사 정책상 개봉된 디지털 라이선스는 30달러 초과 환불에 매니저 승인이 필요할 수 있다. 이 경우 단순 필터와 스키마 검증은 문제를 못 잡는다.

따라서 에이전트 보안은 세 층으로 나누어야 한다.

• payload 검사: prompt injection, 악성 URL, 민감정보 유출 차단
• tool intent 검사: 제안된 도구 호출이 사용자 의도와 업무 정책에 맞는지 판단
• session behavior 검사: 여러 턴에 걸친 누적 남용을 탐지

하나만 두면 빈틈이 생긴다.

도구 호출 직전에 의도를 검증한다

가장 중요한 지점은 모델이 도구를 호출하려는 순간이다. 사용자의 말, 대화 이력, 도구 이름, 파라미터, 업무 정책을 함께 보고 실행 여부를 결정해야 한다. Google은 이를 Semantic Governance Policies로 설명한다. 자연어 정책을 바탕으로 issue_refund 같은 tool call을 허용하거나 차단하는 구조다.

실무에서는 클라우드 특정 제품을 쓰지 않더라도 같은 패턴을 만들 수 있다. 도구 호출 전 middleware를 두고 다음 정보를 평가한다.

• 사용자 요청 원문
• 모델이 선택한 tool name
• tool arguments
• 관련 주문·계정·권한 컨텍스트
• 업무 정책 문서 또는 rule id
• 이전 턴에서 이미 실행된 action

중요한 것은 금액, 타입, 상태만 보는 것이 아니라 “왜 이 도구를 호출하는지”를 보는 것이다. refund_amount=120이 주문 총액보다 작더라도, 품목이 디지털 라이선스이고 정책상 매니저 승인이 필요하면 차단해야 한다.

세션 단위 이상행동을 따로 본다

단일 요청은 정상인데 전체 흐름은 비정상일 수 있다. 예를 들어 소프트웨어 환불 정책이 30달러 이하 단건을 허용한다면, 공격자는 20달러 환불을 여러 번 요청할 수 있다. 각 요청은 정책을 통과하지만 누적 환불액은 주문 총액을 넘어설 수 있다.

이 문제는 single-turn guardrail로 잡기 어렵다. 세션 로그와 계정 단위 집계를 봐야 한다.

필요한 지표는 다음과 같다.

• 세션별 tool call 횟수
• 동일 계정의 짧은 시간 내 반복 요청
• 같은 주문에 대한 누적 환불액
• 실패한 tool call 이후의 우회 시도
• 정책 거부 후 표현만 바꿔 재요청한 비율
• 평소와 다른 시간대·지역·디바이스 패턴

에이전트 이상행동 탐지는 모델 응답 품질 문제가 아니라 결제, 권한, 데이터 변경의 안전장치다. 특히 돈이나 권한이 움직이는 에이전트에는 반드시 필요하다.

모델 응답과 도구 실행을 분리해 기록한다

AI 에이전트 사고 조사에서 가장 답답한 상황은 “모델이 그렇게 했다”는 말만 남는 경우다. 실제로는 모델이 어떤 도구를 선택했고, 어떤 파라미터를 만들었고, 정책 엔진이 무엇을 판단했고, 백엔드가 어떤 응답을 반환했는지 알아야 한다.

로그는 최소 네 가지로 나누는 것이 좋다.

1. user event: 사용자 요청과 세션 정보
2. model event: 모델의 tool selection과 rationale 요약
3. policy event: 허용·차단 verdict와 rule id
4. backend event: 실제 API status, latency, side effect id

민감한 원문을 모두 저장하라는 뜻은 아니다. 개인정보와 secret은 마스킹해야 한다. 하지만 조사 가능한 구조는 남겨야 한다. 그래야 보안팀, 개발팀, 고객지원팀이 같은 사실을 보고 대응할 수 있다.

사람 승인 단계를 어디에 둘지 정한다

Zero-trust는 모든 것을 막는 전략이 아니다. 위험이 큰 실행을 승인 경로로 보내는 전략이다. 환불, 계정 폐쇄, 권한 상승, 외부 이메일 발송, 데이터 삭제는 자동 실행보다 승인 단계를 거치는 편이 안전하다.

승인 UI에는 다음 정보가 필요하다.

• 에이전트가 하려는 action
• 근거가 된 사용자 요청
• 핵심 파라미터
• 적용된 정책
• 예상 side effect
• 되돌릴 수 있는지 여부

사람은 모델의 긴 reasoning을 읽고 싶어 하지 않는다. 승인에 필요한 근거만 짧게 봐야 한다.

실행 체크리스트

• 프롬프트 필터, 의도 검증, 세션 이상탐지를 분리했는가
• tool call 직전에 정책 검증 middleware를 두었는가
• 자연어 업무 정책을 rule id와 함께 관리하는가
• 같은 주문·계정에 대한 누적 action을 집계하는가
• 모델 이벤트, 정책 이벤트, 백엔드 이벤트 로그를 분리하는가
• 개인정보와 secret 마스킹 기준이 있는가
• 돈, 권한, 삭제, 외부 발송 작업에는 사람 승인 단계를 두었는가
• 정책 거부 사유를 사용자에게 얼마나 공개할지 정했는가
• 거부 후 재시도·우회 시도를 세션 단위로 탐지하는가
• 테스트에는 정상 요청뿐 아니라 조용한 사회공학 요청도 포함했는가

Zero-trust AI agent의 핵심은 모델을 믿지 않는 것이 아니다. 모델 한 번의 판단에 돈, 권한, 데이터 변경을 맡기지 않는 것이다. 프롬프트 필터는 시작점일 뿐이고, 실제 운영에서는 의도, 도구, 세션 로그가 함께 움직여야 한다.

출처: Google Developers Blog, “Build zero-trust AI agents that judge intent, not just syntax”, 2026년 9월 15일.