Como proteger implantações empresariais com agentes em várias nuvens

1. Introdução

Neste codelab, você vai implantar uma implantação segura de agente único / várias ferramentas usando o Kit de Desenvolvimento de Agente (ADK), o Agent Engine e o Google Kubernetes Engine. Você vai aprender como um agente de IA iniciado por um usuário no Gemini Enterprise navega com segurança pelo Google Cloud, contando com o GKE Gateway com Service Extensions para ocultar dados sensíveis em trânsito das respostas da ferramenta MCP.

Conteúdo do laboratório

Implantar um agente assistente de hipoteca do ADK no Agent Engine com instrumentação do OpenTelemetry
Implante servidores MCP de back-end no Google Kubernetes Engine (GKE) atrás de um gateway interno.
Conecte o Agent Engine a uma VPC do projeto usando uma interface do PSC e o peering de DNS.
Exponha APIs REST como ferramentas do MCP usando o proxy de descoberta do MCP Apigee.
Configure o GKE Gateway para saída controlada de agentes com Service Extensions para remoção de dados sensíveis da DLP e autorização do MCP
Aplicar barreiras de proteção de IA com o Model Armor para análise de comandos e respostas

O que é necessário

Um navegador da web, como o Chrome
Tenha um projeto do Google Cloud com o faturamento ativado.
Conhecimento básico de Terraform, Kubernetes e Python

Este codelab é destinado a desenvolvedores e profissionais de segurança que querem implantar e proteger fluxos de trabalho de agentes em ambientes empresariais.

2. Antes de começar

Crie um projeto na nuvem do Google Cloud e ative as APIs necessárias.

No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto na nuvem .
Verifique se o faturamento está ativado para seu projeto do Cloud. Saiba como verificar se o faturamento está ativado em um projeto.

Papéis do IAM obrigatórios

Este codelab pressupõe que você tenha o papel de Proprietário do projeto no seu projeto na nuvem do Google.

Ativar APIs

No console do Google Cloud, clique em Ativar o Cloud Shell: se você nunca usou o Cloud Shell antes, um painel vai aparecer com a opção de iniciar o Cloud Shell em um ambiente confiável com ou sem um boost. Se for preciso autorizar o Cloud Shell, clique em Autorizar.

No Cloud Shell, ative todas as APIs necessárias:

gcloud services enable \
compute.googleapis.com \
container.googleapis.com \
dns.googleapis.com \
certificatemanager.googleapis.com \
dlp.googleapis.com \
aiplatform.googleapis.com \
discoveryengine.googleapis.com \
apigee.googleapis.com

Instalar dependências

No Cloud Shell, verifique se você tem as ferramentas necessárias instaladas. O Terraform, o kubectl e o Go geralmente vêm pré-instalados. Você precisa instalar o uv (gerenciador de pacotes do Python) e o Skaffold:

# Install uv
curl -LsSf https://astral.sh/uv/install.sh | sh

# Install Skaffold
curl -Lo skaffold https://storage.googleapis.com/skaffold/releases/latest/skaffold-linux-amd64 && \
sudo install skaffold /usr/local/bin/

Defina as variáveis de ambiente

Defina as seguintes variáveis de ambiente usadas neste codelab:

export PROJECT_ID=$(gcloud config get project)
export REGION=us-central1
export LOCATION=${REGION}

Criar uma zona de DNS pública

Este codelab exige que uma zona de DNS pública já exista no seu projeto antes de aplicar a configuração do Terraform. Essa zona é necessária para a delegação de servidores de nomes. Assim, a configuração pode automatizar a criação dos registros necessários para o Certificate Manager.

Execute o seguinte comando no Cloud Shell para criar a zona:

gcloud dns managed-zones create "inference-gateway-zone" \
    --dns-name="gateway.example.com." \
    --description="Public zone for Inference Gateway" \
    --visibility="public" \
    --project="${PROJECT_ID}"

3. Clonar um repositório do GitHub

Em um terminal na sua máquina local, clone o repositório cloud-networking-solutions:
```
git clone https://github.com/googleCloudPlatform/cloud-networking-solutions.git
```

Navegue até o diretório do repositório baixado:

cd cloud-networking-solutions/demos/service-extensions-gke-gateway

4. Implantar infraestrutura com o Terraform

Você vai usar o Terraform para provisionar a rede fundamental, o cluster do GKE e as configurações de identidade necessárias.

Navegue até o diretório terraform no repositório clonado:
```
cd terraform
```
Configure o back-end do Terraform. Crie um arquivo backend.conf para configuração parcial de back-end. Substitua por um nome de bucket globalmente exclusivo.
```
cat <<EOF > backend.conf
bucket = "<YOUR_TERRAFORM_STATE_BUCKET>"
prefix = "terraform"
EOF
```

Copie o arquivo de variáveis de exemplo e atualize-o com os valores do seu projeto:
```
cp example.tfvars terraform.tfvars
```
Edite terraform.tfvars e substitua os valores do marcador.Substitua o seguinte:
- project_id: o ID do seu projeto do Google Cloud.
- organization_id: o ID numérico da organização do GCP.
- dns_zone_domain: um domínio que você controla (por exemplo, demo.example.com.). Precisa terminar com um ponto.
Verifique se as seguintes flags de recursos estão ativadas. Elas já estão pré-configuradas no arquivo de exemplo:
- enable_certificate_manager = true
- enable_model_armor = true
- enable_agent_engine = true
- enable_psc_interface = true

Inicialize e aplique a configuração do Terraform:

terraform init -backend-config=backend.conf
terraform plan -out=tfplan
terraform apply "tfplan"

5. Implantar cargas de trabalho de amostra com o Skaffold

Em seguida, implante os servidores do MCP e os serviços de processamento externo no seu cluster do GKE.

Conecte-se ao cluster do GKE criado pelo Terraform:

gcloud container clusters get-credentials gateway-cluster \
    --region=${REGION} \
    --project=${PROJECT_ID}

Volte para a raiz do projeto e configure os modelos de manifesto do Kubernetes. Copie o exemplo de configuração e defina o ID do projeto e o domínio base:defina BASE_DOMAIN para corresponder ao seu ambiente. O BASE_DOMAIN precisa corresponder à sua variável do Terraform dns_zone_domain (sem o ponto final).
```
export BASE_DOMAIN=example.com
```

Gere os manifestos do Kubernetes e skaffold.yaml com base em modelos:

bash k8s/generate.sh
envsubst '${PROJECT_ID}' < skaffold.yaml.tmpl > skaffold.yaml

Implante todos os serviços de back-end:

skaffold run -m legacy-dms,income-verification-api,corporate-email,dlp-ext-proc

Implante a configuração do gateway e do HTTPRoute:
```
kubectl apply -k k8s/gateway-internal/
```

6. Aplicar proteções de IA com o Model Armor

É possível delegar decisões de segurança de conteúdo, como remoção de comandos nocivos ou prevenção de vazamentos de dados, ao Model Armor.

Pré-requisitos: conceder papéis do IAM

Conceda os papéis necessários à conta de serviço do GKE Gateway. A conta de serviço segue o formato: service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com.

Execute os comandos a seguir para conceder as permissões necessárias:

export GATEWAY_PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format="value(projectNumber)")

# Grant roles in the Gateway project
gcloud projects add-iam-policy-binding $PROJECT_ID \
 --member=serviceAccount:service-${GATEWAY_PROJECT_NUMBER}@gcp-sa-dep.iam.gserviceaccount.com \
 --role=roles/modelarmor.calloutUser

gcloud projects add-iam-policy-binding $PROJECT_ID \
 --member=serviceAccount:service-${GATEWAY_PROJECT_NUMBER}@gcp-sa-dep.iam.gserviceaccount.com \
 --role=roles/serviceusage.serviceUsageConsumer

# Grant role in the project containing Model Armor templates
gcloud projects add-iam-policy-binding $PROJECT_ID \
 --member=serviceAccount:service-${GATEWAY_PROJECT_NUMBER}@gcp-sa-dep.iam.gserviceaccount.com \
 --role=roles/modelarmor.user

Criar a extensão de autorização do Model Armor

Defina uma extensão que aponte para o serviço Model Armor na sua região. Salve essa configuração como ma-content-authz-extension.yaml.

Exporte o ID do modelo do Model Armor criado pelo Terraform.

export MA_TEMPLATE_ID=$(cd terraform && terraform output -raw model_armor_template_id)

cat >ma-content-authz-extension.yaml <<EOF
name: ma-ext
service: modelarmor.$LOCATION.rep.googleapis.com
metadata:
  model_armor_settings: '[
  {
  "response_template_id": "projects/${PROJECT_ID}/locations/$LOCATION/templates/${MA_TEMPLATE_ID}",
  "request_template_id": "projects/${PROJECT_ID}/locations/$LOCATION/templates/${MA_TEMPLATE_ID}"
  }
  ]'
failOpen: true
EOF

gcloud beta service-extensions authz-extensions import ma-ext \
    --source=ma-content-authz-extension.yaml \
    --location=$LOCATION

Criar a política de autorização do Model Armor

Crie uma política que associe a extensão do Model Armor ao seu Agent Gateway. Salve essa configuração como ma-content-authz-policy.yaml.

cat >ma-content-authz-policy.yaml <<EOF
name: ma-content-authz-policy
target:
  resources:
  -   "projects/$PROJECT_ID/locations/$LOCATION/gateways/mortgage-gateway"
policyProfile: CONTENT_AUTHZ
action: CUSTOM
customProvider:
  authzExtension:
    resources:
    -   "projects/$PROJECT_ID/locations/$LOCATION/authzExtensions/ma-ext"
EOF

gcloud network-security authz-policies import ma-content-authz-policy \
    --source=ma-content-authz-policy.yaml \
    --location=$LOCATION

7. Configurar o Gemini Enterprise

Ativar a observabilidade

O agente de hipoteca é implantado com a instrumentação do OpenTelemetry e as seguintes variáveis de ambiente de telemetria ativadas por padrão:

GOOGLE_CLOUD_AGENT_ENGINE_ENABLE_TELEMETRY=true
OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT=true
OTEL_TRACES_SAMPLER=parentbased_traceidratio

Para detalhes sobre como configurar rastreamentos e intervalos no Gemini Enterprise, consulte Gerenciar configurações de observabilidade.

Ativar o Model Armor no Gemini Enterprise

Aplique a filtragem do Model Armor ao assistente do Gemini Enterprise para analisar os comandos do usuário e as respostas do modelo. Os apps globais do Gemini Enterprise exigem um modelo do Model Armor na us multirregião. Por isso, o Terraform implanta um modelo separado para essa finalidade.

Recupere o nome do modelo da saída do Terraform:

cd terraform
export GE_MA_TEMPLATE_NAME=$(terraform output -raw model_armor_gemini_enterprise_template_name)

Extraia o ID do APP da sua instância do Gemini Enterprise:

No console do Google Cloud, acesse a página do Gemini Enterprise.
No menu de navegação, clique em "Apps".
Copie o ID da instância do Gemini Enterprise.

Exporte o ID como uma variável de ambiente.

export APP_ID=<PASTE_APP_ID>

Corrija o assistente para ativar o Model Armor:

curl -X PATCH \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -H "X-Goog-User-Project: ${PROJECT_ID}" \
  "https://global-discoveryengine.googleapis.com/v1/projects/${PROJECT_ID}/locations/global/collections/default_collection/engines/${APP_ID}/assistants/default_assistant?update_mask=customerPolicy" \
  -d '{
    "customerPolicy": {
      "modelArmorConfig": {
        "userPromptTemplate": "'"$GE_MA_TEMPLATE_NAME"'",
        "responseTemplate": "'"$GE_MA_TEMPLATE_NAME"'",
        "failureMode": "FAIL_OPEN"
      }
    }
  }'

Defina failureMode como FAIL_OPEN para permitir solicitações quando o Model Armor não estiver disponível ou FAIL_CLOSED para bloqueá-las.

8. Implantar e adicionar um agente no Gemini Enterprise

Receber detalhes da autorização

Siga estas etapas para acessar os detalhes da autorização.

No console do Google Cloud, na página "APIs e serviços", acesse a página "Credenciais".
Acesse Credenciais.
Clique em "Criar credenciais" e selecione "ID do cliente OAuth".
Em "Tipo de aplicativo", selecione "Aplicativo da Web".
Na seção "URIs de redirecionamento autorizados", adicione os seguintes URIs:

https://vertexaisearch.cloud.google.com/oauth-redirect
https://vertexaisearch.cloud.google.com/static/oauth/oauth.html

Clique em "Criar".
Exporte o ID e a chave secreta do cliente para implantação.

export OAUTH_CLIENT_ID=<Client ID>
export OAUTH_CLIENT_SECRET=<Client Secret>

Implantar o agente de empréstimo imobiliário

O script src/mortgage-agent/deploy_agent.py implanta o agente do ADK no Agent Engine e, opcionalmente, o registra no Gemini Enterprise. Consulte Registrar e gerenciar um agente A2A para saber mais sobre o fluxo de registro do Gemini Enterprise.

Exporte variáveis da implantação do Terraform.

export VPC_NAME=$(cd terraform && terraform output -raw vpc_name)
export PSC_ATTACHMENT=$(cd terraform && terraform output -raw psc_interface_network_attachment_id)
export DNS_PEERING_DOMAIN=$(cd terraform && terraform output -raw psc_interface_dns_peering_domain)

Instale as dependências e faça a implantação:

cd src/mortgage-agent
uv sync

Implante o agente no Vertex Agent Engine e registre-o no Gemini Enterprise:

uv run python deploy_agent.py \
    --project=${PROJECT_ID} \
    --dms-mcp-url=https://dms.${DNS_PEERING_DOMAIN%%.}/mcp \
    --income-verification-url=https://income-verification.${DNS_PEERING_DOMAIN%%.} \
    --email-mcp-url=https://email.${DNS_PEERING_DOMAIN%%.}/mcp \
    --network-attachment=projects/${PROJECT_ID}/regions/${REGION}/networkAttachments/${PSC_ATTACHMENT} \
    --dns-peering-domain=${DNS_PEERING_DOMAIN} \
    --dns-peering-target-project=${PROJECT_ID} \
    --dns-peering-target-network=${VPC_NAME} \
    --enable-agent-identity \
    --ge-deploy \
    --app-id=${APP_ID} \
    --oauth-client-id=${OAUTH_CLIENT_ID} \
    --agent-name=mortgage-agent

Referência da flag

Sinalização	padrão	Descrição
`--project`	`$PROJECT_ID`	ID do projeto do GCP
`--dms-mcp-url`	(obrigatório)	URL do servidor MCP do DMS
`--income-verification-url`	(obrigatório)	URL de base da API Income Verification; `/mcp` é anexado automaticamente
`--email-mcp-url`	(obrigatório)	URL do servidor MCP de e-mail
`--region`	`$REGION`	Região do GCP
`--staging-bucket`	`gs://PROJECT-staging`	Bucket do GCS para preparo
`--display-name`	`Mortgage Assistant Agent`	Nome de exibição do agente implantado
`--update`	(opcional)	Atualizar um agente no local (transmitir o nome completo do recurso)
`--network-attachment`	(opcional)	Anexo de rede para interface do PSC (caminho completo ou nome)
`--dns-peering-domain`	(opcional)	Domínio DNS para peering de DNS do PSC-I (precisa terminar com um ponto)
`--dns-peering-target-project`	(opcional)	Projeto que hospeda a rede VPC de destino para peering de DNS
`--dns-peering-target-network`	(opcional)	Nome da rede VPC para peering de DNS
`--enable-agent-identity`	`false`	Ativar credenciais de privilégio mínimo por agente
`--ge-deploy`	`false`	Registrar o agente no Gemini Enterprise após a implantação
`--app-id`	(opcional)	ID do mecanismo do Gemini Enterprise (obrigatório com `--ge-deploy`)
`--oauth-client-id`	`$OAUTH_CLIENT_ID`	ID do cliente OAuth2 (obrigatório com `--ge-deploy`)
`--oauth-client-secret`	`$OAUTH_CLIENT_SECRET`	Chave secreta do cliente OAuth2 (obrigatória com `--ge-deploy`)
`--model`	`gemini-3.1-flash-lite-preview`	Nome do modelo do Gemini para o agente
`--agent-name`	`mortgage-agent`	Autorização do Gemini Enterprise e nome do agente
`--ge-deploy-only`	(opcional)	Registrar um mecanismo de raciocínio existente no Gemini Enterprise sem nova implantação (transmita o nome completo do recurso)

Adicionar usuários com permissão

Para adicionar usuários com permissão a um agente do ADK usando o console do Google Cloud, consulte Adicionar ou modificar usuários e permissões.

9. Testar seu agente

Agora que você implantou e configurou o agente, o GKE Gateway e todos os serviços de back-end, teste o fluxo de ponta a ponta para verificar se as políticas de segurança estão funcionando como esperado. Você vai interagir com o "mortgage-agent" na interface do Gemini Enterprise.

Acessar o agente

Acesse a página do Gemini Enterprise no console do Google Cloud.
Selecione o app do Gemini Enterprise que você configurou antes, onde o "mortgage-agent" está registrado.
Na guia "Visão geral", navegue até o URL mostrado na seção "Seu app da Web do Gemini Enterprise está pronto".
Selecione a guia "Agente" no menu à esquerda chamado Galeria de agentes.
Agora você pode conversar com o "Agente de assistência de hipoteca".

Caso de teste 1: o "caminho feliz" – resumo de dados com encobrimento de PII

Esse teste verifica se o agente pode acessar sistemas de back-end pelo gateway do agente e se as políticas de prevenção contra perda de dados (DLP) são aplicadas para redigir informações sensíveis.

Envie o seguinte comando ao agente do Assistente de hipotecas:

I'm reviewing the Sterling family's current application. Can you summarize their 2024 and 2025 tax returns and verify if their total household income meets our 2026 debt-to-income requirements?

O que acontece nos bastidores:
- O agente do Gemini Enterprise formula solicitações para as ferramentas necessárias, como o sistema de gerenciamento de documentos (DMS, na sigla em inglês) para declarações de imposto de renda e a API Income Verification.
- O Model Armor inspeciona os payloads de solicitação e resposta em busca de ameaças.
- A "Política de autorização baseada em conteúdo" que você configurou aciona a extensão personalizada de DLP (dlp-content-authz-ext). Essa extensão inspeciona os dados buscados dos sistemas de back-end.
- O serviço de DLP encobre todas as informações de identificação pessoal (PII), como números de CPF, dos dados da declaração de imposto de renda antes que eles cheguem ao agente.
Resultado esperado:o agente vai retornar um resumo das declarações de tributos e um status de verificação de renda. É fundamental inspecionar o resumo fornecido pelo agente. Observe que informações sensíveis, como números de identificação do contribuinte (SSNs), foram substituídas por marcadores de posição (por exemplo, [REDACTED]). Isso confirma a execução da política de DLP pelo gateway.

Observabilidade e auditoria

Durante esses testes, a plataforma do agente e os serviços associados coletam telemetria:

Cloud Logging:registros detalhados do gateway do GKE, das cargas de trabalho do GKE e de outros serviços fornecem um rastreamento de auditoria de solicitações, avaliações de políticas e resultados.
Cloud Trace:a instrumentação do OpenTelemetry configurada no agente e nos serviços de back-end permite visualizar todo o fluxo de chamadas, do Gemini Enterprise pelo gateway do GKE até as ferramentas de back-end. Isso é muito útil para depurar e entender o ciclo de vida da solicitação.

Veja os rastreamentos das suas sessões:

No console do Google Cloud, acesse a página do Vertex AI Agent Engine.
Acesse o Agent Engine. As instâncias do Agent Engine que fazem parte do projeto selecionado aparecem na lista. Use o campo "Filtro" para filtrar a lista pela coluna especificada.
Clique no nome da sua instância do Agent Engine.
Clique na guia "Traces".
Você pode selecionar a visualização de sessão ou de intervalo.
Clique em uma sessão ou período para inspecionar os detalhes do trace, incluindo um gráfico acíclico direcionado (DAG) dos períodos, entradas e saídas e atributos de metadados.

10. Opcional: transcodificar APIs REST para MCP com a Apigee

Embora nosso serviço de verificação de renda seja compatível com o Protocolo de Contexto de Modelo, muitos sistemas legados empresariais só oferecem APIs RESTful. Nesta etapa opcional, você vai usar o proxy de descoberta do MCP da Apigee para transcodificar o endpoint REST do serviço de verificação de renda em uma ferramenta do MCP. Isso permite aplicar a governança avançada, a limitação de taxa e as políticas de segurança da Apigee às suas ferramentas legadas.

Para mais informações, consulte a visão geral do MCP da Apigee.

Pré-requisitos

Antes de continuar, provisione e configure o hub de API da Apigee. Siga as etapas na documentação Provisionar o hub de APIs para configurar e anexar sua instância da Apigee.

Etapa 1: criar um anexo de serviço para a Apigee

Para permitir que a Apigee alcance seus serviços internos em execução no GKE, crie uma vinculação de serviço.

Procure a regra de encaminhamento do gateway interno do GKE:

export RULE_URI=$(gcloud compute forwarding-rules list \
  --filter="loadBalancingScheme=INTERNAL_MANAGED AND target~targetHttpsProxies" \
  --format="value(selfLink.segment(6), region.basename(), name)" | \
  awk '{print "projects/" $1 "/regions/" $2 "/forwardingRules/" $3}')

Crie o anexo do serviço:

gcloud compute service-attachments create internal-gke-gateway-apigee \
    --region=${REGION} \
    --target-service=$RULE_URI \
    --connection-preference=ACCEPT_AUTOMATIC \
    --nat-subnets=gateway-psc-subnet

Etapa 2: ativar o Apigee com o Terraform

Agora, atualize a configuração da infraestrutura para provisionar a organização e a instância da Apigee.

Navegue até o diretório terraform:
```
cd terraform
```
Edite terraform.tfvars e defina enable_apigee = true.
Aplique as alterações:
```
terraform apply
```

Etapa 3: definir a especificação OpenAPI

A Apigee usa definições padrão da OpenAPI (OAS) para descobrir e transcodificar ferramentas. Crie um arquivo chamado income-verification-oas.yaml com o conteúdo a seguir:

openapi: 3.0.0
info:
  title: Income Verification API
  description: Verify applicant income through third-party employer records.
  version: 1.0.0
servers:
  -   url: https://income-verification.internal.${DNS_PEERING_DOMAIN%%.}/api
paths:
  /income-verification/verify:
    post:
      summary: Verify applicant income
      operationId: verifyApplicant
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              properties:
                first_name:
                  type: string
                last_name:
                  type: string
      responses:
        '200':
          description: Successful verification
          content:
            application/json:
              schema:
                type: object

Etapa 4: implante o proxy de descoberta do MCP do Apigee

O proxy de descoberta do MCP é um proxy especializado da Apigee que atua como um servidor MCP.

Na interface da Apigee, acesse Desenvolver > Proxies de API.
Clique em Criar novo e selecione Proxy de descoberta do MCP.
Nomeie o proxy como income-verification-discovery.
Na seção Especificação OpenAPI, faça upload do arquivo income-verification-oas.yaml que você criou.
Defina o Grupo de ambientes como aquele em que o gateway interno está acessível.
Clique em Implantar.

(Opcional) Adicionar uma política de segurança

Antes de implantar ou compartilhar seu proxy, proteja-o. É possível adicionar políticas para aplicar requisitos de segurança, como tokens OAuth ou chaves de API. Para instruções sobre como adicionar uma política de segurança, consulte a documentação da Apigee sobre como proteger APIs.

Etapa 5: verificar o acesso à ferramenta transcodificada

Depois de implantado, o Apigee transcodifica automaticamente o endpoint POST /verify em uma ferramenta MCP verifyApplicant.

Liste as ferramentas disponíveis no endpoint do MCP da Apigee:

curl -X POST https://api.internal.${DNS_PEERING_DOMAIN%%.}/income-verification-discovery/mcp \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/list",
    "params": {}
  }'

Você vai encontrar a ferramenta verifyApplicant na resposta, transcodificada da sua especificação REST. Agora é possível chamar essa ferramenta pela Apigee, que vai processar a tradução para o serviço REST subjacente e aplicar as políticas de segurança configuradas.

Etapa 6: atualizar o agente de hipotecas para usar a Apigee

Agora que o Apigee está transcodificando sua API REST em uma ferramenta compatível com MCP, você precisa atualizar a configuração de implantação do agente. Ao direcionar o agente para o endpoint da Apigee, todas as solicitações de verificação de renda agora se beneficiam da segurança, do registro e do gerenciamento de tráfego de nível empresarial da Apigee.

Identifique o URL do MCP da Apigee: seu endpoint precisa seguir o padrão https://api.internal.${DNS_PEERING_DOMAIN%%.}/income-verification-discovery/mcp.

Execute o script de implantação novamente:use a flag --update com o novo --income-verification-url. Isso atualiza o agente atual no Agent Engine sem exigir uma exclusão completa.

cd src/mortgage-agent

# Update the agent to route income verification through Apigee
uv run python deploy_agent.py \
    --project=${PROJECT_ID} \
    --update \
    --agent-name=mortgage-agent \
    --dms-mcp-url=https://dms.${DNS_PEERING_DOMAIN%%.}/mcp \
    --income-verification-url=https://api.internal.${DNS_PEERING_DOMAIN%%.}/income-verification-discovery/mcp \
    --email-mcp-url=https://email.${DNS_PEERING_DOMAIN%%.}/mcp \
    --network-attachment=projects/${PROJECT_ID}/regions/${REGION}/networkAttachments/${PSC_ATTACHMENT} \
    --dns-peering-domain=${DNS_PEERING_DOMAIN} \
    --dns-peering-target-project=${PROJECT_ID} \
    --dns-peering-target-network=${VPC_NAME} \
    --ge-deploy \
    --app-id=${APP_ID} \
    --oauth-client-id=${OAUTH_CLIENT_ID}

Verifique a mudança:volte à interface do Gemini Enterprise e peça ao agente para verificar a renda de um candidato.
```
"Can you verify the joint income for the Sterlings using the verification service?"
```
Na guia "Apigee Debug", agora você vai ver a solicitação JSON-RPC recebida do GKE Gateway sendo transformada em uma solicitação REST POST padrão para o serviço GKE de back-end.

11. Limpar

Para evitar cobranças na sua conta do Google Cloud pelos recursos criados neste codelab, exclua-os quando terminar.

Exclua o anexo de serviço se ele foi criado manualmente:

gcloud compute service-attachments delete internal-gke-gateway \
    --region=${REGION} --quiet

Navegue até o diretório terraform e destrua todos os recursos:
```
cd terraform
terraform destroy
```
Se quiser, exclua todo o projeto na nuvem do Google Cloud:
```
gcloud projects delete ${PROJECT_ID}
```

12. Parabéns

Você concluiu este codelab e aprendeu a proteger implantações empresariais agênticas entre nuvens.

Conteúdo abordado

Implantou um agente assistente de hipoteca do ADK no Agent Engine com instrumentação do OpenTelemetry
Implantamos servidores MCP de back-end no GKE por trás de um gateway interno.
Conectou o Agent Engine a uma VPC do projeto usando uma interface do PSC e o peering de DNS.
Configurou o GKE Gateway para saída de agente governada com redação de DLP e autorização do MCP
Barreiras de proteção de IA aplicadas com o Model Armor para análise de comandos e respostas
APIs REST transcodificadas para MCP usando o proxy de descoberta do MCP da Apigee (opcional)

Próximas etapas

Conheça o Model Armor
Leia sobre o Agent Engine
Conheça o Gemini Enterprise