Google ADK로 보는 제로 트러스트 AI 에이전트 보안 체크리스트

출처: https://developers.googleblog.com/build-zero-trust-ai-agents-with-googles-agent-development-kit/

핵심 요약: 운영 환경의 에이전트에는 단단한 경계가 필요하다

시스템 프롬프트는 보안 통제가 아니다. 확률 모델에 주는 지시일 뿐이며 프롬프트 인젝션이나 모델 변경으로 흔들릴 수 있다. Google의 글은 모델이 속을 수 있다고 가정하고 중요한 통제를 프롬프트 밖의 아키텍처로 옮기라고 말한다. 핵심은 상태를 바꾸는 쓰기의 암호학적신원, 생성 코드의 격리 실행, 입력과 출력과 도구 호출을 검사하는 결정적 게이트웨이다.

에이전트 보안이 주목받는 이유

AI 에이전트는 고객 지원, 데이터 분석, 콘텐츠 파이프라인, 개발 운영으로 들어가고 있다. 이제 질문은 답변이 좋은가에 그치지 않는다. 악성 지시가 들어왔을 때 어떤 권한까지 도달하는지가 중요하다. Google의 예시는 환불 에이전트다. 정상적으로는 환불 금액을 계산하고 장부에 기록한다. 공격자가 규칙 무시, 과도한 환불, 환경 변수 출력을 요구하면 모델을 신뢰하는 설계에서는 데이터베이스와 런타임이 위험해진다.

첫 번째 방어선: 중요한 쓰기에 서명하라

모든 작업자가 하나의 넓은 데이터베이스 연결을 공유하면 추적성이 약하다. 각 에이전트가 자기 키로 상태 변경 페이로드에 서명하고, API나 인그레스 계층이 커밋 전에 검증해야 한다. 그러면 어떤 에이전트가 기록을 만들었는지, 승인된 내용이 무엇인지, 나중에 데이터가 변조되지 않았는지 확인할 수 있다. 결제, 권한, 게시, 검수 업무에는 특히 중요하다.

두 번째 방어선: 생성 코드를 격리하라

에이전트는 계산, 파일 파싱, 데이터 정리를 위해 짧은 스크립트를 만들 수 있다. 이를 운영 서버 권한으로 실행하면 비밀 유출이나 호스트 침해로 이어질 수 있다. Google은 gVisor 방식 격리, 네트워크 차단, 권한 제거, 메모리 제한, 짧은 타임아웃을 제안한다. 작은 팀도 전용 러너, 네트워크 제한, 입출력 로그, 운영 비밀과의 분리를 최소 기준으로 삼아야 한다.

세 번째 방어선: 프롬프트와 도구 호출을 통제하라

정책 게이트웨이는 탈옥 문구, 키 유출, 환불 한도 초과, 위험한 SQL, 고위험 작업을 검사할 수 있다. 모델처럼 창의적일 필요는 없고 예측 가능해야 한다. AI 도구를 평가할 때는 워크플로별신원, 변경 불가 감사 로그, 샌드박스, 관리자 한도, 프롬프트 인젝션 테스트를 물어보라. BTTC 소프트웨어 디렉터리 와 BTTC 블로그 에서 관련 도구와 글을 살펴볼 수 있다.

자주 묻는 질문

Google ADK가 필수인가?

필수는 아니다. ADK는 예시이며 신원, 샌드박스, 게이트웨이, 감사는 어떤 에이전트 프레임워크에도 적용된다.

더 좋은 프롬프트로 prompt injection을 해결할 수 있나?

아니다. 지시는 행동을 개선하지만 외부 강제 통제를 대체하지 못한다.

작은 팀의 첫 단계는 무엇인가?

에이전트 런타임에서 넓은 자격 증명을 제거하고 고위험 도구에 게이트웨이와 로그를 추가하라.

도입 전에 확인할 운영 기준

AI 에이전트 플랫폼을 고를 때 모델 이름이나 화려한 데모만 보면 안 된다. 워크플로별로 권한을 나눌 수 있는지, 도구 호출이 변경 불가능한 로그로 남는지, 실패 시 되돌릴 수 있는지, 관리자 정책을 사용자 입력이 우회할 수 없는지 확인해야 한다. 내부 도입은 요약, 분류, 초안 작성, 읽기 전용 검색처럼 위험이 낮은 작업부터 시작하는 편이 안전하다. 서명, 격리, 게이트웨이, 경보가 테스트로 검증된 뒤에 쓰기 권한을 단계적으로 넓혀야 한다.

개발 팀을 위한 실무적 의미

이 원칙은 대기업만을 위한 것이 아니다. 작은 제품도 무인 작업은 검증된 API를 통과하게 하고, 데이터베이스 직접 쓰기를 피하며, 게시 전 검증을 수행하고, 결과를 감사 로그에 남길 수 있다. 에이전트에 편리한 권한을 줄수록 경계 설계의 가치는 커진다. 안전한 자동화는 속도를 늦추는 장치가 아니라 실패 범위를 줄이고 나중에 설명 가능한 상태를 만드는 투자다.

권한은 단계적으로 넓혀야 한다

모든 에이전트에 같은 강한 권한을 줄 필요는 없다. 읽기 전용 요약이나 분류는 상대적으로 위험이 낮지만, 계정 변경, 환불, 게시, 삭제를 수행하는 에이전트는 별도 기준이 필요하다. 작은 권한으로 시작하고 감사 로그를 보며 실패 패턴을 모은 뒤 테스트를 늘려 권한을 확장해야 한다. 이렇게 하면 편의성을 유지하면서 사고의 범위를 줄일 수 있다.

평가에서는 증거를 확인하라

벤더나 내부 팀에는 설명보다 증거를 요구해야 한다. 샌드박스 설정, 네트워크 제한, 서명 검증 실패 사례, 차단된 도구 호출, 복구 절차, 감사 리포트를 확인할 수 있으면 운영 전 판단이 현실적이 된다. 특히 자율 게시나 고객 대응처럼 민감한 흐름에서는 정상 데모뿐 아니라 악성 입력을 받았을 때 실제로 멈추는지 확인해야 한다.

결론

제로 트러스트 AI 에이전트 설계는 운영 필수 조건이 되고 있다. 좁은신원를 부여하고 실행을 격리하며 도구 호출을 검증하고 감사 증거를 남겨야 한다.