Zero-trust AI Agent 설계법: 프롬프트 대신 인프라로 권한을 막는 운영 체크리스트

AI 에이전트를 운영 시스템에 붙일 때 가장 위험한 착각은 “프롬프트에 하지 말라고 쓰면 된다”는 생각이다. Google Developers Blog가 2026년 8월 17일 다룬 zero-trust AI agents 주제는 이 착각을 잘 찌른다. 자율 에이전트가 데이터베이스를 수정하고, 코드를 실행하고, 외부 API를 호출한다면 보안 경계는 모델의 선의가 아니라 인프라와 권한 구조에 있어야 한다.

Zero-trust의 기본 전제는 단순하다. 어떤 요청도 기본적으로 믿지 않는다. 사용자 입력, 검색된 웹 문서, 사내 문서, 이전 대화, 모델의 자기 판단까지 모두 검증 대상이다. AI 에이전트에서는 이 원칙이 더 중요해진다. 모델은 외부 문서 안에 들어 있는 악성 지시를 일반 정보처럼 읽을 수 있고, 도구 호출을 통해 실제 상태를 바꿀 수 있기 때문이다.

프롬프트 기반 통제의 한계

시스템 프롬프트는 필요하다. 답변 스타일, 금지 정책, 작업 순서, 사용자 확인 규칙을 알려주는 데 유용하다. 하지만 시스템 프롬프트는 최종 방어선이 될 수 없다. 사용자가 악의적인 지시를 보내거나, 웹 페이지가 prompt injection 문구를 포함하거나, 검색 결과가 조작되면 모델은 혼란스러운 컨텍스트 안에서 판단해야 한다.

더 큰 문제는 도구 권한이다. 모델이 deleteUser, refundPayment, deployProduction, sendEmail 같은 도구를 호출할 수 있다면, 한 번의 잘못된 판단이 실제 피해로 이어진다. “위험하면 호출하지 마”라는 문장은 도움이 되지만 충분하지 않다. 애초에 모델이 직접 호출할 수 없는 구조, 또는 호출해도 게이트웨이가 막는 구조가 필요하다.

권한은 최소 권한 원칙으로 설계해야 한다. 읽기 전용 에이전트에는 읽기 토큰만 준다. 초안 작성 에이전트에는 외부 전송 권한을 주지 않는다. 운영 변경이 필요한 경우에는 승인 대기 상태까지만 만들고, 별도 서비스가 승인 여부를 확인한 뒤 실행한다. 모델은 제안자이지 최종 집행자가 아니다.

게이트웨이가 해야 할 일

Zero-trust AI Agent에서 핵심 컴포넌트는 semantic gateway다. 일반 API gateway가 인증, 속도 제한, 라우팅을 담당한다면, semantic gateway는 요청의 의미와 위험도를 검사한다. 예를 들어 “고객 500명에게 할인 메일 보내기”는 단순 sendEmail 호출이 아니라 대량 외부 전송이다. 게이트웨이는 수신자 수, 템플릿, 개인정보 포함 여부, 승인 상태를 확인해야 한다.

게이트웨이는 최소 네 가지 검사를 해야 한다. 첫째, 스키마 검증이다. 도구 파라미터가 타입과 범위를 만족하는지 본다. 둘째, 정책 검증이다. 현재 에이전트 역할로 이 행동이 허용되는지 본다. 셋째, 컨텍스트 검증이다. 사용자가 실제로 해당 작업을 요청했는지, 요청 범위가 맞는지 확인한다. 넷째, 위험도 분류다. 읽기, 초안, 내부 수정, 외부 전송, 삭제, 결제 같은 등급을 나눠 승인 흐름을 다르게 태운다.

이 검사는 모델이 아니라 코드로 구현해야 한다. 일부 의미 판단에는 작은 모델이나 규칙 기반 분류기를 쓸 수 있지만, 최종 허용 여부는 명시적 정책 엔진이 결정하는 편이 안전하다. 실패 시에는 “모델이 거절했다”가 아니라 “정책 ID P-013에 의해 차단됐다”처럼 로그가 남아야 한다.

동적 코드 실행은 샌드박스가 기본값이다

에이전트가 코드를 작성하고 실행하는 제품은 특히 조심해야 한다. 데이터 분석, 크롤링, 브라우저 자동화, 테스트 생성 기능은 편리하지만, 실행 환경이 열려 있으면 파일 유출이나 네트워크 오남용으로 이어질 수 있다. zero-trust 관점에서는 동적 코드를 기본적으로 불신하고 격리해야 한다.

실무 기준은 다음과 같다. 파일 시스템은 작업 디렉터리로 제한한다. 네트워크는 기본 차단하고 필요한 도메인만 허용한다. 실행 시간과 메모리 제한을 둔다. 민감한 환경 변수는 주입하지 않는다. 실행 결과는 stdout, stderr, 생성 파일 목록, 네트워크 시도 로그로 남긴다. 컨테이너, VM, gVisor 같은 샌드박스 기술을 상황에 맞게 선택한다.

또한 샌드박스 안에서 생성된 결과를 운영 시스템에 반영하는 단계는 분리해야 한다. 에이전트가 만든 SQL을 바로 운영 DB에 실행하지 말고, explain plan, 영향 범위, 샘플 결과, 승인 단계를 거친다. 코드 패치도 마찬가지다. 에이전트는 브랜치를 만들고 테스트를 돌릴 수 있지만, production deploy는 보호된 CI/CD와 리뷰를 통과해야 한다.

운영 관측성과 사고 대응

보안은 차단만으로 끝나지 않는다. 어떤 에이전트가 어떤 입력을 받아 어떤 도구를 호출했고, 어떤 정책에 의해 허용 또는 차단됐는지 추적해야 한다. 그래야 사고가 났을 때 원인을 찾고, 재발 방지 테스트를 만들 수 있다.

로그에는 최소한 사용자 요청, 모델 버전, 시스템 프롬프트 버전, 검색된 외부 문서 ID, 도구 호출 파라미터, 정책 검증 결과, 승인자, 실행 결과가 포함돼야 한다. 개인정보와 민감 정보는 마스킹하되, 사고 분석에 필요한 구조는 남겨야 한다. 또한 차단 로그를 제품 개선 데이터로 써야 한다. 같은 정책에서 오탐이 반복되면 UX를 고치고, 같은 공격 패턴이 반복되면 방어 규칙을 추가한다.

레드팀 테스트도 필요하다. prompt injection 문서, 권한 상승 요청, 대량 전송 유도, 숨겨진 삭제 지시, 과도한 파일 읽기, 민감정보 요약 요청 같은 케이스를 회귀 테스트에 넣는다. 모델이나 프롬프트를 바꿀 때마다 이 테스트를 통과해야 한다.

바로 적용할 체크리스트

• 에이전트 권한을 읽기, 초안, 내부 수정, 외부 전송, 삭제, 결제 등 위험 등급으로 나눈다.
• 고위험 도구는 모델이 직접 실행하지 못하게 하고 승인 대기 객체만 만들게 한다.
• 모든 도구 호출 앞에 스키마 검증, 정책 검증, 컨텍스트 검증, 위험도 분류를 둔다.
• 동적 코드 실행은 샌드박스에서만 허용하고 네트워크와 파일 접근을 제한한다.
• 운영 DB 변경, 이메일 발송, 결제, 배포는 별도 승인·리뷰 파이프라인을 통과시킨다.
• 도구 호출과 정책 판단 결과를 감사 가능한 로그로 남긴다.
• prompt injection과 권한 상승 시나리오를 회귀 테스트에 포함한다.
• 차단 이벤트를 주기적으로 분석해 오탐과 미탐을 줄인다.

Zero-trust AI Agent의 핵심은 모델을 불신하자는 뜻이 아니다. 모델이 실수해도 시스템이 무너지지 않게 만들자는 뜻이다. 프롬프트는 행동 지침이고, 인프라는 안전벨트다. 실제 제품에서는 안전벨트가 먼저다.