Gemini Enterprise 를 이용한 사내 AI 플랫폼 구축 - ③ 프롬프트 공격과 폭주하는 에이전트

③ 프롬프트 공격과 폭주하는 에이전트: AI의 말과 행동을 검사하고 지켜본다

시리즈 안내 | ① 권한 탈취 → ② 데이터 유출 → ③ 프롬프트 공격과 폭주하는 에이전트

들어가며: 문을 잠가도 내용은 들어온다

허깅페이스 침입의 시작점은 업로드된 악성 데이터셋이었습니다. 데이터 처리 파이프라인의 템플릿 인젝션 취약점을 노린 입력 하나가 서버에서 코드로 실행됐습니다. 그리고 에이전트는 약 17,600건의 행동을 이어 갔지만, 그 흐름은 사건이 끝난 뒤에야 로그로 재구성됐습니다.

사내 AI 플랫폼에서도 같은 일이 벌어질 수 있습니다. 정당한 사용자가 정당한 경로로 보낸 프롬프트나 문서 안에 지시를 조작하는 공격이 숨어 있거나, 모델이 정당한 데이터를 부적절하게 말하는 경우입니다. 요청이 정상 경로로 들어오고 데이터가 경계 안에 있으니 IAM도 VPC-SC도 막지 못합니다. 문제는 내용과 행동입니다. 마지막 회에서는 AI의 입출력을 검사하는 Model Armor와, 에이전트의 행동을 지켜보는 관측을 다룹니다.

1. Model Armor: 프롬프트와 응답을 실시간으로 검사한다

Model Armor는 LLM의 프롬프트는 모델에 가기 전에, 응답은 사용자에게 가기 전에 검사하는 Google Cloud 서비스입니다. 특정 모델이나 클라우드에 종속되지 않아 어떤 모델 앞에도 둘 수 있고, 문서·이미지 검사와 한국어를 포함한 여러 언어를 지원합니다.

<그림 1. Model Armor의 프롬프트·응답 검사 흐름 >

필터	하는 일
프롬프트 인젝션·탈옥 탐지	AI 지시를 조작하거나 안전 제약을 우회하려는 시도를 무력화
민감 정보 보호(SDP)	개인정보와 기밀 데이터의 노출 탐지
악성 URL 탐지	악성코드·피싱 사이트 링크 차단
책임 있는 AI 필터	위험·성적·괴롭힘·혐오 콘텐츠 차단

2. 템플릿 설계: 정책을 코드가 아니라 설정으로

Model Armor의 정책 단위는 필터와 임계값을 묶은 템플릿입니다. 설계에서 정할 것은 두 가지입니다.

신뢰도 임계값: High는 확실한 위반만 잡아 사용자 경험을 지키고, Medium and above는 일반 기업 앱의 표준이며, Low and above는 오탐이 많아 미탐이 치명적인 항목에만 신중히 씁니다. 공식 문서는 Gemini Enterprise에서 프롬프트 인젝션·탈옥 탐지의 오탐을 피하도록 High를 제안합니다.
입력과 출력 템플릿 분리: 입력 템플릿은 인젝션·탈옥, 민감 데이터 업로드, 악성 URL·파일을 막고, 출력 템플릿은 민감 정보 유출, 유해 콘텐츠, 악성 URL 반환을 막습니다. 출력 쪽 프롬프트 인젝션 탐지는 끄는 것이 좋습니다. 공격은 입력에서 시작되므로 응답에서 탐지하면 오탐만 늘어납니다.

3. 도입 순서: 처음부터 막지 않는다

입출력 통제의 가장 흔한 실패는 정상 업무가 차단되어 사용자가 플랫폼을 외면하는 것입니다. 그래서 세 단계로 도입합니다.

Inspect only: 위반을 Cloud Logging에 기록만 하고 차단하지 않습니다.
조정: Security Command Center의 AI Protection 대시보드로 탐지 현황을 보며 임계값을 조정합니다.
Inspect and block: 충분히 검증되면 차단으로 전환합니다.

Gemini Enterprise에 연결하려면 템플릿을 앱과 같은 프로젝트, 같은 위치에 만들고(Model Armor Admin 역할 필요), 앱의 Configurations > Assistant에서 프롬프트용·응답용 템플릿을 지정합니다. 주의할 점이 두 가지 있습니다. 검사 때문에 응답 지연이 늘 수 있으니 2회의 타임아웃 설정과 함께 점검하세요. 그리고 Gemini Enterprise 연동 문서는 Model Armor가 PII를 제거하거나 마스킹하지 않는다고 명시하므로, 이 연동에서는 탐지 후 허용 또는 차단만 가능하다고 보고 설계하는 편이 안전합니다. 프로젝트마다 기준이 들쭉날쭉하지 않도록 최소 임계값을 정하는 플로어 설정(Floor setting)도 활용하세요.

4. 행동하는 AI에는 사람의 승인을 둔다

Gemini Enterprise의 액션은 Calendar 일정 생성이나 메일 발송처럼 데이터 소스에 직접 쓰기를 합니다. 이때 어시스턴트는 초안을 먼저 보여주고, 사용자가 수정한 뒤 OAuth로 권한을 허용하고 실행을 확인해야 실제로 처리됩니다. 마지막 확인을 사람이 하는 구조입니다. 2회에서 본 것처럼 VPC-SC 환경에서는 액션 자체가 기본 차단되어, 필요한 액션만 허용 목록으로 엽니다.

5. 에이전트를 올릴 때 챙길 통제

Gemini Enterprise는 만드는 사람의 역량에 따라 세 가지 경로를 제공합니다. 현업이 직접 만드는 노코드 Agent Designer, 고객 상담 흐름에 맞는 로우코드 CX Agent Studio, 복잡한 로직을 코드로 구현하는 ADK입니다. ADK 에이전트는 개발자가 Agent Runtime에 배포하고(adk deploy), 관리자가 앱의 Agents > Add agent에서 등록하면, 직원이 Agent Gallery에서 사용합니다.

<그림 2. 개발자-관리자-소비자 에이전트>

설명은 호출 조건입니다. LLM은 등록 시 입력한 설명으로 에이전트를 호출할지 판단합니다. 무엇을 하고 어떤 질문에 써야 하는지 구체적으로 적어야 엉뚱한 호출이 줄어듭니다.
플랫폼이 지켜 주는 것과 개발자가 챙길 것을 구분합니다. 앱과 Agent Runtime의 위치가 일치해야 하고, VPC-SC를 준수해야 하며, 직접 만든 ADK 에이전트에는 Model Armor를 개발자가 코드에서 REST API로 구성해야 합니다.

6. 지켜본다: 행동의 궤적을 관측한다

에이전트는 비결정적이고, 내부에서는 여러 LLM 호출과 도구 사용이 연쇄적으로 일어납니다. CSA는 허깅페이스 사건의 교훈으로 개별 행동이 아니라 행동의 궤적(trajectory)을 모니터링하라고 권했습니다. Gemini Enterprise에서는 콘솔의 구성 > 관측성 탭에서 두 가지를 켭니다.

설정	수집되는 것
OpenTelemetry 트레이스·로그 계측	트레이스, 스팬, 스팬 로그, 메트릭
프롬프트 입력·응답 출력 로깅	Cloud Logging에 프롬프트와 응답 전문

두 번째 설정은 주의가 필요합니다. 프롬프트와 응답이 그대로 기록되어 PII를 포함한 민감 정보가 로그에 남으므로, 로그 접근을 승인된 인원으로 제한하세요.

에이전트 내부: 실행 흐름(DAG)의 LLM 호출과 도구 사용을 단계별 트레이스로 보고, 모든 호출의 감사 로그를 남깁니다.
보안: AI Protection 대시보드로 Model Armor 탐지 현황을 보고 임계값을 조정합니다.
이상 징후: Metrics Explorer와 Trace Explorer의 지표에 알림 정책을 걸어, 평소와 다른 호출 급증이나 오류를 사건이 끝나기 전에 받습니다.
도입률과 비용: Analytics의 결과 없는 검색어 Top 10은 다음에 연결할 데이터의 힌트이고, Cloud Billing으로 지출 추세를 봅니다.

<그림 3. VPC Service Controls를 적용한 구성 >

시리즈를 마치며

AI가 스스로 해킹하는 사건은 더 이상 가정이 아닙니다. 하지만 그 사건이 드러낸 빈틈은 익숙한 것들이었습니다. 넓은 권한, 열린 출구, 검사되지 않은 입력, 지켜보지 않은 행동. Gemini Enterprise로 사내 AI 플랫폼을 세운다면 이 세 회에서 다룬 방어선을 순서대로 쌓으면 됩니다.

권한 탈취: 역할 분리, 앱 단위 접근, 단기 토큰(WIF), 원본 시스템의 권한 집행
데이터 유출: 신뢰도 순서의 연결, 기본 차단된 MCP·액션, VPC Service Controls
프롬프트 공격과 폭주: Model Armor, 사람의 승인, 궤적 관측

플랫폼은 배포로 끝나지 않고 관측 → 사용자 피드백 → 새 에이전트 → 다시 관측의 순환으로 이어집니다. 그리고 기술만큼 중요한 것은 처음부터 보안·네트워크 팀과 함께 설계하는 것입니다.

참고 공식 문서

자세한 내용이 궁금하시다면, 메가존소프트 문의포탈을 통해 궁금한 부분을 남겨주세요.

Gemini Enterprise 를 이용한 사내 AI 플랫폼 구축 – ③ 프롬프트 공격과 폭주하는 에이전트