에이전트 레지스트리에 등록됐는데, 왜 MCP 도구 호출 권한은 따로 실패할까? 6칸 identity-resolution 영수증

읽는 시간 약 9분 · 등록 정보와 실제 호출 권한을 분리해 확인하는 운영 가이드

핵심 요약

• Registry에 보이는 URN은 검색·발견용입니다. Google Cloud 문서는 이 URN을 IAM 바인딩, 인증 헤더, Agent Gateway 경로 규칙의 대체물로 쓰지 않도록 구분합니다.
• 정책은 resource name을, 호출 인증·감사는 caller principal을 확인합니다. 실제 실행 환경은 runtime reference로 별도 대조해야 합니다.
• MCP server 자체에 IAM principal이 있다고 가정하지 마세요. Google Cloud Agent Registry 문서에서는 MCP server가 요청에 응답하고, 도구 호출 권한은 호출하는 agent principal을 기준으로 설명합니다.
• 성공 테스트 하나는 충분하지 않습니다. 기대한 제한 principal의 읽기 전용 허용과 승인된 저권한 테스트 주체의 거부를 각각 확인하고, 토큰이나 고객 데이터를 증거에 남기지 마세요.
• 이 글의 6칸 영수증은 FLOWIT이 제안하는 운영 점검표입니다. Google Cloud가 요구하는 공식 인증 절차나 안전 보증으로 보시면 안 됩니다.

목차

1. 발견과 권한은 다른 단계입니다
2. Google Cloud Agent Registry의 네 계층
3. 등록에서 MCP 도구 호출까지 어디서 끊기나요?
4. 배포 전에 채우는 6칸 영수증
5. 확대·보류·회수 판단표
6. 가상 시나리오: 허용 1건, 거부 1건
7. 운영 부담을 줄이는 적용 순서
8. 자주 묻는 질문
9. 참고 자료

발견과 권한은 다른 단계입니다

Agent Registry가 agent나 MCP server를 찾아 보여준다는 것은 카탈로그에서 해당 구성요소를 발견했다는 뜻입니다. 이것만으로 특정 도구의 기반 서비스가 호출자를 허가했다거나, 실제 workload가 예상한 환경에서 실행된다는 사실까지 입증되지는 않습니다.

Google Cloud 문서는 등록 식별자와 resource name, agent principal, runtime reference를 목적별로 나눕니다. 또한 발견한 도구를 호출할 때 underlying Google Cloud 서비스에 필요한 IAM 권한이 별도로 있을 수 있다고 안내합니다. 따라서 “검색된다”와 “이 주체가 이 대상에 이 경로로 접근할 수 있다”를 서로 다른 검증 질문으로 다루셔야 합니다. Google Cloud의 식별자 설명과 도구·리소스 인증 문서가 이 차이를 설명합니다.

이 구분은 처음 설치할 때만 필요한 절차가 아닙니다. 재등록, 정책 변경, agent identity 전환, runtime 이동 같은 변경이 있었다면 기존 연결 기록이 지금도 유효한지 다시 확인해야 합니다. 설치물의 출처와 훅을 검토하는 구성요소 설치 수용 게이트와도 역할이 다릅니다. 설치 검증을 통과했다고 등록 뒤의 호출 주체와 정책 대상까지 자동으로 맞는 것은 아닙니다.

Google Cloud Agent Registry의 네 계층

네 값은 이름만 다른 동의어가 아닙니다. 각각 답하는 질문과 확인할 시스템이 다릅니다. Google Cloud의 Identity and identifiers 문서를 기준으로 아래처럼 분리해 보세요.

표가 좁은 화면에서 잘리지 않도록 좌우로 이동해 확인해 주세요.

URN은 안정적인 발견 키이지 실행 권한 증거가 아닙니다. 공식 문서에 따르면 registry identifier는 등록 구성요소를 검색·필터링하기 위한 논리적 URN이며 runtime governance 용도로 쓰이지 않습니다. 반면 resource name은 IAM 정책 바인딩이나 Agent Gateway 등 downstream 정책에서 대상으로 삼는 값입니다.

Agent principal은 caller의 인증·권한·감사와 연결됩니다. Google 문서는 Google Cloud에서 실행되는 agent의 SPIFFE ID 같은 신원과 외부 agent의 service account 같은 신원을 예로 듭니다. 다만 실제 적용 가능한 신원 방식은 사용 중인 실행 환경과 인증 모델에 따라 확인해야 합니다. 마지막으로 runtime reference는 compute 또는 인프라 경로를 담는 별도 값이며, 호출자가 누구인지 자체를 대신 설명하지 않습니다.

그리고 Google Cloud Agent Registry 범위에서는 중요한 예외가 하나 있습니다. MCP server는 요청에 응답하는 구성요소이며 IAM principal을 갖지 않는다고 문서가 명시합니다. MCP tool 호출 권한은 그 요청을 내는 agent principal을 기준으로 확인합니다. 이를 놓치면 “서버 principal에 권한을 줬다”는 잘못된 운영 메모가 생길 수 있습니다.

등록에서 MCP 도구 호출까지 어디서 끊기나요?

실제 흐름은 아래 네 질문으로 나눠 보면 막힌 지점을 좁히기 쉽습니다.

1. 발견: 올바른 agent나 MCP server의 registry identifier를 찾았나요? 비슷한 이름의 다른 환경이나 endpoint를 고른 것은 아닌가요?
2. 정책 대상: 현재 정책이 가리키는 resource name이 의도한 등록 리소스와 일치하나요? 정책이 governance project 쪽 리소스를 가리키는지, underlying 서비스 권한과 혼동하지 않았는지도 확인하세요.
3. 호출자: 실제 요청이 agent 자신의 identity로 나가는지, 사용자 위임 권한으로 나가는지, 외부 도구용 custom header 경로인지 분명한가요? 이 경로들은 서로 같은 설정이 아닙니다.
4. 실행 경로: 기록된 runtime reference가 현재 workload가 있는 인프라와 맞나요? 배포 위치나 네트워크 경로가 달라졌다면 기존 연결을 그대로 신뢰하지 마세요.

여기서 Registry API 조회 권한과 도구가 사용하는 기반 서비스의 권한을 분리해야 합니다. Google Cloud 인증 문서는 underlying 서비스를 사용하는 데 필요한 IAM 권한을 별도로 안내하고, own identity·delegated access·custom header의 경로도 나눠 설명합니다. API 목록 조회가 성공했더라도 실제 MCP 도구 호출은 다른 권한 조건에서 실패할 수 있습니다.

또한 Agent Identity의 역할과 Registry의 카탈로그 역할도 같지 않습니다. Google Cloud IAM의 Agent Identity 개요는 agent identity와 사용자 위임 권한의 구분, Agent Registry와 Agent Gateway의 서로 다른 역할을 설명합니다. 일반 권한 등급을 설계할 때는 AI 에이전트 권한 설계를, 호출 직전의 승인 경계는 도구 호출 승인 게이트를 함께 보시면 연결 지점이 더 분명해집니다.

배포 전에 채우는 6칸 identity-resolution 영수증

아래 영수증은 배포 전후 비교와 담당자 인계를 돕기 위해 FLOWIT이 제안하는 실무 기록입니다. Google Cloud 제품의 내장 기능이나 필수 준수 양식은 아닙니다. 값은 실제 계정·프로젝트·주체를 넣기 전에 각 환경에서 확인하고, 외부로 공유하는 사본에는 민감한 식별자를 제거하세요.

표가 좁은 화면에서 잘리지 않도록 좌우로 이동해 확인해 주세요.

실제 값을 적을 때는 Registry URN과 resource name을 한 칸에 이어 붙이지 마세요. principal의 전체 token이나 secret을 복사해 기록할 필요도 없습니다. 허가 판단에 필요한 식별 정보와 결과만 남기고, 민감한 자격증명은 로그·영수증·스크린샷에 포함하지 않는 편이 안전합니다.

확대·보류·회수 판단표

테스트 결과는 “성공했다” 한 줄로 끝내지 말고 예상 결과와 실제 결과를 함께 봐야 합니다. 다음 기준은 FLOWIT의 보수적인 운영 제안이며, 조직의 승인 정책과 테스트 환경 안전 기준을 우선 적용하세요.

표가 좁은 화면에서 잘리지 않도록 좌우로 이동해 확인해 주세요.

예상하지 못한 허용은 권한 경계가 생각보다 넓을 수 있다는 신호이므로 즉시 범위를 멈추고 확인해야 합니다. 예상한 허용이 거부되는 경우도 자동으로 권한을 더 주기보다 호출 principal, 대상 resource, underlying 서비스 권한을 한 번에 하나씩 대조하세요.

가상 시나리오: 허용 1건, 거부 1건

아래는 절차를 설명하기 위한 가상 예시이며, 실제 Google Cloud 계정의 실행 결과가 아닙니다. 한 팀이 등록된 MCP server의 읽기 전용 목록 조회를 제한된 시험 환경에서 확인한다고 가정해 보겠습니다. 프로젝트 번호, 실제 principal, endpoint, token은 기재하지 않습니다.

1. 먼저 Registry에서 대상 MCP server를 식별하고, 별도로 해당 등록 리소스의 resource name과 underlying 서비스에 적용된 정책 위치를 기록합니다.
2. 호출이 agent 자신의 identity로 나가는지, 사용자의 위임 권한으로 나가는지 확인합니다. MCP server 자체에 IAM principal을 붙이는 것으로 가정하지 않습니다.
3. 현재 runtime reference를 시험 배포 환경과 대조하고, tool이 조회만 수행하는지 확인합니다. 조회 대상은 민감하지 않은 테스트 데이터로 한정합니다.
4. 승인된 제한 principal로 읽기 전용 목록 조회를 실행해 기대한 허용 결과가 나오는지 확인합니다.
5. 동일한 격리 환경에서 권한이 없는 것으로 명시된 테스트 principal의 결과가 거부되는지도 확인합니다. 임의의 실제 사용자나 운영 대상에 대한 무단 접근 시도는 하지 않습니다.

두 결과가 모두 기대와 일치해도, 그것은 해당 주체·대상·권한 범위·시점의 테스트 결과일 뿐 모든 도구가 안전하거나 모든 쓰기 작업이 허가됐다는 증거는 아닙니다. 확인한 범위를 영수증에 남기고, 쓰기 도구는 별도의 승인·정책 검토가 끝날 때까지 열지 않는 편이 좋습니다. 허용·거부 결과를 실제로 확보하지 못했다면 성공으로 간주하지 말고 보류하세요.

운영 부담을 줄이는 적용 순서

이 점검의 실무 가치는 새 문서를 하나 더 만드는 데 있지 않습니다. 배포가 바뀐 뒤 “어떤 값을 다시 봐야 하고, 누구에게 확인해야 하는지”를 빠르게 좁히는 데 있습니다. 특히 여러 팀이 같은 MCP server나 agent를 공유하면 요청 주체가 뒤섞이기 쉽기 때문에, principal과 정책 대상을 분리해 기록하면 원인 분석의 불필요한 왕복을 줄일 수 있습니다.

• 비용: 승인된 최소 조회 작업만 시험하고, 확인 가능한 운영 증거만 남깁니다. 반복되는 디버깅을 줄이되 더 넓은 권한을 편의상 부여하지 않습니다.
• 권한: Registry 조회 권한, underlying tool 서비스 권한, agent 자신의 identity, 사용자 위임 권한을 각각 구분합니다.
• 신뢰성: 허용뿐 아니라 기대된 거부도 확인합니다. 한쪽 결과가 없으면 검증이 완성된 것으로 보지 않습니다.
• 운영: resource·principal·runtime의 변경 담당자를 적고, 어느 변경부터 재확인할지 팀 안에서 합의합니다.
• 품질: 검증 증거와 실제 배포 상태가 같은 revision·환경을 가리키는지 확인합니다. 값이 오래됐거나 재조회할 수 없다면 새 영수증으로 교체합니다.

runtime reference를 확인한 뒤에는 실제 네트워크 목적과 egress 경로를 정리하는 agent egress 연결 계약으로 이어갈 수 있습니다. 검색·발견 결과의 품질과 접근 권한을 혼동하지 않으려면 도구 discovery 품질 카드도 참고해 보세요. 발견이 잘 된다는 사실은 권한 허용이나 실제 경로 검증을 대신하지 않습니다.

작게 시작할 때의 기준: 대표 구성요소 하나, 읽기 전용 작업 하나, 승인된 시험 환경 하나부터 receipt를 작성해 보세요. 여섯 칸이 비어 있지 않고 예상한 허용·거부를 모두 확인한 뒤에만 같은 절차를 다른 구성요소로 확장하면 됩니다.

자주 묻는 질문

Registry URN을 IAM 바인딩이나 Gateway 경로 규칙에 넣으면 안 되나요?

Google Cloud의 Agent Registry 문서는 registry URN을 발견·검색용 식별자로 구분하고, IAM 바인딩이나 Agent Gateway 경로 규칙에는 해당 리소스의 resource name 등 목적에 맞는 값을 사용하도록 설명합니다. 실제 정책 필드는 적용하는 서비스 문서를 기준으로 확인해 주세요.

MCP server 자체에도 agent principal이 있나요?

Google Cloud Agent Registry 문서 범위에서는 MCP server는 요청에 응답하는 구성요소이며 IAM principal을 갖지 않습니다. MCP tool 호출 권한은 호출하는 agent principal을 기준으로 확인합니다. 다른 제품이나 배포 구조까지 같은 동작이라고 일반화하지는 마세요.

agent 자신의 identity와 사용자의 위임 권한은 같은 것인가요?

같지 않습니다. Google Cloud Agent Identity 문서는 agent가 자체 권한으로 동작하는 방식과 최종 사용자를 대신해 접근하는 위임 방식을 구분합니다. 어느 모델을 쓰는지, downstream 서비스가 실제로 어떤 주체를 검증하는지 호출 경로별로 확인하셔야 합니다.

읽기 전용 호출 한 번이 성공하면 범위를 넓혀도 되나요?

그 결과만으로는 부족합니다. 성공은 시험한 주체·대상·권한·환경에서 해당 읽기 작업이 동작했다는 뜻입니다. 승인된 저권한 주체의 기대된 거부까지 확인하고, 쓰기 범위는 별도 승인과 검토가 끝나기 전까지 추가하지 마세요.

참고 자료

1. Google Cloud, “Identity and identifiers | Agent Registry” — discovery URN, resource name, agent principal, runtime reference의 역할을 구분합니다. 특히 MCP server의 principal 여부와 각 식별 계층의 사용 위치를 확인하는 근거입니다.
2. Google Cloud, “Authenticate to tools and resources | Agent Registry” — 발견한 도구 호출과 underlying Google Cloud 서비스 권한이 별개일 수 있고, own identity·위임 접근·custom header가 다른 인증 경로임을 설명합니다.
3. Google Cloud IAM, “Agent Identity overview” — agent 자체 identity와 사용자 위임 권한, Agent Identity·Registry·Gateway의 역할 구분을 확인하는 자료입니다.
4. Google Cloud Blog, “Inside Agent Compute Engine: Building the compute foundation for the agentic era” — 에이전트 실행 인프라의 배경 맥락을 위한 원저자 기술 글입니다. 이 글에서는 이 자료로 서비스의 일반 제공 여부나 비용·성능·보안 결과를 주장하지 않습니다.

위 설명은 Google Cloud 문서의 해당 제품 범위에 한정됩니다. 다른 Registry, 클라우드, MCP 서버, 실행 프레임워크에는 각 제품의 인증·정책 모델을 별도로 확인해 주세요.