이 페이지에서는 에이전트 게이트웨이를 통해 에이전트 런타임 트래픽을 라우팅하는 방법을 설명합니다. Agent Gateway는 Gemini Enterprise Agent Platform 생태계의 중앙 네트워킹 및 보안 구성요소입니다. 사용자와 에이전트 간, 에이전트와 도구 간 또는 에이전트 간에 발생하는 모든 에이전트 상호작용을 위한 안전하고 관리되는 연결을 제공합니다.
시작하기 전에
Agent Runtime에 에이전트를 배포하는 방법을 숙지해야 합니다.
Agent Gateway에 대해 알아봅니다. Agent-to-Anywhere (egress) 모드에서 Agent Gateway를 사용하여 도구, 모델, API, 기타 에이전트로의 아웃바운드 트래픽을 포함한 모든 아웃바운드 통신을 보호하고 관리할 수 있습니다. 클라이언트-에이전트(수신) 모드에서 게이트웨이를 사용하여 에이전트에 액세스할 수 있는 클라이언트를 제어합니다. 게이트웨이를 사용하면 이러한 상호작용에 적용해야 하는 IAP 정책과 Model Armor 템플릿을 선택할 수 있습니다.
단일 런타임 인스턴스는 에이전트-어디서나(이그레스) 게이트웨이와 클라이언트-에이전트 (인그레스) 게이트웨이에 동시에 바인딩할 수 있습니다.
제한사항
- Agent Gateway는 2026년 4월 29일 이전에 생성된 런타임 추론 엔진에 바인딩할 수 없습니다.
단일 프로젝트 및 리전에서 여러 Agent-to-Anywhere (이그레스) 및 Client-to-Agent (인그레스) Agent Gateway 인스턴스를 호스팅할 수 있지만 동일한 프로젝트 및 리전 내에 배포된 모든 Agent Runtime 에이전트는 동일한 특정 이그레스 및 인그레스 Agent Gateway 인스턴스에 바인딩되어야 합니다.
예를 들어 프로젝트와 리전에
egress-gateway-X및egress-gateway-Y이 포함된 경우 해당 프로젝트와 리전의 모든 에이전트는 이그레스를 위해 동일한 게이트웨이를 사용하도록 구성해야 합니다. 즉, 모든 에이전트가egress-gateway-X를 사용하거나 모든 에이전트가egress-gateway-Y를 사용합니다.egress-gateway-X를 사용하도록agent-A를 구성하고egress-gateway-Y를 사용하도록agent-B를 구성할 수는 없습니다.이 동일한 바인딩 규칙은 프로젝트 및 리전 내의 인그레스 게이트웨이에도 적용됩니다.
Security Command Center Agent Engine Threat Detection 서비스는 에이전트에 대해 Agent Gateway가 사용 설정된 경우 사용할 수 없습니다.
클라이언트-에이전트 (인그레스) 모드에서 Agent Gateway는 Agent Runtime의
query및streamQuery메서드만 관리할 수 있습니다. 지원되지 않는 다른 메서드 (예:asyncQuery)를 보호하려면 애플리케이션이나 에이전트에서 직접 Model Armor 템플릿을 적용하면 됩니다. 프롬프트 및 대답 정리 또는 Model Armor를 사용하여 보안 에이전트 시스템 빌드에 관한 이 Codelab을 참고하세요.VPC 서비스 제어는 에이전트 게이트웨이에서 지원되지 않습니다.
Agent Gateway를 통해 Agent Runtime 트래픽 라우팅
Agent Gateway를 통해 Agent Runtime 트래픽을 라우팅하려면 다음 단계를 수행하세요.
Agent Gateway 리소스를 만들고 필요에 따라 승인 정책을 연결합니다. 에이전트-어디로든 (이그레스) 모드 또는 클라이언트-에이전트 (인그레스) 모드에서 게이트웨이를 만들 수 있습니다. 에이전트와 게이트웨이는 동일한 프로젝트와 리전에서 생성해야 합니다. 자세한 내용은 에이전트 게이트웨이 설정을 참고하세요.
게이트웨이가 배포 요구사항을 충족하도록 구성되어 있는지 확인합니다. 예를 들어 에이전트에 LLM 액세스가 필요한 경우 잠재적인 Agent Runtime 배포 실패를 방지하기 위해 이 액세스를 허용하도록 게이트웨이를 구성합니다.
Agent Gateway를 통해 트래픽을 라우팅하도록 에이전트를 구성합니다.
신규 상담사
에이전트를 배포하는 동안 게이트웨이 리소스를 지정합니다. 예를 들어 Agent Runtime에 에이전트를 배포하려면
client.agent_engines.create를 사용하여local_agent객체를 선택적 구성과 함께 전달합니다.이 에이전트와 함께 Model Armor 또는 Semantic Governance Policies와 같은 게이트웨이 중재 플랫폼 기능을 사용하려면 이 예와 같이 생성 호출에서
agent_gateway_config와identity_type=AGENT_IDENTITY를 모두 설정하세요.identity_type=AGENT_IDENTITY가 없으면 런타임 인스턴스의effectiveIdentity이 기본 Vertex AI 서비스 계정으로 대체되고 시맨틱 거버넌스 정책이 정책 생성 선택기에서 에이전트를 자동으로 필터링합니다.remote_agent = client.agent_engines.create( agent=local_agent, config={ "agent_gateway_config": { "agent_to_anywhere_config": {"agent_gateway": projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_TO_ANYWHERE_NAME}, # "client_to_agent_config": {"agent_gateway": projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_CLIENT_TO_AGENT_NAME} }, "identity_type": types.IdentityType.AGENT_IDENTITY, # Other optional configuration ... # "requirements": requirements, # "gcs_dir_name": gcs_dir_name, # https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/runtime/agent-identity#opt-out-caa "env_vars": { "GOOGLE_API_PREVENT_AGENT_TOKEN_SHARING_FOR_GCP_SERVICES": False, } }, )
AGENT_GATEWAY_TO_ANYWHERE_NAME을 에이전트-투-애니웨어(이그레스) 모드에서 만든 Agent Gateway의 이름으로 바꿉니다.클라이언트-에이전트 (인그레스) 모드에서 게이트웨이를 만든 경우 대신
client_to_agent_config필드를 사용하고AGENT_GATEWAY_CLIENT_TO_AGENT_NAME을 인그레스를 위해 만든 Agent Gateway의 이름으로 바꿉니다.기존 상담사의 경우
Agent-to-Anywhere
다음 REST API 요청을 사용하여 기존 상담사를 출구용 Agent-to-Anywhere 게이트웨이와 연결합니다.
curl -X PATCH \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -H "Content-Type: application/json; charset=utf-8" \ -d '{ "spec": { "deploymentSpec": { "agentGatewayConfig": { "agentToAnywhereConfig": { "agentGateway": "projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_TO_ANYWHERE_NAME" } } } } }' \ "https://REGION-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/REGION/reasoningEngines/RESOURCE_ID?updateMask=spec.deploymentSpec.agentGatewayConfig"
다음을 바꿉니다.
PROJECT_ID: 프로젝트 ID입니다.REGION: 에이전트가 배포된 리전AGENT_GATEWAY_TO_ANYWHERE_NAME: 에이전트에서 모든 위치로(이그레스) 모드에서 만든 Agent Gateway의 이름RESOURCE_ID: 에이전트의 리소스 ID
클라이언트에서 에이전트로
다음 REST API 요청을 사용하여 기존 상담사를 인그레스용 Client-to-Agent gateway와 연결합니다.
curl -X PATCH \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -H "Content-Type: application/json; charset=utf-8" \ -d '{ "spec": { "deploymentSpec": { "agentGatewayConfig": { "clientToAgentConfig": { "agentGateway": "projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_CLIENT_TO_AGENT_NAME" } } } } }' \ "https://REGION-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/REGION/reasoningEngines/RESOURCE_ID?updateMask=spec.deploymentSpec.agentGatewayConfig"
다음을 바꿉니다.
PROJECT_ID: 프로젝트 ID입니다.REGION: 에이전트가 배포된 리전AGENT_GATEWAY_CLIENT_TO_AGENT_NAME: 클라이언트에서 에이전트로(인그레스)에서 만든 Agent Gateway의 이름RESOURCE_ID: 에이전트의 리소스 ID
에이전트 및 게이트웨이와 동일한 프로젝트 및 리전의 에이전트 레지스트리 인스턴스에 등록합니다.
gcloud agent-registry services create SERVICE_NAME \ --project=PROJECT_ID \ --location=REGION \ --display-name="DISPLAY_NAME" \ --endpoint-spec-type=no-spec \ --interfaces='[{url="https://REGION-aiplatform.mtls.googleapis.com",protocolBinding="jsonrpc"}]' \ --format="value(registryResource)"다음을 바꿉니다.
SERVICE_NAME: 리소스에 지정할 이름(예:allow-aiplatform-region-eu3)PROJECT_ID: 프로젝트 ID입니다.REGION: 레지스트리 리전입니다.DISPLAY_NAME: 엔드포인트의 사람이 읽을 수 있는 이름입니다.
자세한 내용은 에이전트 등록을 참고하세요.
에이전트에 대한 에이전트-레지스트리 IAM 정책 바인딩을 만듭니다.
gcloud iap web add-iam-policy-binding \ --resource-type=agent-registry \ --endpoint=ENDPOINT_ID \ --region=REGION \ --project=PROJECT_ID \ --member=MEMBER \ --role=roles/iap.egressor
다음을 바꿉니다.
ENDPOINT_ID: 등록된 에이전트의 서비스 엔드포인트 ID입니다. 이 값은 이전 단계의 출력에서 가져옵니다.MEMBER: 역할을 부여할 에이전트 ID 주 구성원입니다. 일반적으로 형식은principal://TRUST_DOMAIN/resources/aiplatform/projects/PROJECT_ID/locations/REGION/reasoningEngines/ENGINE_ID입니다.
이제 에이전트 트래픽이 Agent Gateway를 통해 라우팅됩니다. 하지만 Agent Gateway는 기본 거부 정책을 채택합니다. 특정 Agent Platform 기능을 사용 설정하려면 에이전트가 다음 엔드포인트와 통신할 수 있어야 합니다.
Cloud Trace가 사용 설정된 경우 Agent Gateway는 엔드포인트
https://telemetry.googleapis.com/로의 트래픽을 허용해야 합니다.GOOGLE_API_USE_CLIENT_CERTIFICATE및GOOGLE_API_USE_MTLS_ENDPOINT환경 변수가 설정된 경우https://telemetry.mtls.googleapis.com/로의 트래픽도 허용되는지 확인합니다.Cloud Logging이 사용 설정된 경우 Agent Gateway는 엔드포인트
https://logging.googleapis.com/로의 트래픽을 허용해야 합니다.GOOGLE_API_USE_CLIENT_CERTIFICATE및GOOGLE_API_USE_MTLS_ENDPOINT환경 변수가 설정된 경우https://logging.mtls.googleapis.com/로의 트래픽도 허용되는지 확인합니다.
또한 에이전트가 LLM을 호출하거나 세션 및 메모리 뱅크와 같은 기능을 사용하는 경우 에이전트가 이러한 서비스에서 사용하는 엔드포인트와 통신할 수 있는지 확인해야 합니다. 예를 들면 다음과 같습니다.
- 세션:
https://REGION-aiplatform.googleapis.com/API_VERSION/projects/PROJECT_ID/locations/REGION/reasoningEngines/RESOURCE_ID/sessions - 메모리 뱅크:
https://REGION-aiplatform.googleapis.com/API_VERSION/projects/PROJECT_ID/locations/REGION/reasoningEngines/RESOURCE_ID/memories
보안상의 이유로 에이전트가 액세스하는 특정 URI만 등록하고 허용 목록에 추가하는 것이 좋습니다. 게이트웨이는 호스트 이름을 직접 일치시키므로 에이전트 SDK가 사용하는 모든 변형을 등록해야 합니다. 예를 들어 SDK 버전, 리전 클라이언트 구성 또는 mTLS 사용에 따라 Google API는 다음 엔드포인트 호스트 이름을 통해 확인할 수 있습니다.
https://REGION-aiplatform.googleapis.comhttps://REGION-aiplatform.mtls.googleapis.comhttps://aiplatform.REGION.rep.googleapis.com
엔드포인트를 등록하는 방법을 알아보려면 엔드포인트 등록을 참고하세요. 또한 에이전트에 이러한 엔드포인트에 대한 IAP Egressor 역할이 있는지 확인해야 합니다. 자세한 내용은 에이전트-엔드포인트 이그레스 정책 만들기를 참고하세요.
에이전트 구성을 확인합니다.
콘솔
- Google Cloud 콘솔에서 Agent Platform 배포 페이지로 이동합니다.
배포한 에이전트의 이름을 클릭합니다.
서비스 구성을 클릭합니다. 에이전트의 관측 가능성 창이 열립니다.
배포 세부정보를 클릭합니다. Agent Gateway 인그레스 및 이그레스 구성은 배포 사양 필드에서 확인할 수 있습니다.
gcloud
다음 REST API 요청을 사용하여 에이전트가 이제 게이트웨이와 연결되었는지 확인합니다. 반환된 출력이
null이면 런타임이 게이트웨이에 바인딩되지 않은 것입니다.curl -s -X GET \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ "https://REGION-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/REGION/reasoningEngines/RESOURCE_ID" \ | jq '.spec.deploymentSpec.agentGatewayConfig'
다음을 바꿉니다.
PROJECT_ID: 프로젝트 ID입니다.REGION: 에이전트가 배포된 리전RESOURCE_ID: 에이전트의 리소스 ID
- Google Cloud 콘솔에서 Agent Platform 배포 페이지로 이동합니다.
Agent Gateway용 맞춤 컨테이너 (BYOC) 에이전트 구성
커스텀 컨테이너 이미지 (Bring Your Own Container / BYOC)로 배포된 에이전트의 Agent-to-Anywhere (이그레스) Agent Gateway를 통해 아웃바운드 트래픽을 라우팅하려면 게이트웨이의 루트 인증 기관 (CA) 인증서를 커스텀 컨테이너 이미지의 트러스트 저장소에 베이킹해야 합니다.
에이전트 게이트웨이는 아웃바운드 에이전트 통신에 대해 TLS 복호화 및 검사를 실행하므로 비 BYOC (소스 기반) 에이전트 배포는 이미지 생성 중에 CA의 인증서를 자동으로 삽입합니다. 커스텀 컨테이너 이미지의 경우 게이트웨이의 CA 인증서를 명시적으로 가져와 Dockerfile 내의 시스템 CA 트러스트 저장소에 설치하고 Python SDK, HTTP 클라이언트 라이브러리, gRPC에 필요한 인증서 번들 환경 변수를 설정해야 합니다.
에이전트 게이트웨이 이그레스를 위한 BYOC 컨테이너 이미지를 구성하려면 다음 단계를 따르세요.
Agent Gateway 리소스에서 루트 인증서를 가져옵니다.
에이전트 게이트웨이 리소스의
agentGatewayCard.rootCertificates필드에서 CA 루트 인증서 PEM 문자열을 직접 내보냅니다.export AGW_CERT=$(gcloud network-services agent-gateways describe AGENT_GATEWAY_NAME \ --location=REGION \ --project=PROJECT_ID \ --format="value[delimiter=\\n](agentGatewayCard.rootCertificates)")
또는 REST API를 사용하여 게이트웨이 리소스를 검색할 수 있습니다.
curl -s -X GET \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ "https://networkservices.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_NAME" \ | jq -r '.agentGatewayCard.rootCertificates[]'
다음을 바꿉니다.
AGENT_GATEWAY_NAME: 이그레스 에이전트 게이트웨이의 이름REGION: 게이트웨이가 배포된 리전PROJECT_ID: 프로젝트 ID입니다.
CA 인증서를 신뢰하도록
Dockerfile를 업데이트합니다.Dockerfile에AGENT_GATEWAY_ROOT_CERTIFICATES빌드 인수를 추가합니다. 빌드 명령어는 인증서를 별도의 파일로 분할하고update-ca-certificates를 사용하여 설치하며 OpenSSL, Python HTTP 클라이언트 라이브러리 (requests,httpx), gRPC가 맞춤 CA를 인식하도록 환경 변수를 설정합니다.# Install root certificates under root user USER root ARG AGENT_GATEWAY_ROOT_CERTIFICATES RUN if [ -n "$AGENT_GATEWAY_ROOT_CERTIFICATES" ]; then \ echo "Installing Agent Gateway root certificates..."; \ printf "%b" "$AGENT_GATEWAY_ROOT_CERTIFICATES" | awk 'BEGIN {c=0} /BEGIN CERTIFICATE/ {c++} c > 0 { print > "/usr/local/share/ca-certificates/agw-" c ".crt" }'; \ update-ca-certificates; \ fi # Configure SSL/TLS trust paths for Python HTTP libraries, OpenSSL, and gRPC ENV GRPC_DEFAULT_SSL_ROOTS_FILE_PATH=${AGENT_GATEWAY_ROOT_CERTIFICATES:+/etc/ssl/certs/ca-certificates.crt} ENV REQUESTS_CA_BUNDLE=${AGENT_GATEWAY_ROOT_CERTIFICATES:+/etc/ssl/certs/ca-certificates.crt} ENV SSL_CERT_FILE=${AGENT_GATEWAY_ROOT_CERTIFICATES:+/etc/ssl/certs/ca-certificates.crt} ENV AGENT_GATEWAY_ROOT_CERT_302034098528=${AGENT_GATEWAY_ROOT_CERTIFICATES:+/etc/ssl/certs/ca-certificates.crt} # Switch back to application execution user USER 1000
Cloud Build를 사용하여 컨테이너 이미지를 빌드합니다.
대체를 사용하여 루트 인증서 문자열을 Cloud Build에 전달하는
cloudbuild.yaml파일을 만듭니다.steps: - name: 'gcr.io/cloud-builders/docker' args: - 'build' - '--build-arg' - 'AGENT_GATEWAY_ROOT_CERTIFICATES=${_AGW_CERT}' - '-t' - '$_IMAGE_URI' - '.' images: - '$_IMAGE_URI'컨테이너 이미지 빌드를 Cloud Build에 제출합니다.
export IMAGE_URI="REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/IMAGE_NAME:latest" gcloud builds submit \ --project=PROJECT_ID \ --region=REGION \ --config=cloudbuild.yaml \ --substitutions=_IMAGE_URI="$IMAGE_URI",_AGW_CERT="$AGW_CERT" \ .
REPOSITORY_NAME및IMAGE_NAME을 Artifact Registry 저장소 및 이미지 이름으로 바꿉니다.컨테이너화된 에이전트를 배포합니다.
배포 요청에서 Agent Gateway 구성과 함께 빌드된 컨테이너 이미지 URI를 지정합니다 (
spec.deploymentSpec아래에agent_gateway_config사용 또는 SDK 배포 호출 사용).
승인된 에이전트 게이트웨이로 Agent Runtime 제한
에이전트를 배포하는 동안 사용할 수 있는 적격한 Agent Gateway 리소스 집합을 정의하는 맞춤 조직 정책 제약 조건을 만들 수 있습니다.
커스텀 조직 정책 제약조건 만들기
이 예시에서는 사전 승인된 게이트웨이 목록으로 오가는 트래픽만 허용하는 맞춤 제약 조건을 만듭니다.
Agent-to-Anywhere
에이전트-임의 위치 모드 (이그레스)의 맞춤 제약 조건을 정의하려면
constraint-agent-gateway-egress.yaml라는 파일을 만듭니다.다음 예에서
condition필드는 Agent Gateway 리소스가 지정된 경우(필드가 있고 비어 있지 않음) 지정된 게이트웨이가 사전 승인된 목록에 있는 경우에만 작업이 허용됨을 지정합니다.name: organizations/ORGANIZATION_ID/customConstraints/custom.allowlistedEgressAgentGatewaysForAgentEngine resource_types: - aiplatform.googleapis.com/ReasoningEngine condition: >- has(resource.spec.deploymentSpec.agentGatewayConfig.agentToAnywhereConfig.agentGateway) && resource.spec.deploymentSpec.agentGatewayConfig.agentToAnywhereConfig.agentGateway != '' && (resource.spec.deploymentSpec.agentGatewayConfig.agentToAnywhereConfig.agentGateway in [ 'projects/AGENT_PROJECT_ID_1/locations/REGION_1/agentGateways/AGENT_GATEWAY_ID_1', 'projects/AGENT_PROJECT_ID_2/locations/REGION_2/agentGateways/AGENT_GATEWAY_ID_2', ]) method_types: - CREATE - UPDATE action_type: ALLOW display_name: Restrict Reasoning Engine Egress to Approved Agent Gateways description: Reasoning Engines can only be bound to a pre-approved list of Agent Gateway instances. Binding to any other gateway is denied.다음을 바꿉니다.
- ORGANIZATION_ID: 조직 ID입니다.
- AGENT_PROJECT_ID: 프로젝트 ID입니다.
- REGION: 게이트웨이가 생성된 리전입니다.
- AGENT_GATEWAY_ID: 게이트웨이 ID입니다.
커스텀 제약 조건을 적용합니다.
gcloud org-policies set-custom-constraint EGRESS_CONSTRAINT_PATH
EGRESS_CONSTRAINT_PATH을 이전 단계에서 만든 맞춤 제약 조건 파일의 전체 경로로 바꿉니다.
제약 조건을 적용하는 조직 정책을 만듭니다. 조직 정책을 정의하려면
policy-agent-gateway-egress.yaml이라는 정책 YAML 파일을 만듭니다. 이 예시에서는 프로젝트 수준에서 이 제약조건을 적용하지만 조직 또는 폴더 수준에서 이를 설정할 수도 있습니다.name: projects/AGENT_PROJECT_ID/policies/custom.allowlistedEgressAgentGatewaysForAgentEngine spec: rules: - enforce: trueAGENT_PROJECT_ID를 프로젝트 ID로 바꿉니다.조직 정책을 적용합니다.
gcloud org-policies set-policy EGRESS_POLICY_PATH
EGRESS_POLICY_PATH을 이전 단계에서 만든 조직 정책 YAML 파일의 전체 경로로 바꿉니다. 정책이 적용되는 데 최대 15분이 소요됩니다.
클라이언트에서 에이전트로
클라이언트-에이전트 모드 (인그레스)의 맞춤 제약 조건을 정의하려면
constraint-agent-gateway-ingress.yaml라는 파일을 만듭니다.다음 예에서
condition필드는 Agent Gateway 리소스가 지정된 경우(필드가 있고 비어 있지 않음) 지정된 게이트웨이가 사전 승인된 목록에 있는 경우에만 작업이 허용됨을 지정합니다.name: organizations/ORGANIZATION_ID/customConstraints/custom.allowlistedIngressAgentGatewaysForAgentEngine resource_types: - aiplatform.googleapis.com/ReasoningEngine condition: >- has(resource.spec.deploymentSpec.agentGatewayConfig.clientToAgentConfig.agentGateway) && resource.spec.deploymentSpec.agentGatewayConfig.clientToAgentConfig.agentGateway != '' && (resource.spec.deploymentSpec.agentGatewayConfig.clientToAgentConfig.agentGateway in [ 'projects/AGENT_PROJECT_ID_1/locations/REGION_1/agentGateways/AGENT_GATEWAY_ID_1', 'projects/AGENT_PROJECT_ID_2/locations/REGION_2/agentGateways/AGENT_GATEWAY_ID_2', ]) method_types: - CREATE - UPDATE action_type: ALLOW display_name: Restrict Reasoning Engine Ingress to Approved Agent Gateways description: Reasoning Engines can only be bound to a pre-approved list of Agent Gateway instances. Binding to any other gateway is denied.다음을 바꿉니다.
- ORGANIZATION_ID: 조직 ID입니다.
- AGENT_PROJECT_ID: 프로젝트 ID입니다.
- REGION: 게이트웨이가 생성된 리전입니다.
- AGENT_GATEWAY_ID: 게이트웨이 ID입니다.
커스텀 제약 조건을 적용합니다.
gcloud org-policies set-custom-constraint INGRESS_CONSTRAINT_PATH
INGRESS_CONSTRAINT_PATH을 이전 단계에서 만든 맞춤 제약 조건 파일의 전체 경로로 바꿉니다.
제약 조건을 적용하는 조직 정책을 만듭니다. 조직 정책을 정의하려면
policy-agent-gateway-ingress.yaml이라는 정책 YAML 파일을 만듭니다. 이 예시에서는 프로젝트 수준에서 이 제약조건을 적용하지만 조직 또는 폴더 수준에서 이를 설정할 수도 있습니다.name: projects/AGENT_PROJECT_ID/policies/custom.allowlistedIngressAgentGatewaysForAgentEngine spec: rules: - enforce: trueAGENT_PROJECT_ID를 프로젝트 ID로 바꿉니다.조직 정책을 적용합니다.
gcloud org-policies set-policy INGRESS_POLICY_PATH
INGRESS_POLICY_PATH을 이전 단계에서 만든 조직 정책 YAML 파일의 전체 경로로 바꿉니다. 정책이 적용되는 데 최대 15분이 소요됩니다.
커스텀 조직 정책 제약 조건을 사용하는 방법에 대한 자세한 내용은 커스텀 제약 조건 만들기를 참고하세요.
다음 단계
Codelab: Govern agentic workloads with Agent Platform
Gemini Enterprise Agent Platform에서 Agent Gateway를 사용하여 에이전트형 워크로드를 관리하는 방법을 알아보세요.