Data Agent Kit에서 쓰기 도구를 강제로 막는 장치는 IAM 거부 정책이다. 그 정책은 MCP 도구 호출에만 걸리고 셸로 나가는 gcloud 명령은 보지 않는다. 에이전트 세션의 gcloud 계정과 셸 허용 여부를 이번 주에 확인한다.
Claude Code나 Codex에 BigQuery를 붙이면 첫 질문은 "DROP TABLE을 치면 어떻게 되나"다. Google이 10월 1일 정식 출시한 Data Agent Kit은 15개가 넘는 Google Data Cloud 서비스를 MCP 도구로 연결하고 Apache 2.0 스킬 37개를 함께 설치한다. 에이전트는 사용자 본인 계정이나 본인이 대리 실행(impersonation)하는 서비스 계정으로 접속한다.
아무것도 바꾸지 않으면 에이전트는 설치한 데이터 엔지니어의 권한을 그대로 쓴다. 삭제 명령과 에이전트 사이의 장치는 둘이고, InfoQ 10월 24일 분석은 둘을 권고와 강제로 나눴다. 두 장치는 덮는 경로가 다르다.
데이터 손실 방지 스킬은 셸 명령까지 다루지만 집행하지 않는다
accidental-data-loss-prevention 스킬 description은 "STOP AND VERIFY"로 시작한다. 되돌릴 수 없는 명령 앞에서 에이전트는 멈추고, 영향을 설명하고, 명시적 동의를 기다려야 한다. 대상은 DROP·TRUNCATE, WHERE 없는 DELETE, gsutil rm·gcloud storage rm, gcloud projects delete, KMS 키 파기다.
목록의 절반이 셸 명령이다. 스킬은 지시문이라 MCP 도구든 터미널이든 경로를 가리지 않는다. 대신 InfoQ가 짚었듯 따르라고 요청한 조언이지 집행되는 통제가 아니다.
스킬 형식도 아직 보안 경계를 정의하지 않는다. Anthropic은 10월 22일 Agent Skills 표준을 Linux Foundation 산하 Agentic AI Foundation에 기부하며 ChatGPT·Cursor·GitHub Copilot을 포함한 70개 넘는 플랫폼이 이 형식을 쓰고, 약 100만 개 스킬이 공개돼 2억 8천만 회 가까이 설치됐다고 밝혔다. 스킬 작성자·설치자용 보안 지침은 일정 없는 로드맵 항목이다. 스킬 구조는 업무 매뉴얼이 설치 파일이 됐다에서 다뤘다.
IAM 거부 정책은 집행하지만 MCP 경로만 검사한다
강제 장치는 IAM이다. Google Cloud 문서는 mcp.googleapis.com/tools.call 권한을 거부하고 조건을 api.getAttribute('mcp.googleapis.com/tool.isReadOnly', false) == false로 거는 정책을 예시로 든다. 읽기 전용 표시가 없는 도구 호출은 HTTP 클라이언트 오류로 실패한다.
같은 문서에 따르면 이 속성은 mcp.tools.call 권한에서만 검사되고, Google Cloud 밖 MCP 서버의 도구는 통제하지 못한다.
셸에서 실행한 gcloud storage rm은 MCP 도구 호출이 아니므로 이 정책의 검사 대상이 아니다.
Claude Code와 Codex는 터미널 명령을 실행하고, Data Agent Kit이 기본 설치된 Cloud Shell의 gcloud는 사용자 계정으로 로그인돼 있다. 권한을 가진 계정이라면 스킬이 경고한 셸 명령을 막는 것은 모델이 지시를 따르는지 하나뿐이다.
| 실행 경로 | 데이터 손실 방지 스킬 | tool.isReadOnly 거부 정책 | 읽기 전용 서비스 계정 |
|---|---|---|---|
| Google Cloud MCP 쓰기 도구 | 멈추라고 요청 | 차단 | 권한 부족으로 실패 |
| 셸의 gcloud·bq·gsutil | 멈추라고 요청 | 검사 안 함 | 셸이 그 계정일 때만 실패 |
| Google Cloud 밖 MCP 서버 | 멈추라고 요청 | 통제 불가 | 해당 없음 |
InfoQ가 인용한 Google Jeff Nelson의 제안은 두 가지다: 읽기 전용 서비스 계정으로 대리 실행하거나, 위 거부 정책을 건다. 두 경로를 함께 덮는 쪽은 앞의 것이다. 권한이 없으면 어느 경로로 오든 삭제가 실패한다. 단 셸의 gcloud도 그 계정이어야 한다.
막힌 도구는 목록에 남고, 타임아웃난 쓰기는 결과를 알 수 없다
거부 정책을 건 뒤에도 tools/list는 쓰기 도구를 그대로 돌려준다. 에이전트는 호출 시점에야 막힌 것을 안다. 막힌 다음 같은 목적을 셸로 다시 시도하는지는 문서가 다루지 않는다. viaSocket의 Ankit Dongre는 InfoQ에서 도구 결과에 멱등성 키·커밋 상태가 없어 타임아웃난 쓰기의 반영 여부를 확인할 수 없다고 지적했다.
가져갈 것
- Data Agent Kit을 쓰는 계정이 운영 데이터셋의
bigquery.tables.delete권한을 갖고 있는가? - 분석용 프로젝트에
mcp.googleapis.com/tools.call을tool.isReadOnly == false조건으로 거부하는 정책을gcloud iam policies create --kind=denypolicies로 붙였는가? - Claude Code·Codex 세션에
gcloud·bq·gsutil셸 실행이 열려 있다면,gcloud auth list의 활성 계정이 사람 계정이 아니라 읽기 전용 서비스 계정인가? - 함께 붙인 Google Cloud 밖 MCP 서버마다 쓰기 도구를 무엇으로 막는지 답할 수 있는가?
- 쓰기를 허용한 프로젝트 런북에 "타임아웃 시 재실행 전 대상 테이블 상태 조회" 단계가 있는가?
안 되는 경우
- 셸 실행을 끄고 Google Cloud MCP 도구만 쓰는 팀은 거부 정책 하나로 쓰기 경로가 닫힌다.
- 문서 예시는 거부 대상을
principalSet://goog/public:all로 둬서 그 프로젝트의 모든 주체가 MCP 쓰기 도구를 못 쓴다. 계획 승인 뒤 리소스를 만드는 그래프 스킬을 쓰는 프로젝트에는 그대로 붙일 수 없다. - 문서는 정책 반영 시간, 조직·폴더 단위 적용 명령,
tool.isReadOnly표시 기준을 밝히지 않는다. 모델이 스킬의 MUST를 얼마나 지키는지 보여 주는 수치도 없다.
이번 주에 바꿀 것은 하나다: 데이터 에이전트를 돌리는 세션의 gcloud 활성 계정을 사람 계정에서 읽기 전용 서비스 계정으로 바꾼다. 에이전트 작업 범위를 IAM으로 옮길 담당자가 아직 없다면 그 질문부터 조녁컴퍼니와 함께 정리하길 권한다. 사업영역 →