제로 트러스트 AI 에이전트 설계: 프롬프트 필터보다 중요한 런타임 거버넌스

AI 에이전트 보안을 프롬프트 필터로만 막으려는 팀은 곧 한계에 부딪힙니다. Google의 zero-trust agents 글에서 중요한 메시지도 같습니다. 정적 규칙과 빌드 타임 테스트만으로는 합법적으로 보이는 요청 속의 의도를 판단하기 어렵습니다. 그래서 보안 검사를 에이전트 코드 바깥, 런타임 플랫폼으로 옮겨야 합니다.

Google 예시는 고객지원 환불 에이전트입니다. 에이전트는 주문을 조회하고, 재입고 수수료를 계산하고, 환불을 실행합니다. 문제는 공격자가 항상 “이전 지시를 무시해” 같은 노골적인 문장을 쓰지 않는다는 점입니다. 공격자는 정상적인 말투로, 정상적인 금액 안에서, 정책상 환불하면 안 되는 디지털 상품 환불을 요청할 수 있습니다. SQL 파라미터도 정상이고, 금액도 주문 총액 이내라면 단순 문법 검사는 통과합니다.

문제: 문법적으로 정상인 요청이 정책상 위험할 수 있습니다

전통적인 방어는 대개 세 가지입니다.

• 금칙어와 정규식으로 프롬프트 인젝션 차단
• 입력값 타입 검사와 금액 한도 검사
• CI 테스트로 알려진 공격 패턴 재현

이 방식은 필요하지만 충분하지 않습니다. 예를 들어 “연간 Workplace 라이선스를 샀는데 우리 워크플로우에 맞지 않아서 환불해 주세요”라는 문장은 공격처럼 보이지 않습니다. 금액도 120달러라 주문 총액 149달러보다 작습니다. 하지만 회사 정책이 “30달러 초과 디지털 라이선스는 관리자 승인 없이는 환불 불가”라면 이 요청은 차단되어야 합니다.

여기서 필요한 판단은 문법이 아니라 의도와 정책의 관계입니다. 상품명이 소프트웨어라는 것을 이해하고, 환불 요청이 어떤 도구 호출로 이어지는지 보고, 회사 정책과 비교해야 합니다.

원인: 에이전트는 여러 턴에 걸쳐 권한을 소비합니다

일반 API 보안은 요청 하나를 검사합니다. 하지만 에이전트는 여러 턴에 걸쳐 정보를 모으고 권한을 소비합니다. 첫 번째 요청은 정상일 수 있습니다. 두 번째 요청도 정상일 수 있습니다. 그런데 전체 세션을 보면 계정 잔액을 조금씩 빼내거나, 여러 고객에게 반복 환불을 실행하거나, 도구 호출을 우회하는 패턴일 수 있습니다.

따라서 AI 에이전트 보안에는 세 층이 필요합니다.

첫째, 엣지에서 악성 입력과 민감정보 유출을 막는 필터입니다. Google은 Model Armor를 예로 들며 프롬프트 인젝션, jailbreak, 악성 URL, 민감 데이터 유출을 요청 경로에서 검사한다고 설명합니다.

둘째, 도구 실행 직전에 의도를 판단하는 정책 엔진입니다. Semantic Governance Policies처럼 도구 이름, 파라미터, 사용자 프롬프트, 대화 이력, 비즈니스 정책을 함께 보고 허용 또는 차단을 결정해야 합니다.

셋째, 세션 전체의 이상 행동을 보는 탐지입니다. Agent Anomaly Detection처럼 한 번의 요청으로는 보이지 않는 다중 턴 악용을 로그와 텔레메트리로 잡아야 합니다.

해결: 코드 안의 if문보다 런타임 정책을 우선 설계합니다

실무에서 모든 정책을 코드에 박아 넣으면 유지보수가 어려워집니다. 환불 정책, 승인 기준, 지역별 규정, 고객 등급 예외는 자주 바뀝니다. 개발자가 매번 배포해야 한다면 보안 정책이 제품 속도를 늦추고, 반대로 급하게 고치다 보면 구멍이 생깁니다.

런타임 거버넌스의 장점은 정책 소유권을 분리할 수 있다는 점입니다. 에이전트 개발자는 도구와 워크플로우를 만들고, 보안·플랫폼 관리자는 정책을 관리합니다. 에이전트 코드가 바뀌지 않아도 도구 호출 전에 정책 판정을 바꿀 수 있습니다.

정책은 기계가 읽을 수 있어야 하지만 사람이 검토할 수 있어야 합니다. “디지털 상품, 소프트웨어 라이선스, 개봉된 라이선스는 30달러 초과 환불 시 관리자 승인이 필요하다”처럼 자연어 제약으로 표현하고, 어떤 도구에 적용되는지 명시하는 방식이 실무적입니다.

적용 예시: 환불 에이전트 정책 분리

환불 에이전트를 운영한다고 가정하면 최소한 다음 도구를 분리해야 합니다.

• verify_order: 주문 확인, 읽기 전용
• calculate_refund: 환불 가능 금액 계산, 읽기/계산
• draft_refund_response: 고객에게 보낼 답변 초안 생성
• issue_refund: 실제 환불 실행
• escalate_to_manager: 관리자 검토로 넘김

읽기 도구는 비교적 넓게 허용할 수 있습니다. 하지만 issue_refund는 반드시 정책 엔진을 거쳐야 합니다. 정책 입력에는 주문 품목, 금액, 상품 유형, 고객 요청 문장, 이전 대화, 고객 등급, 지역 규정이 포함되어야 합니다.

또한 egress 검사도 필요합니다. 에이전트가 응답하면서 카드 번호, 내부 토큰, 직원 ID, 결제 시크릿을 노출하지 않도록 출력 경로에서 한 번 더 필터링해야 합니다. 입력만 막는 보안은 절반짜리입니다.

운영 로그에 반드시 남겨야 할 것

제로 트러스트 AI 에이전트는 “막았다”보다 “왜 막았는지 설명할 수 있다”가 중요합니다. 감사 로그에는 최소한 다음 정보가 있어야 합니다.

• 사용자 요청 원문 또는 안전하게 마스킹된 원문
• 모델이 제안한 도구 호출과 파라미터
• 적용된 정책 이름과 버전
• 허용, 차단, 승인 요청 중 어떤 판정이 났는지
• 판정 근거 요약
• 실제 도구 실행 여부와 결과
• 사람이 개입했다면 승인자와 시간

이 로그가 없으면 장애나 분쟁이 생겼을 때 재현이 어렵습니다. “모델이 그렇게 했다”는 설명은 운영팀에도 고객에게도 부족합니다.

실행 체크리스트

• 에이전트 도구를 읽기, 계산, 초안, 실행 도구로 분리합니다.
• 실행 도구마다 적용할 비즈니스 정책을 문서화합니다.
• 금칙어 필터만 두지 말고 도구 호출 직전 정책 판정 단계를 둡니다.
• 정책은 코드 배포 없이 바꿀 수 있는 형태로 관리합니다.
• 입력 필터와 출력 필터를 모두 둡니다. 민감정보 유출은 응답에서도 발생합니다.
• 세션 단위 이상 탐지를 위해 사용자, 도구, 금액, 반복 횟수, 실패율을 로그로 남깁니다.
• 차단 이벤트는 개발팀만 보지 말고 운영·보안 담당자가 읽을 수 있는 설명을 남깁니다.
• 첫 출시에서는 실제 실행 도구를 끄고 초안 생성과 승인 플로우만 검증합니다.

AI 에이전트 보안은 프롬프트를 더 길게 쓰는 문제가 아닙니다. 에이전트가 권한을 쓰는 순간마다 의도, 정책, 세션 행동을 검사하는 문제입니다. 실무 개발팀은 모델 안전성 발표를 기다리기보다, 지금 가진 도구 호출 경로를 기준으로 런타임 거버넌스를 먼저 설계해야 합니다.