Agent Platform Audit Logging: 에이전트·모델 호출을 누가 언제 했는지 남기는 감사 로그 설정

Agent Platform에서 에이전트와 모델이 무엇을 읽고 실행했는지 감사 로그로 남기려면 기본으로 꺼져 있는 Data Access 로그부터 켜야 합니다. 모델 예측, 세션과 메모리 조회, RAG 파일 업로드, 샌드박스 코드 실행이 모두 이 로그에 들어갑니다. 켠 뒤에는 에이전트마다 서비스 계정을 따로 주고 기본 보존 30일인 버킷 밖으로 sink를 걸어 BigQuery에 쌓아야 감사 질문에 답할 수 있습니다.

요약

Google Cloud 문서 ‘Agent Platform audit logging information’은 Gemini Enterprise Agent Platform(Vertex AI의 새 이름, 이하 Agent Platform)이 Cloud Audit Logs(구글 클라우드 공통 감사 로그)에 무엇을 남기는지 정리한 레퍼런스입니다. 감사 로그는 누가, 어느 리소스에, 언제, 무엇을 했는지에 답하는 기록입니다. 문서는 로그를 Admin Activity, Data Access, System Event 세 유형으로 나누고 Agent Platform API의 작업 하나하나가 어느 유형에 기록되는지 표로 정리합니다. 서비스 이름은 aiplatform.googleapis.com, 리소스 유형은 audited_resource 하나입니다. 로그 이름에는 보안 정책이 접근을 막은 기록인 Policy Denied도 나옵니다. 그 밖에 로그 항목 구조, 켜는 법, 열람 역할, 조회와 라우팅을 다룹니다.

에이전트를 운영하는 쪽에서 가장 먼저 볼 것은 기본값입니다. 설정 변경을 남기는 Admin Activity와 시스템이 스스로 한 변경을 남기는 System Event는 항상 기록되고 끌 수 없습니다. 반면 endpoints.predict 같은 모델 예측, memories.retrieve 같은 메모리 조회, sessionEvents.append 같은 세션 기록, sandboxEnvironments.execute 같은 코드 실행은 모두 Data Access에 속합니다. 이 로그는 명시적으로 켜기 전에는 쓰이지 않습니다. 켜지 않으면 누가 에이전트를 배포했는지는 남아도 에이전트가 무엇을 읽고 실행했는지는 남지 않습니다. 문서는 오래 보관하거나 분석하려면 BigQuery·Cloud Storage·Pub/Sub로 로그를 보내고 양이 할당량을 넘으면 Data Access를 빼는 sink를 만들라고 안내합니다. 아래에서는 로그 유형과 메서드 매핑을 풀고 에이전트 호출을 감사할 수 있게 만드는 설정과 2주 점검 계획을 덧붙였습니다.

핵심 메커니즘

Audit Log Types: 기본으로 켜진 셋과 꺼진 하나

Cloud Audit Logs는 기록 대상에 따라 로그를 네 갈래로 나눕니다. Admin Activity는 리소스의 구성이나 메타데이터를 바꾸는 관리 작업입니다. 엔드포인트 생성, 모델 배포(endpoints.deployModel), 튜닝 작업 생성(tuningJobs.create)이 여기에 남습니다. 항상 기록되며 끌 수 없습니다. Data Access는 구성과 메타데이터를 읽는 작업, 그리고 사용자가 넣은 데이터를 읽고 쓰는 작업입니다. 기본으로 꺼져 있으며 예외는 끌 수 없는 BigQuery의 Data Access 로그뿐입니다. System Event는 사람이 직접 하지 않은 자동 구성 변경입니다. Agent Platform 표에 오른 작업은 InstanceVerification.LogEvidence 하나입니다.

네 번째 Policy Denied는 보안 정책 위반으로 사용자나 서비스 계정의 접근을 거부했을 때 남습니다. Cloud Audit Logs 개요 문서에 따르면 기본으로 생성되고 저장 비용이 붙습니다. 끌 수는 없지만 제외 필터로 저장에서 뺄 수 있습니다. 저장 위치도 다릅니다. Admin Activity와 System Event는 _Required 버킷, Data Access와 Policy Denied는 _Default 버킷에 들어갑니다. 가상 예시로, 데이터 과학자가 엔드포인트에 모델을 배포하면 Admin Activity가 남습니다. 상담 에이전트가 그 엔드포인트에 예측을 요청하면 Data Access(DATA_READ)를 켠 경우에만 남습니다.

Data Access Subtypes: ADMIN_READ, DATA_READ, DATA_WRITE

Data Access는 다시 세 하위 유형으로 나뉩니다. ADMIN_READ는 구성을 읽는 get·list 호출입니다(endpoints.get, memories.list, semanticGovernancePolicies.get 등). DATA_READ는 사용자 데이터를 읽는 호출입니다. endpoints.predict를 비롯한 예측 호출과 memories.retrieve, sessionEvents.list, indexEndpoints.findNeighbors가 여기에 있습니다. DATA_WRITE는 사용자 데이터를 쓰는 호출로 sessionEvents.append, ragFiles.upload, sandboxEnvironments.execute가 대표적입니다.

언제 무엇을 켤지는 하위 유형 단위로 정합니다. 에이전트가 무엇을 읽었는지가 궁금하면 DATA_READ, 무엇을 남기고 실행했는지가 궁금하면 DATA_WRITE가 필요합니다. 분류는 이름으로 짐작하지 말고 표에서 메서드별로 확인합니다. 예를 들어 벡터 인덱스의 indexes.create와 indexes.patch는 Admin Activity가 아니라 DATA_WRITE에 있습니다.

Agent Memory · Session · Sandbox: 에이전트 실행이 남기는 로그

표에는 에이전트 실행과 직접 닿는 리소스가 있습니다. sessions·sessionEvents(대화 세션과 이벤트), memories·memoryRevisions(장기 기억과 변경 이력), ragCorpora·ragFiles(RAG 코퍼스와 문서), sandboxEnvironments(코드 실행 샌드박스)입니다. 같은 리소스라도 작업마다 로그 유형이 갈립니다. 메모리를 만들고 고치고 지우는 memories.create·update·delete·generate·purge와 memoryRevisions.rollback은 Admin Activity라 항상 남습니다. 메모리를 꺼내 쓰는 memories.retrieve는 DATA_READ입니다.

이 차이가 감사 범위를 정합니다. Data Access를 끈 상태에서는 기억이 언제 바뀌었는지는 남지만 에이전트가 그 기억을 언제 꺼내 썼는지는 남지 않습니다. 샌드박스도 같습니다. 만들고 지우는 기록(sandboxEnvironments.create·delete·snapshot)은 Admin Activity, 그 안에서 코드를 돌린 기록(sandboxEnvironments.execute)은 DATA_WRITE입니다.

AuditLog Entry: 로그 한 줄에 담기는 필드

감사 로그 한 줄은 LogEntry 객체입니다. logName(어느 로그인지), resource(감사 대상), timestamp(작업 시각), protoPayload(감사 내용)가 핵심 필드입니다. protoPayload에는 @type이 type.googleapis.com/google.cloud.audit.AuditLog인 AuditLog 객체가 들어가며 serviceName이 로그를 쓴 서비스를 가리킵니다. 서비스별 세부는 예전 연동이면 serviceData, 새 연동이면 metadata에 담깁니다. 호출자 IP는 RequestMetadata.caller_ip에 있습니다. 문서는 일부 호출자 신원과 IP가 가려질 수 있다고 적습니다.

가려지는 조건은 Cloud Audit Logs 개요 문서가 설명합니다. 호출자 신원은 AuthenticationInfo에 들어갑니다. 성공한 접근과 모든 쓰기 작업에서는 이메일이 가려지지 않습니다. 권한 거부로 실패한 읽기 호출은 이메일이 가려질 수 있는데, 호출자가 서비스 계정이면 가려지지 않습니다. 구글 내부의 서비스 간 호출은 IP가 private으로 표시됩니다. 에이전트를 서비스 계정으로 돌리면 실패한 시도의 행위자도 남습니다.

Logs Viewer vs Private Logs Viewer: Data Access를 읽는 권한

로그를 읽는 역할은 둘입니다. Logs Viewer(roles/logging.viewer)는 Admin Activity, Policy Denied, System Event를 읽지만 _Default 버킷의 Data Access는 읽지 못합니다. Private Logs Viewer(roles/logging.privateLogViewer)는 Logs Viewer 권한에 _Default 버킷의 Data Access 읽기를 더합니다. 문서는 사용자가 만든 버킷에 비공개 로그를 두면 그 버킷을 읽을 수 있는 사람은 누구나 비공개 로그도 읽는다고 덧붙입니다.

Data Access 로그에는 누가 어느 세션과 메모리, RAG 파일에 손댔는지가 남습니다. 그래서 Private Logs Viewer를 받는 사람과, sink로 로그를 받는 BigQuery 데이터셋의 열람 권한이 그대로 접근 통제 범위가 됩니다.

Viewing and Routing: 보기·보내기·줄이기

콘솔의 Logs Explorer에서는 logName:“cloudaudit.googleapis.com” 쿼리로 전체 감사 로그를 보고 쿼리 빌더에서 activity, data_access, system_event, policy 중 하나로 좁힙니다. 묶어서 분석할 때는 SQL을 쓰는 Log Analytics를 씁니다. gcloud logging read는 프로젝트·폴더·조직·결제 계정 단위 logName 필터를 받습니다. 하루보다 오래된 로그는 —freshness를 붙여 읽습니다. REST로는 Logging API의 entries.list를 호출합니다.

라우팅의 쓰임은 셋입니다. 오래 보관하거나 깊이 검색하려면 Cloud Storage, BigQuery, Pub/Sub로 사본을 보냅니다. 조직 전체를 관리하려면 여러 프로젝트에서 모으는 aggregated sink를 씁니다. Data Access 양이 로그 할당량을 넘으면 그 로그를 빼는 sink로 줄입니다. 가격은 문서에 숫자가 없고 Google Cloud Observability 가격 페이지의 Cloud Logging 항목을 가리킵니다.

통념과 다른 주장

기술 디테일: 에이전트·모델 호출을 감사할 수 있게 만들려면

이 절에서는 문서의 메커니즘을 실제로 돌릴 때 필요한 설정으로 옮겼습니다. 원문에 없는 설정값과 명령은 새로 작성했습니다. 가상 값은 대문자 자리표시자(PROJECT_ID 등)로 표시했습니다.

Data Access를 켜려면(Data Access 하위 유형과 연결) 프로젝트나 폴더, 조직의 IAM 정책에 auditConfigs를 넣습니다. 서비스는 aiplatform.googleapis.com으로 지정하고 auditLogConfigs에 하위 유형(logType)을 하나씩 적습니다. 에이전트 감사가 목적이면 DATA_READ와 DATA_WRITE를 먼저 켭니다. get·list 호출이 많은 ADMIN_READ는 개발 환경에서 하루 양을 본 뒤 정합니다. exemptedMembers(면제 계정)는 대시보드 새로 고침처럼 사람이 아닌 모니터링 계정에만 씁니다. 감사 대상인 에이전트 계정은 면제하지 않습니다. Config Connector를 쓴다면 아래처럼 선언합니다(가상 값).

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMAuditConfig
metadata:
  name: aiplatform-data-access
spec:
  service: aiplatform.googleapis.com
  auditLogConfigs:
    - logType: DATA_READ
    - logType: DATA_WRITE
    - logType: ADMIN_READ
      exemptedMembers:
        - serviceAccount:MONITORING_SA@PROJECT_ID.iam.gserviceaccount.com
  resourceRef:
    kind: Project
    external: projects/PROJECT_ID

에이전트를 행위자 단위로 구분하려면(AuditLog Entry와 연결) 에이전트마다 서비스 계정을 하나씩 줍니다. 감사 로그가 가르는 행위자 단위는 호출한 계정이므로, 여러 에이전트가 한 계정을 나눠 쓰면 로그만으로는 어느 에이전트가 읽었는지 알 수 없습니다. 이름은 agent-claims-intake@PROJECT_ID.iam.gserviceaccount.com처럼 에이전트 이름이 드러나게 짓고 에이전트 목록과 계정의 대응표를 따로 관리합니다. 서비스 계정은 권한 거부로 실패한 읽기 호출에서도 이메일이 가려지지 않으므로, 막힌 시도의 행위자도 남습니다.

BigQuery에 쌓아 질문하려면(Viewing and Routing과 연결) 감사 로그만 고르는 sink를 만들고 BigQuery 데이터셋을 목적지로 지정합니다. 아래 명령은 문서의 라우팅 안내를 옮긴 가상 예시입니다. 만든 뒤에는 명령 결과에 나오는 sink의 writer identity(쓰기 계정)에 데이터셋의 BigQuery Data Editor 역할을 줍니다. 여러 프로젝트에 에이전트가 흩어져 있으면 조직이나 폴더에 aggregated sink를 겁니다.

gcloud logging sinks create aiplatform-audit-bq \
  bigquery.googleapis.com/projects/PROJECT_ID/datasets/ai_audit \
  --log-filter='logName:"cloudaudit.googleapis.com" AND protoPayload.serviceName="aiplatform.googleapis.com"' \
  --use-partitioned-tables

sink를 걸기 전에는 Logs Explorer에서 protoPayload.serviceName=“aiplatform.googleapis.com” AND logName:“data_access” AND protoPayload.authenticationInfo.principalEmail=“AGENT_SA_EMAIL” 같은 필터로 에이전트 하나의 기록을 먼저 확인합니다. 쌓인 뒤에는 지난 7일 동안 어느 계정이 어떤 메서드를 몇 번 불렀는지 한 번에 봅니다. 테이블과 열 이름은 BigQuery 내보내기 스키마를 따른 가상 예시이니, 데이터셋에 생긴 실제 이름으로 바꿉니다.

SELECT
  protopayload_auditlog.authenticationInfo.principalEmail AS caller,
  protopayload_auditlog.methodName AS method,
  COUNT(*) AS calls
FROM `PROJECT_ID.ai_audit.cloudaudit_googleapis_com_data_access`
WHERE protopayload_auditlog.serviceName = 'aiplatform.googleapis.com'
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
GROUP BY caller, method
ORDER BY calls DESC

보존 기간과 비용을 맞추려면(Audit Log Types와 연결) 버킷별 보존부터 확인합니다. Cloud Logging 문서에 따르면 _Required는 400일 고정이고 _Default는 기본 30일이며 바꿀 수 있습니다. Data Access는 _Default에 들어가므로 손대지 않으면 30일 뒤 사라집니다. 사내 감사 주기가 1년이라면 _Default 보존을 늘리거나 BigQuery sink 쪽 테이블 만료를 그 기간에 맞춥니다. Cloud Audit Logs 개요는 Data Access가 많은 양을 만들고 로그 요금을 늘릴 수 있다고 경고합니다. 개발 환경의 하루 로그 양을 운영 호출량으로 환산해 월 비용을 미리 계산합니다.

프롬프트와 응답 본문을 다루려면(AuditLog Entry와 연결) 감사 로그가 무엇까지 담는지 테스트로 확인합니다. Agent Platform 감사 로그 문서는 protoPayload에 감사 정보가 들어간다고만 적을 뿐 요청·응답 본문을 남기는지는 밝히지 않습니다. 대화 내용을 보관해야 한다면 같은 문서 체계에 있는 request-response logging(요청·응답을 BigQuery에 남기는 별도 기능) 문서를 따로 검토합니다. 테스트 호출 뒤 protoPayload에 본문 일부라도 보이면, 그 로그를 읽는 Private Logs Viewer 대상과 BigQuery 열람 권한을 개인정보 기준으로 다시 정합니다.

메서드 이름을 확정하려면(Agent Memory · Session · Sandbox와 연결) 개발 프로젝트에서 직접 호출해 봅니다. 문서의 표는 endpoints.predict처럼 리소스와 메서드를 짧게 적습니다. 로그의 methodName 필드는 다른 형식으로 찍힐 수 있습니다. 우리 에이전트가 쓰는 Gemini 생성 호출이 표의 어느 행에 해당하는지도 이 단계에서 확인합니다. 에이전트 경로마다 한 번씩 실행한 뒤 Logs Explorer에서 methodName과 principalEmail 목록을 뽑아 감사 대상 메서드표를 만들고 그 표를 운영 sink 필터와 경보 규칙에 씁니다. 호출했는데 로그가 보이지 않으면 auditConfigs의 서비스 이름, _Default로 가는 sink의 제외 필터, 조회 계정의 Private Logs Viewer 역할을 차례로 확인합니다.

현업 실행 디테일: 누가, 언제, 무엇을

역할부터 나눕니다(예시).

역할	맡는 일	산출물
CISO · 보안팀	감사 범위(어느 하위 유형을 켤지)와 보존 기간 승인, 열람 권한자 지정	감사 로그 정책 1쪽
클라우드 플랫폼팀	auditConfigs 설정, sink와 BigQuery 데이터셋, 버킷 보존 변경	설정 변경 기록, sink 목록
AX 추진 · 에이전트 개발팀	에이전트별 서비스 계정 분리, 경로별 테스트 호출	에이전트-계정 대응표, 감사 대상 메서드표
FinOps	로그 양과 요금 측정, 상한 설정	월 로그 비용 추정
내부감사 · 법무	감사 질문 목록 작성, 리허설 결과 확인	질문별 답 소요 시간

시작 전에 준비할 것은 넷입니다. 에이전트가 도는 프로젝트·폴더 목록, 운영 중인 에이전트와 각 에이전트가 쓰는 서비스 계정 목록, 현재 IAM 정책의 auditConfigs 상태(gcloud projects get-iam-policy로 내려받음), 사내 규정이 요구하는 로그 보존 기간입니다.

일정은 영업일 10일을 잡습니다(가상 예시). 1~2일차에 프로젝트별 Data Access 상태와 서비스 계정 공유 여부를 표로 만듭니다. 3~4일차에는 개발 프로젝트에서 DATA_READ와 DATA_WRITE를 켜고 에이전트 경로마다 한 번씩 호출해 감사 대상 메서드표를 만듭니다. 5~7일차에는 공유 계정을 에이전트별로 쪼개고 BigQuery sink와 보존 기간을 운영에 적용합니다. 8~10일차에는 아래 질문으로 리허설하고 하루 로그 양과 비용을 잽니다.

리허설에서 던질 질문입니다.

1. 지난 7일 동안 고객 세션(sessions.get, sessionEvents.list)을 읽은 계정은 누구인가?
2. 특정 RAG 코퍼스에 파일을 올리거나 지운 계정(ragFiles.upload, ragFiles.delete)과 시각은?
3. 샌드박스에서 코드를 실행한(sandboxEnvironments.execute) 에이전트와 그 횟수는?
4. 장기 기억을 지우거나 되돌린 기록(memories.purge, memoryRevisions.rollback)은?
5. 정책 위반으로 거부된 Agent Platform 호출(policy 로그)은 어느 계정에서 왔나?

진행 판정 기준(예시)은 이렇습니다. 다섯 질문 모두 BigQuery 쿼리 하나로 10분 안에 답하면 통과입니다. 운영 에이전트 호출의 principalEmail이 모두 에이전트 전용 계정이어야 합니다. 공유 계정이 하나라도 남으면 5~7일차로 돌아갑니다. 측정한 로그 비용이 FinOps가 정한 상한을 넘으면 ADMIN_READ를 끄거나 면제 계정을 조정한 뒤 다시 잽니다. 최종 승인은 CISO가 감사 로그 정책 1쪽에 서명하는 것으로 끝냅니다.

AX 적용 순서는 고객 데이터를 만지는 에이전트부터 잡습니다. 상담, 청구 접수, 인사 문의처럼 세션과 메모리에 개인정보가 쌓이는 에이전트에 먼저 Data Access와 계정 분리를 적용합니다. 내부 문서 요약 같은 저위험 에이전트는 다음 분기로 미룹니다. 에이전트 레지스트리를 이미 운영한다면 에이전트 ID와 서비스 계정, 감사 대상 메서드표를 한 행에 묶어 두는 편이 낫습니다. 신규 에이전트 승인 때 로그 설정 확인이 체크리스트 한 줄로 줄어듭니다. SIEM(보안 관제 시스템)을 쓰는 조직은 Pub/Sub sink로 같은 로그를 관제로 넘겨, 에이전트 계정의 비정상 호출을 기존 보안 경보 체계 안에서 봅니다.

원문 사례

항목	원문 내용
문서	Agent Platform audit logging information (Google Cloud 문서, Gemini Enterprise Agent Platform)
서비스 이름 · 리소스 유형	aiplatform.googleapis.com · audited_resource
로그 유형	Admin Activity(항상 기록), Data Access(기본 꺼짐, BigQuery만 예외), System Event(항상 기록), 로그 이름에 Policy Denied(policy) 포함
작업 표 분류	Admin Activity, Data Access(ADMIN_READ · DATA_READ · DATA_WRITE), System Event
에이전트 관련 Admin Activity	memories.create · delete · generate · purge · update, memoryRevisions.rollback, ragCorpora.create · delete, sandboxEnvironments.create · delete · snapshot, semanticGovernancePolicies.create · update · delete
에이전트 관련 DATA_READ	endpoints.predict · rawPredict · explain · predictLongRunning, memories.retrieve, sessions.get · list, sessionEvents.list, ragFiles.get · list, indexEndpoints.findNeighbors
에이전트 관련 DATA_WRITE	sessions.create · update · delete, sessionEvents.append, ragFiles.import · upload · delete, sandboxEnvironments.execute, onlineEvaluators.create · update · delete
System Event 작업	InstanceVerification.LogEvidence
로그 항목 구조	LogEntry의 protoPayload에 AuditLog, 호출자 IP는 RequestMetadata.caller_ip
열람 역할	roles/logging.viewer, roles/logging.privateLogViewer(Data Access 읽기)
조회 수단	Logs Explorer · Log Analytics, gcloud logging read(—freshness), Logging API entries.list
라우팅	Cloud Storage · BigQuery · Pub/Sub, aggregated sink, Data Access 제외 sink
가격 · 보존	가격은 Observability 가격 페이지로 안내, 보존 기간은 이 문서에 없음

핵심 개념

Cloud Audit Logs

구글 클라우드 서비스가 누가 무엇을 했는지 남기는 공통 감사 로그 체계.

audited_resource

Agent Platform 감사 로그가 모두 쓰는 리소스 유형. 필터에서 리소스를 고를 때 씁니다.

_Required · _Default

Cloud Logging이 프로젝트마다 만드는 기본 로그 버킷. 앞쪽은 400일 고정, 뒤쪽은 기본 30일입니다.

sink

조건에 맞는 로그를 다른 버킷이나 BigQuery·Cloud Storage·Pub/Sub로 보내는 라우팅 규칙.

aggregated sink

조직이나 폴더 아래 여러 프로젝트의 로그를 한곳으로 모으는 sink.

exemptedMembers

Data Access 로그를 켠 상태에서 특정 계정의 호출만 기록하지 않게 빼는 설정.

Log Analytics

Cloud Logging 안에서 로그를 SQL로 묶어 분석하는 기능.

request-response logging

모델 호출의 요청과 응답을 BigQuery에 남기는 Agent Platform의 별도 기능. 감사 로그와는 다른 문서에서 다룹니다.

내 메모

TODO: 내 생각 추가

원문: Google Cloud, ‘Agent Platform audit logging information’ (Gemini Enterprise Agent Platform 문서, 한국어판 ‘Agent Platform 감사 로깅 정보’). 서비스 이름, 로그 유형, 메서드 이름은 영어판 표기를 따랐습니다. 요약과 핵심 메커니즘은 문서 내용을 AX Review가 다시 정리했습니다. 기술·현업 실행 디테일과 명령·쿼리 예시, 인포그래픽, 표는 새로 작성했습니다. 메커니즘 보강에는 Cloud Audit Logs 개요(로그 유형별 동작, 호출자 신원 가림 규칙), Cloud Logging ‘Store log entries’(버킷별 보존 기간), Config Connector IAMAuditConfig 레퍼런스(auditConfigs 필드)를 1차 출처로 썼습니다. 전체 메서드 표는 원문에서 볼 수 있습니다.