O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Implantar o Secure Web Proxy como um Gateway de Agente

Nesta página, descrevemos como configurar e implantar sua instância do Secure Web Proxy como um Gateway de Agente.

Visão geral

As cargas de trabalho de IA corporativas implantadas no Google Cloud exigem limites de rede estruturados para manter a conformidade com a privacidade de dados, evitar vazamentos de dados sensíveis e proteger contra ameaças emergentes de IA, como injeção de comandos.

O Gateway de Agente oferece governança de segurança centralizada, aplicação de identidade e proteções de conteúdo para o tráfego de saída de agentes de IA para modelos de linguagem grandes (LLMs), ferramentas do Protocolo de Contexto de Modelo (MCP), APIs externas, agentes remotos e destinos da Web padrão.

É possível implantar um Gateway de Agente gerenciado pelo Google ou uma instância do Secure Web Proxy como um Gateway de Agente autogerenciado. Os dois modelos de implantação oferecem uma solução comum de governança da Gemini Enterprise Agent Platform, incluindo políticas de acesso centralizadas, integração com o Agent Registry e proteções de conteúdo.

Escolha entre as seguintes opções de implantação com base nas suas preferências operacionais:

Gateway de Agente gerenciado pelo Google: use essa opção se quiser uma experiência totalmente gerenciada e sem manutenção, sem a necessidade de gerenciar a infraestrutura de proxy de rede. Para mais informações, consulte Gateway de Agente gerenciado pelo Google. Esse modelo é otimizado para agentes executados no Gemini Enterprise ou no Agent Runtime na Gemini Enterprise Agent Platform.
Secure Web Proxy como um Gateway de Agente autogerenciado: implante sua instância do Secure Web Proxy como um Gateway de Agente se quiser manter o controle total sobre o perímetro da rede VPC, os certificados de CA particulares e o roteamento de proxy para oferecer suporte a agentes executados no Google Kubernetes Engine (GKE) ou no Cloud Run.

Vantagens

Implantar o Secure Web Proxy como um Gateway de Agente oferece os seguintes benefícios:

Infraestrutura controlada pelo cliente: é possível gerenciar o gateway do Secure Web Proxy na sua própria rede de nuvem privada virtual (VPC), mantendo o controle total sobre o roteamento de rede, o endereçamento IP, os certificados de CA particulares e a inspeção de TLS.
Aplicação centralizada de políticas de IA: é possível definir políticas de autorização em um recurso agentGateway. Isso permite aplicar essas políticas diretamente no gateway do Secure Web Proxy para restringir chamadas de ferramentas do MCP, filtrar os destinos externos de agentes de IA e invocar serviços de sanitização de conteúdo, como o Model Armor.
Suporte ao ambiente de execução: é possível rotear o tráfego de saída de agentes de IA hospedados em vários ambientes de execução, como o GKE ou o Cloud Run, por um único perímetro de proxy.
Observabilidade com reconhecimento de agentes: os registros de transações no Cloud Logging contêm automaticamente metadados de execução do agente de IA (agentGatewayInfo), incluindo métodos MCP, nomes de ferramentas e nomes de recursos uniformes (URNs) de destinos do Agent Registry.

Arquitetura

As etapas a seguir mostram como o Secure Web Proxy protege o tráfego de saída como um Gateway de Agente:

Agent Runtime: agentes autônomos executados no GKE ou no Cloud Run iniciam conexões de saída com APIs externas, provedores de modelos, servidores de ferramentas MCP, agentes remotos ou destinos da Web padrão.
Roteamento de tráfego de saída: o tráfego do agente é direcionado para o Secure Web Proxy usando o roteamento de proxy na VPC ou anexos de serviço do Private Service Connect (PSC) entre VPCs.
Avaliação de políticas e sanitização de conteúdo: o Secure Web Proxy encerra conexões TLS, aplica políticas de autorização do MCP e invoca serviços de extensão, como o Model Armor ou o Identity-Aware Proxy (IAP), para sanitizar payloads e verificar a identidade do cliente.

Antes de começar

Antes de implantar a instância do Secure Web Proxy como um Gateway de Agente, conclua os seguintes pré-requisitos:

Ative as seguintes APIs do Google Cloud necessárias:

gcloud services enable \
    networkservices.googleapis.com \
    networksecurity.googleapis.com \
    privateca.googleapis.com \
    certificatemanager.googleapis.com \
    serviceextensions.googleapis.com \
    agentregistry.googleapis.com \
    compute.googleapis.com

Verifique se você tem os seguintes papéis necessários do Identity and Access Management (IAM):
- Papel de administrador de rede do Compute (roles/compute.networkAdmin)
- Papel de administrador de segurança de rede (roles/networksecurity.admin)
- Papel de administrador do CA Service (roles/privateca.admin)

Configure as seguintes variáveis de ambiente para sua implantação:

export PROJECT_ID="my-project-id"
export PROJECT_NUMBER="my-project-number"
export REGION="us-central1"
export NETWORK_NAME="swp-vpc"
export PROXY_SUBNET_NAME="swp-proxy-subnet"
export PSC_NAT_SUBNET_NAME="swp-psc-nat-subnet"
export CA_POOL_NAME="swp-ca-pool"
export ROOT_CA_NAME="swp-root-ca"
export TLS_INSPECTION_POLICY_NAME="swp-tls-inspection-policy"
export SECURE_WEB_PROXY_NAME="swp-agent-gateway"
export SWP_IP_ADDRESS="10.129.0.10"
export SWP_CERTIFICATE_NAME="swp-cert"
export SERVER_TLS_POLICY_NAME="swp-server-tls-policy"
export GATEWAY_SECURITY_POLICY_NAME="swp-security-policy"
export SERVICE_ATTACHMENT_NAME="swp-service-attachment"
export AGENT_GATEWAY_NAME="my-agent-gateway"

Opcional: se os Agent Runtimes operarem em redes VPC ou ambientes gerenciados separados, como clusters do GKE ou do Cloud Run entre projetos, exponha o Secure Web Proxy por um anexo de serviço do Private Service Connect:
- Crie uma sub-rede NAT do PSC com --purpose=PRIVATE_SERVICE_CONNECT.
- Crie um anexo de serviço que tenha como destino o gateway do Secure Web Proxy. Para mais informações, consulte Implantar o Secure Web Proxy como um serviço do Private Service Connect.

Configurar a inspeção de TLS

O Secure Web Proxy encerra as conexões TLS para inspecionar cabeçalhos HTTP, avaliar métodos MCP e limpar payloads.

Para configurar a inspeção de TLS, crie um pool de autoridade certificadora (CA) particular, uma CA raiz e um recurso tlsInspectionPolicy fazendo o seguinte:

Criar um pool de CAs particular.
```
gcloud privateca pools create CA_POOL_NAME \
    --location=REGION \
    --tier=devops \
    --project=PROJECT_ID
```
Substitua:
- CA_POOL_NAME: nome do pool de CAs
- REGION: região em que o pool de CAs é criado
- PROJECT_ID: ID do projeto do Google Cloud .
Crie uma CA raiz no pool de CAs particulares.
```
gcloud privateca roots create ROOT_CA_NAME \
    --pool=CA_POOL_NAME \
    --location=REGION \
    --subject="CN=Agent Gateway SWP Root CA, O=MyOrganization" \
    --auto-enable \
    --project=PROJECT_ID
```
Substitua:
- ROOT_CA_NAME: nome da CA raiz
- CA_POOL_NAME: nome do pool de CAs
- REGION: região em que a CA raiz é criada
- PROJECT_ID: ID do projeto do Google Cloud .
Observação: para permitir que as cargas de trabalho do cliente, como o Cloud Run ou o GKE, confiem nos certificados emitidos por esse pool de CAs durante a inspeção de TLS, exporte o certificado de CA raiz e adicione-o ao repositório de confiança da carga de trabalho. Por exemplo, é possível definir a variável de ambiente AGENT_GATEWAY_ROOT_CERTIFICATES.

Conceda à conta de serviço de segurança de rede permissão para solicitar certificados.

gcloud privateca pools add-iam-policy-binding CA_POOL_NAME \
    --location=REGION \
    --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-networksecurity.iam.gserviceaccount.com" \
    --role="roles/privateca.certificateRequester" \
    --project=PROJECT_ID

Crie o recurso tlsInspectionPolicy em um arquivo chamado tls-inspection-policy.yaml.
```
name: projects/PROJECT_ID/locations/REGION/tlsInspectionPolicies/TLS_INSPECTION_POLICY_NAME
caPool: projects/PROJECT_ID/locations/REGION/caPools/CA_POOL_NAME
```
Substitua:
- PROJECT_ID: ID do projeto do Google Cloud .
- REGION: região em que o TlsInspectionPolicy é criado.
- TLS_INSPECTION_POLICY_NAME: nome do recurso TlsInspectionPolicy.
- CA_POOL_NAME: nome do pool de CAs

Para importar a política, execute o comando gcloud network-security tls-inspection-policies import.

gcloud network-security tls-inspection-policies import TLS_INSPECTION_POLICY_NAME \
    --source=tls-inspection-policy.yaml \
    --location=REGION \
    --project=PROJECT_ID

Implantar o Secure Web Proxy

Criar um gateway do Secure Web Proxy com TLS mútuo (mTLS) configurado.

Verifique se a rede VPC tem uma sub-rede somente proxy na região em que você quer implantar o gateway.
```
gcloud compute networks subnets create PROXY_SUBNET_NAME \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=REGION \
    --network=NETWORK_NAME \
    --range=10.129.0.0/23
```
Substitua:
- PROXY_SUBNET_NAME: nome da sub-rede somente proxy.
- NETWORK_NAME: nome da rede VPC.
- REGION: região em que a sub-rede é criada
Opcional: selecione um endereço IP disponível no intervalo de sub-rede somente proxy, por exemplo, 10.129.0.10 em 10.129.0.0/23, para atribuir ao SWP_IP_ADDRESS.

Observação: se você não adicionar o campo addresses no arquivo swp.yaml, o Secure Web Proxy vai alocar automaticamente um endereço IP da sub-rede somente proxy.
Para garantir que o gateway do Secure Web Proxy possa aceitar com segurança as conexões de agentes de cliente recebidas, crie um certificado de servidor SSL/TLS regional no Certificate Manager.
1. Gere um certificado autogerenciado e uma chave privada.
```
openssl req -x509 -newkey rsa:2048 -nodes \
    -keyout "swp.key" \
    -out "swp.crt" \
    -days 365 \
    -subj "/CN=SWP_IP_ADDRESS"
```
  Substitua SWP_IP_ADDRESS pelo endereço IP do gateway do Secure Web Proxy.
2. Para fazer upload do certificado no Certificate Manager, execute o comando gcloud certificate-manager certificates create.
```
gcloud certificate-manager certificates create SWP_CERTIFICATE_NAME \
    --location=REGION \
    --certificate-file="swp.crt" \
    --private-key-file="swp.key" \
    --project=PROJECT_ID
```
  Substitua:
  - SWP_CERTIFICATE_NAME: nome do recurso de certificado
  - REGION: região em que o certificado é criado
  - PROJECT_ID: ID do projeto do Google Cloud
Para ativar o mTLS de front-end, crie um recurso ServerTlsPolicy. Para permitir que as cargas de trabalho, como o Cloud Run, transmitam os certificados de identidade para serviços como o IAP, configure a política com clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT.

Observação: se você usar o IAP, não defina nenhum valor para o campo clientValidationTrustConfig, porque ele não é compatível.
1. Crie um arquivo chamado server-tls-policy.yaml e adicione o seguinte conteúdo:
```
name: projects/PROJECT_ID/locations/REGION/serverTlsPolicies/SERVER_TLS_POLICY_NAME
mtlsPolicy:
  clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
```
  Substitua:
  - PROJECT_ID: ID do projeto do Google Cloud .
  - REGION: região em que o ServerTlsPolicy é criado.
  - SERVER_TLS_POLICY_NAME: nome do recurso ServerTlsPolicy.
2. Para importar a política, execute o comando gcloud network-security server-tls-policies import.
```
gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME \
    --source=server-tls-policy.yaml \
    --location=REGION \
    --project=PROJECT_ID
```
Crie uma política de segurança de gateway para anexar seu tlsInspectionPolicy.
1. Crie um arquivo chamado gateway-security-policy.yaml e adicione o seguinte conteúdo:
```
name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/GATEWAY_SECURITY_POLICY_NAME
tlsInspectionPolicy: projects/PROJECT_ID/locations/REGION/tlsInspectionPolicies/TLS_INSPECTION_POLICY_NAME
```
  Substitua:
  - PROJECT_ID: ID do projeto do Google Cloud .
  - REGION: região em que o GatewaySecurityPolicy é criado.
  - GATEWAY_SECURITY_POLICY_NAME: nome do recurso GatewaySecurityPolicy.
  - TLS_INSPECTION_POLICY_NAME: nome do recurso TlsInspectionPolicy.
2. Para importar a política, execute o comando gcloud network-security gateway-security-policies import.
```
gcloud network-security gateway-security-policies import GATEWAY_SECURITY_POLICY_NAME \
    --source=gateway-security-policy.yaml \
    --location=REGION \
    --project=PROJECT_ID
```

Crie um arquivo de especificação do Secure Web Proxy chamado swp.yaml.

name: projects/PROJECT_ID/locations/REGION/gateways/SECURE_WEB_PROXY_NAME
type: SECURE_WEB_GATEWAY
addresses:
  - "SWP_IP_ADDRESS"
ports:
  - 443
routingMode: EXPLICIT_ROUTING_MODE
certificateUrls:
  - projects/PROJECT_ID/locations/REGION/certificates/SWP_CERTIFICATE_NAME
serverTlsPolicy: projects/PROJECT_ID/locations/REGION/serverTlsPolicies/SERVER_TLS_POLICY_NAME
network: projects/PROJECT_ID/global/networks/NETWORK_NAME
subnetwork: projects/PROJECT_ID/regions/REGION/subnetworks/PROXY_SUBNET_NAME
gatewaySecurityPolicy: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/GATEWAY_SECURITY_POLICY_NAME

Substitua:

PROJECT_ID: ID do projeto do Google Cloud .
REGION: região em que o gateway do Secure Web Proxy é criado
SECURE_WEB_PROXY_NAME: nome do gateway do Secure Web Proxy
SWP_IP_ADDRESS: endereço IP do gateway do Secure Web Proxy
SWP_CERTIFICATE_NAME: nome do certificado associado ao gateway do Secure Web Proxy
SERVER_TLS_POLICY_NAME: nome do recurso ServerTlsPolicy
NETWORK_NAME: nome da rede VPC.
PROXY_SUBNET_NAME: nome da sub-rede somente proxy.
GATEWAY_SECURITY_POLICY_NAME: nome do recurso GatewaySecurityPolicy.

Para importar o gateway do Secure Web Proxy, execute o comando gcloud network-services gateways import.

gcloud network-services gateways import SECURE_WEB_PROXY_NAME \
    --source=swp.yaml \
    --location=REGION \
    --project=PROJECT_ID

Para alterar esses campos em um gateway do Secure Web Proxy sem causar tempo de inatividade da carga de trabalho, faça o seguinte:

Crie outro gateway do Secure Web Proxy com um novo nome e a configuração necessária.
Atualize o recurso agentGateway (selfManaged.resourceUris) para referenciar o novo gateway do Secure Web Proxy.
Atualize o recurso EgressRouting para apontar para o novo gateway do Secure Web Proxy.
Depois de verificar se o novo gateway está gerenciando as rotas de tráfego, remova o gateway antigo do Secure Web Proxy do recurso agentGateway e exclua o recurso de gateway antigo.

Associar sua instância do Secure Web Proxy a um Gateway de Agente

Para associar sua instância do Secure Web Proxy a um recurso agentGateway, faça o seguinte:

Crie um arquivo de configuração chamado agent-gateway.yaml.
```
name: projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_NAME
selfManaged:
  resourceUris:
    - //networkservices.googleapis.com/projects/PROJECT_ID/locations/REGION/gateways/SECURE_WEB_PROXY_NAME
registries:
  - //agentregistry.googleapis.com/projects/PROJECT_ID/locations/REGION
```
Substitua:
- PROJECT_ID: ID do projeto do Google Cloud .
- REGION: região em que o Gateway de Agente é criado
- AGENT_GATEWAY_NAME: nome do Gateway de Agente
- SECURE_WEB_PROXY_NAME: nome da instância do Secure Web Proxy
Opcional: o campo registries associa o Gateway de Agente a um Agent Registry. Se você não quiser usar o Agent Registry para resolução de destino ou ferramenta, não especifique o campo registries.

Para importar o recurso agentGateway, execute o comando gcloud beta network-services agent-gateways import.

gcloud beta network-services agent-gateways import AGENT_GATEWAY_NAME \
    --source=agent-gateway.yaml \
    --location=REGION \
    --project=PROJECT_ID

Configurar vinculações de extensão e políticas de autorização

Para controlar o tráfego de saída do agente de IA, configure vinculações de extensão e políticas de autorização no recurso agentGateway. O proxy ignora todas as políticas diretamente anexadas ao recurso Gateway do Secure Web Proxy subjacente.

O Gateway de Agente é compatível com as duas camadas de governança a seguir:

Vinculações de extensão: anexe serviços externos de segurança e serviços públicos, como o IAP e o Model Armor, diretamente ao Gateway de Agente usando as Service Extensions.
Políticas de autorização: aplicam restrições de método MCP L7 e regras de rede L4.

Anexar vinculações de extensão ao Gateway de Agente

Use vinculações de extensão nas Extensões de Serviço para vincular serviços gerenciados ao Gateway de Agente para inspecionar, autenticar e controlar as interações do agente.

Etapa 1: vincular o Identity-Aware Proxy (IAP) ao Gateway de Agente

Para verificar as identidades dos autores de chamadas do agente e aplicar políticas de acesso antes que o tráfego chegue às ferramentas de destino, vincule o IAP ao Gateway de Agente fazendo o seguinte:

Crie um arquivo de configuração chamado ext-binding-iap.yaml.

name: ext-binding-iap
target:
  resources:
  - "//networkservices.googleapis.com/projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_NAME"
failOpen: false
producerExtension: iap.googleapis.com
matchConditions:
- to:
    destination:
      resources:
      - prefix: "urn:mcp"
    notDestinations:
      hosts:
      - suffix: ".googleapis.com"

Substitua:

PROJECT_ID: ID do projeto do Google Cloud .
REGION: região em que a vinculação de extensão é criada
AGENT_GATEWAY_NAME: nome do Gateway de Agente

Para importar a vinculação de extensão, execute o comando gcloud beta service-extensions extension-bindings import.

gcloud beta service-extensions extension-bindings import ext-binding-iap \
    --source=extension-binding-iap.yaml \
    --location=REGION

Para mais informações, consulte Delegar autorização ao IAP.

Etapa 2: vincular o Model Armor para higienização de comandos e respostas

Para se proteger contra injeção de comandos, conteúdo tóxico e vazamentos de dados sensíveis, vincule o Model Armor ao Gateway de Agente fazendo o seguinte:

Crie um arquivo de configuração chamado ext-binding-model-armor.yaml.

name: ext-binding-model-armor
target:
  resources:
  - "//networkservices.googleapis.com/projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_NAME"
failOpen: false
producerExtension: modelarmor.googleapis.com
producerMetadata:
  model_armor_settings: '[
    {
      "request_template_id": "projects/PROJECT_ID/locations/REGION/templates/REQUEST_TEMPLATE_ID",
      "response_template_id": "projects/PROJECT_ID/locations/REGION/templates/RESPONSE_TEMPLATE_ID"
    }
  ]'
matchConditions:
- to:
    destination:
      resources:
      - prefix: "urn:mcp"

Substitua:

PROJECT_ID: ID do projeto do Google Cloud .
REGION: região em que a vinculação de extensão é criada
AGENT_GATEWAY_NAME: nome do Gateway de Agente
REQUEST_TEMPLATE_ID: ID do modelo de solicitação do Model Armor
RESPONSE_TEMPLATE_ID: ID do modelo de resposta do Model Armor

Para importar a vinculação de extensão, execute o comando gcloud beta service-extensions extension-bindings import.

gcloud beta service-extensions extension-bindings import ext-binding-model-armor \
    --source=extension-binding-model-armor.yaml \
    --location=REGION

Para mais informações, consulte Delegar autorização ao Model Armor e Exemplo 3: ativar a inspeção profunda de payload com o Model Armor usando vinculações de extensão em Configurar políticas de autorização para o Secure Web Proxy.

Restringir ferramentas do MCP usando políticas de autorização

Para restringir a descoberta e a execução de ferramentas do agente às ferramentas aprovadas, crie e importe uma política de autorização fazendo o seguinte:

Crie um arquivo de configuração chamado authz-policy-restrict-mcp-tools.yaml.

name: authz-policy-restrict-mcp-tools
target:
  resources:
  - "projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_NAME"
policyProfile: REQUEST_AUTHZ
httpRules:
- to:
    operations:
    - mcp:
        baseProtocolMethodsOption: MATCH_BASE_PROTOCOL_METHODS
        methods:
        - name: "tools/list"
        - name: "tools/call"
          params:
          - exact: "get_weather"
          - exact: "get_location"
action: ALLOW

Substitua:

PROJECT_ID: ID do projeto do Google Cloud .
REGION: região em que a política de autorização é criada.
AGENT_GATEWAY_NAME: nome do Gateway de Agente

Para importar a política de autorização, execute o comando gcloud network-security authz-policies import.

gcloud network-security authz-policies import authz-policy-restrict-mcp-tools \
    --source=authz-policy-restrict-mcp-tools.yaml \
    --location=REGION \
    --project=PROJECT_ID

Rotear agentes pelo Gateway de Agente

Depois de configurar o Gateway de Agente e anexar políticas de autorização a ele, configure os ambientes de Agent Runtime para direcionar o tráfego de saída para a instância do Secure Web Proxy. O roteamento de tráfego de saída opera de forma transparente na camada de rede, redirecionando solicitações para o gateway sem modificar o código do aplicativo do agente.

Dependendo de onde as cargas de trabalho de IA são executadas, consulte os seguintes recursos de documentação para configurar o roteamento de saída:

GKE: use a rede de ambiente do Cloud Service Mesh para interceptar o tráfego de saída do agente no nível do nó e encaminhá-lo por um túnel HTTP CONNECT para sua instância do Secure Web Proxy. Para configurar políticas de roteamento no cluster, consulte Rotear o tráfego de saída do ambiente pelo Secure Web Proxy e Gateway de Agente para GKE.
Cloud Run: configure a saída de VPC direta para enviar o tráfego de saída do agente para sua rede VPC, em que a rede de ambiente do Cloud Run redireciona as solicitações para sua instância do Secure Web Proxy por um túnel HTTP CONNECT que carrega a identidade do agente. Para configurar o roteamento do tráfego de saída, consulte VPC direta com uma rede VPC e Gateway de Agente para o Cloud Run.

Telemetria, geração de registros e monitoramento

Quando o gateway do Secure Web Proxy está associado a um recurso do Gateway de Agente, os registros de transações são emitidos no recurso monitorado padrão networkservices.googleapis.com/Gateway do Secure Web Proxy. A geração de registros é ativada por padrão com uma taxa de amostragem de 1.0.

Logging

As entradas de registro no Cloud Logging usam o formato LoadBalancerLogEntry e contêm os seguintes campos de payload de segurança e agente de IA:

agentGatewayInfo: contém metadados sobre a transação do agente:
- agentRegistryResource: nome completo do recurso do destino correspondente do registro de agentes, como um servidor MCP ou uma habilidade.
- destinationUrn: informações sobre o URN de destino.
- mcpInfo: detalhes da chamada MCP JSON-RPC, incluindo o método, como tools/call ou resources/read, e o nome da ferramenta ou o URI do recurso.
authzPolicyInfo: resultados da avaliação de autorização (ALLOWED ou DENIED) e os nomes das políticas de correspondência
tls: detalhes da negociação de TLS e atributos de verificação do certificado do cliente criptográfico (mTLS), como clientCertPresent e clientCertSha256Fingerprint

Como monitorar métricas

O Gateway de Agente exporta as seguintes métricas para o Cloud Monitoring:

Duração do MCP:
- gcp.mcp.server.operation.duration: latência das operações que o servidor de ferramentas do MCP realiza
- gcp.mcp.client.operation.duration: duração de ida e volta de ponta a ponta de uma chamada de cliente do MCP.
Latência HTTP:
- http.server.request.duration: latência de execução para solicitações de agente recebidas que o gateway processa
- http.client.request.duration: latência de solicitações de saída do proxy para destinos externos
Capacidade de processamento de tráfego:
- gcp.server.request.total_size e gcp.server.response.total_size: tamanho em bytes das solicitações e respostas que o gateway recebe e envia
- gcp.client.request.total_size e gcp.client.response.total_size: tamanho em bytes das solicitações e respostas que o gateway envia para destinos externos

Implantar o Secure Web Proxy como um Gateway de Agente Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Visão geral

Vantagens

Arquitetura

Antes de começar

Configurar a inspeção de TLS

Implantar o Secure Web Proxy

Associar sua instância do Secure Web Proxy a um Gateway de Agente

Configurar vinculações de extensão e políticas de autorização

Anexar vinculações de extensão ao Gateway de Agente

Etapa 1: vincular o Identity-Aware Proxy (IAP) ao Gateway de Agente

Etapa 2: vincular o Model Armor para higienização de comandos e respostas

Restringir ferramentas do MCP usando políticas de autorização

Rotear agentes pelo Gateway de Agente

Telemetria, geração de registros e monitoramento

Logging

Como monitorar métricas

A seguir

Implantar o Secure Web Proxy como um Gateway de Agente