Delegar autorização com Service Extensions

Use esta página para saber como delegar a autorização do Gateway de Agente ao Identity-Aware Proxy, ao Model Armor e a outros mecanismos de autorização personalizados usando Service Extensions.

Políticas e extensões de autorização

As políticas de autorização permitem aplicar controle de acesso e políticas de governança centralizados ao tráfego que passa pelos endpoints publicados pelo Gateway de Agente. Para lidar com controle de acesso complexo, segurança de conteúdo e decisões de governança, o Gateway de Agente permite configurar políticas de autorização com extensões de autorização que permitem delegar decisões de autorização e segurança de conteúdo aos mecanismos de autorização designados de sua escolha.

Uma extensão de autorização intercepta solicitações que passam por uma implantação do Gateway de Agente e faz uma chamada gRPC em tempo real para o serviço de autorização designado. Isso permite que o serviço inspecione, modifique ou bloqueie o tráfego antes que ele continue até o destino. É possível delegar autorização a serviços Google Cloud como o Identity-Aware Proxy, o Model Armor e as políticas de governança semântica, ou a qualquer mecanismo de autorização personalizado de sua escolha.

As políticas de autorização usam perfis de política para determinar o tipo de dados de tráfego enviados à extensão de autorização:

  • Autorização baseada em solicitação (REQUEST_AUTHZ): avalia os cabeçalhos de solicitação HTTP antes que qualquer payload do aplicativo seja processado. Esse perfil é usado para confirmação de identidade e controle de acesso, como delegação de autorização ao Identity-Aware Proxy.
  • Autorização baseada em conteúdo (CONTENT_AUTHZ): avalia payloads completos de solicitação e resposta HTTP. Esse perfil é usado para inspeção detalhada de conteúdo e segurança de IA, como delegação ao Model Armor para segurança de comandos e respostas ou às políticas de governança semântica para aplicação de restrições de linguagem natural.

Os mecanismos de autorização personalizados podem usar extensões REQUEST_AUTHZ ou CONTENT_AUTHZ, dependendo se inspecionam cabeçalhos ou payloads completos de aplicativos.

É possível configurar extensões de autorização separadamente para políticas baseadas em solicitações e em conteúdo ou combinar as duas em um gateway para segurança abrangente. Para configurações recomendadas, consulte Configuração recomendada de entrada e saída.

Para saber mais sobre políticas de autorização, perfis de política e casos de uso, consulte Visão geral das políticas de autorização.

Para ter segurança abrangente em todo o ciclo de vida do agente, recomendamos o seguinte padrão de arquitetura de vários gateways:

  • Gateways do cliente para o agente:os gateways do cliente para o agente (entrada) só aceitam uma única política CONTENT_AUTHZ. Isso significa que não é possível usar o Model Armor e as políticas de governança semântica juntos no ingresso. Recomendamos usar uma política do Model Armor CONTENT_AUTHZ para se proteger contra ataques de injeção de comandos. No entanto, se você quiser usar uma extensão de política de governança semântica, verifique se o Model Armor não está configurado no gateway. Outros tipos de extensões de serviço não são compatíveis com gateways de entrada.

  • Gateways de agente para qualquer lugar:os gateways de agente para qualquer lugar (saída) aceitam até quatro políticas de autorização. Os gateways de saída são compatíveis com perfis de política REQUEST_AUTHZ e CONTENT_AUTHZ, e é possível configurar várias políticas de cada tipo dentro desse limite.

    Recomendamos a seguinte configuração:

    • Uma política REQUEST_AUTHZ que delega ao Identity-Aware Proxy (IAP) a autorização da identidade do agente.
    • Uma ou mais políticas de CONTENT_AUTHZ que delegam outras decisões ao Model Armor ou políticas de governança semântica para proteger contra a exposição de dados sensíveis e aplicar restrições de linguagem natural em chamadas e respostas de ferramentas de saída.

    Consulte Avaliação de políticas na saída para mais informações sobre como as políticas são avaliadas.

Essa topologia de vários gateways garante que o Model Armor analise os comandos recebidos, enquanto a IAP, o Model Armor e as políticas de governança semântica analisam as respostas enviadas.

Avaliação da política na saída

Quando várias políticas de autorização são configuradas em um gateway de saída, elas são avaliadas sequencialmente de acordo com o tipo de perfil da política:

  1. Políticas REQUEST_AUTHZ (com base em cabeçalho): esses tipos de política são avaliados primeiro. Por exemplo, uma extensão do IAP verifica a identidade mTLS do agente de chamada e valida as políticas de permissão do IAM antes que qualquer conteúdo seja processado. Se a solicitação não passar nessa verificação, ela será rejeitada imediatamente.
  2. Políticas CONTENT_AUTHZ (baseadas em conteúdo): esses tipos de política são avaliados a seguir. Se o pedido passar na verificação com base no cabeçalho, o payload será transmitido para a extensão de autorização com base no conteúdo (como o mecanismo de política de governança semântica) para inspeção detalhada de conteúdo e avaliação de conformidade.

Antes de começar

Antes de começar, verifique se você atende aos seguintes requisitos:

  • O Gateway de Agente é implantado. Consulte Configurar o gateway de agente.

  • Você precisa ter a permissão networkservices.agentGateways.use do IAM no recurso implantado do Gateway de Agente para anexar políticas de autorização ao gateway.

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

Esta seção mostra como configurar políticas de autorização que delegam decisões de autorização e segurança de conteúdo ao Identity-Aware Proxy, Model Armor e outros serviços personalizados.

Delegar autorização ao IAP

É possível configurar uma extensão de autorização de solicitação para delegar decisões de acesso para políticas de autorização ao IAP.

As etapas a seguir mostram como configurar uma extensão de autorização com uma política de autorização para uma instância do gateway de agente.

  1. Antes de começar: desative a aplicação da restrição de política gerenciada da organização Desativar a vinculação do acesso da política ao recurso (constraints/iam.managed.disableAccessPolicyBindings). Por padrão, essa restrição booleana é ativada para novas organizações e impede que você vincule uma política de acesso unificado do IAM a um recurso. Para mais informações, consulte Atualizar políticas com regras booleanas.

  2. Crie as políticas de saída do IAM necessárias para seus agentes e ferramentas. Para mais informações, consulte Criar políticas de agente do IAM.

  3. Consulte Configurar o gateway de agente no modo Agente para qualquer lugar (saída) para ativar o IAP ao criar o gateway de agente (usando o parâmetro Autorização de acesso).

  4. Configure uma extensão de autorização para apontar para o IAP.

    1. Defina a extensão em um arquivo YAML. Use os valores de amostra fornecidos. Se você quiser implantar a extensão em um modo de simulação somente de auditoria para testar a política de autorização sem aplicá-la, especifique o campo iamEnforcementMode no bloco metadata.

      cat >iap-request-authz-extension.yaml <<EOF
name: my-iap-request-authz-ext
service: iap.googleapis.com
failOpen: false
timeout: 1s
metadata:
  iapPolicyVersion: "V2"
EOF

      Se você quiser implantar a extensão em um modo de simulação somente de auditoria para testar a política de autorização sem aplicá-la, especifique o campo iamEnforcementMode no bloco metadata. Isso permite verificar sua política e minimizar o risco de interrupção do tráfego devido a erros de configuração:

      cat >iap-request-authz-extension.yaml <<EOF
name: my-iap-request-authz-ext
service: iap.googleapis.com
failOpen: false
timeout: 1s
metadata:
  iapPolicyVersion: "V2"
  iamEnforcementMode: "DRY_RUN"
EOF

      Remova o campo iamEnforcementMode: "DRY_RUN" do bloco metadata quando estiver tudo pronto para começar a aplicar políticas.

    2. Importe a extensão de autorização. Use o comando gcloud service-extensions authz-extensions import com os seguintes valores de exemplo.

      gcloud service-extensions authz-extensions import my-iap-request-authz-ext \
    --source=iap-request-authz-extension.yaml \
    --location=LOCATION

  5. No mesmo projeto, configure uma política de autorização que delegue a decisão à extensão.

    1. Defina uma política de autorização que associe a extensão my-iap-request-authz-ext ao seu gateway. Use os valores de amostra fornecidos.

      cat >iap-request-authz-policy.yaml <<EOF
name: my-iap-request-authz-policy
target:
  resources:
    - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
policyProfile: REQUEST_AUTHZ
action: CUSTOM
customProvider:
  authzExtension:
    resources:
      - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/my-iap-request-authz-ext"
EOF

      Substitua PROJECT_ID pelo ID do projeto.

    2. Importe a política de autorização para o projeto. Use o comando gcloud network-security authz-policies import com os seguintes valores de exemplo.

      gcloud network-security authz-policies import my-iap-request-authz-policy \
    --source=iap-request-authz-policy.yaml \
    --location=LOCATION

Delegar autorização ao Model Armor

É possível configurar uma extensão de autorização para delegar decisões de segurança de conteúdo para políticas de autorização ao Model Armor.

O exemplo a seguir mostra como configurar uma extensão de autorização com uma política de autorização para o Gateway de Agente.

Console

Para usar o Google Cloud console para ativar o Model Armor para o Gateway de Agente, siga estas etapas:

  1. Crie os modelos do Model Armor necessários.

  2. Consulte Configurar o Gateway de Agente para ativar o Model Armor ao criar o Gateway de Agente (usando a caixa de seleção Ativar o Model Armor). Os modelos do Model Armor são compatíveis com os modos cliente-agente e agente-em-qualquer-lugar.

  3. Ao usar o Model Armor, você precisa conceder à conta de serviço do Agent Gateway as permissões necessárias para usar os modelos do Model Armor. A conta de serviço tem o formato: service-PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com, em que PROJECT_NUMBER é o número do projeto em que você criou o gateway.

    É necessário concluir esta etapa mesmo que o gateway e os modelos estejam no mesmo projeto. Conceda os seguintes papéis:

    • Os papéis roles/modelarmor.calloutUser e roles/serviceusage.serviceUsageConsumer no projeto que contém o gateway.
    • A função roles/modelarmor.user no projeto que contém os modelos do Model Armor.

    Você precisará usar a CLI gcloud para concluir esta etapa.

    gcloud projects add-iam-policy-binding GATEWAY_PROJECT_ID \
    --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com \
    --role=roles/modelarmor.calloutUser
gcloud projects add-iam-policy-binding GATEWAY_PROJECT_ID \
    --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com \
    --role=roles/serviceusage.serviceUsageConsumer
gcloud projects add-iam-policy-binding MODEL_ARMOR_PROJECT_ID \
    --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com \
    --role=roles/modelarmor.user

    Substitua:

    • GATEWAY_PROJECT_ID: o ID do projeto em que você criou o gateway.
    • GATEWAY_PROJECT_NUMBER: o número do projeto em que você criou o gateway.
    • MODEL_ARMOR_PROJECT_ID: o ID do projeto que contém o modelo do Model Armor.

    Se você estiver usando o Gateway de Agente para o Agent Runtime, o agente de serviço do Agent Runtime também vai precisar dessas permissões, conforme documentado em Encaminhar o tráfego do Agent Runtime pelo Gateway de Agente.

gcloud

  1. Crie os modelos do Model Armor necessários.

  2. Ao usar o Model Armor, você precisa conceder à conta de serviço do Agent Gateway as permissões necessárias para usar os modelos do Model Armor. A conta de serviço tem o formato: service-PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com, em que PROJECT_NUMBER é o número do projeto em que você criou o gateway.

    É necessário concluir esta etapa mesmo que o gateway e os modelos estejam no mesmo projeto. Conceda os seguintes papéis:

    • Os papéis roles/modelarmor.calloutUser e roles/serviceusage.serviceUsageConsumer no projeto que contém o gateway.
    • A função roles/modelarmor.user no projeto que contém o modelo do Model Armor.
    gcloud projects add-iam-policy-binding GATEWAY_PROJECT_ID \
    --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com \
    --role=roles/modelarmor.calloutUser
gcloud projects add-iam-policy-binding GATEWAY_PROJECT_ID \
    --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com \
    --role=roles/serviceusage.serviceUsageConsumer
gcloud projects add-iam-policy-binding MODEL_ARMOR_PROJECT_ID \
    --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com \
    --role=roles/modelarmor.user

    Substitua:

    • GATEWAY_PROJECT_ID: o ID do projeto em que você criou o gateway.
    • GATEWAY_PROJECT_NUMBER: o número do projeto em que você criou o gateway.
    • MODEL_ARMOR_PROJECT_ID: o ID do projeto que contém o modelo do Model Armor.

  3. Configure a extensão de autorização para apontar para o Model Armor.

    1. Defina a extensão em um arquivo YAML. Use os valores de amostra fornecidos.

      cat >ma-content-authz-extension.yaml <<EOF
name: my-ma-content-authz-ext
service: modelarmor.LOCATION.rep.googleapis.com
metadata:
  model_armor_settings: '[
    {
    "response_template_id": "projects/MODEL_ARMOR_PROJECT_ID/locations/LOCATION/templates/TEMPLATE_ID",
    "request_template_id": "projects/MODEL_ARMOR_PROJECT_ID/locations/LOCATION/templates/TEMPLATE_ID"
    }
  ]'
failOpen: false
timeout: 1s
EOF

    2. Importe a extensão de autorização. Use o comando gcloud service-extensions authz-extensions import com os seguintes valores de amostra.

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

  4. Configure uma política de autorização com a extensão.

    1. Defina uma política de autorização que associe a extensão my-ma-content-authz-ext a um gateway de agente.

      Agente para qualquer lugar 

      cat >ma-content-authz-policy.yaml <<EOF
name: my-ma-content-authz-policy
target:
  resources:
    - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
policyProfile: CONTENT_AUTHZ
action: CUSTOM
customProvider:
  authzExtension:
    resources:
      - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/my-ma-content-authz-ext"
httpRules:
  - to:
      operations: [ { "paths": [ { "prefix": "/" } ] } ]
    when: >
      request.headers['content-type'] == 'application/json' ||
      request.headers['content-type'].startsWith('text/')
EOF

      Observe o seguinte:

      • O valor de policyProfile está definido como CONTENT_AUTHZ. Isso indica que o provedor de política personalizada processa o tráfego de solicitação e resposta, incluindo o corpo da solicitação.

      • O parâmetro httpRules demonstra como usar atributos da CEL para criar condições que correspondam ao tráfego específico que você quer encaminhar ao Model Armor para avaliação. Neste exemplo, as regras correspondem a todo o tráfego com tipos de conteúdo application/json ou text/. Recomendamos usar essas regras para limitar a avaliação do Model Armor ao tráfego relevante. Isso permite rotear o tráfego compatível de API LLM, MCP e A2A para o Model Armor, excluindo o tráfego interno, como chamadas gRPC do agente.

      Do cliente para o agente 

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

      O valor de policyProfile está definido como CONTENT_AUTHZ. Isso indica que o provedor de política personalizada processa o tráfego de solicitação e resposta, incluindo o corpo da solicitação.

    2. Importe a política de autorização para o projeto. Use o comando gcloud network-security authz-policies import com os seguintes valores de exemplo.

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

Delegar autorização a extensões de autorização personalizadas

É possível configurar extensões de autorização personalizadas para delegar decisões a serviços personalizados. Essas extensões personalizadas podem segmentar apenas nomes de domínio totalmente qualificados (FQDNs).

Quando você usa destinos FQDN, a extensão usa o protocolo HTTP2 com criptografia TLS para se comunicar com endpoints na porta 443. No entanto, a extensão não valida o certificado do servidor. Portanto, para aumentar a segurança, verifique se os endpoints resolvidos estão na rede VPC. Verifique também se o peering de DNS está configurado entre o projeto do Gateway de Agente e a rede VPC.

  1. Para configurar uma extensão de autorização com uma política de autorização para um FQDN específico, como mycustomauthz.internal.net, especifique-o como o valor de service no arquivo YAML da extensão, conforme mostrado no exemplo a seguir. Este exemplo pressupõe que você implantou um servidor na sua rede VPC implementando o protocolo ext_proc no modo de processamento de corpo FULL_DUPLEX_STREAMED.

    cat >custom-authz-extension.yaml <<EOF
name: my-custom-authz-ext
service: mycustomauthz.internal.net
failOpen: false
timeout: 1s
EOF

  2. Crie a extensão de autorização para apontar para o serviço personalizado.

    gcloud beta service-extensions authz-extensions import custom-authz-extension \
  --source=custom-authz-extension.yaml \
  --location=LOCATION

  3. Depois de criar a extensão, configure uma política de autorização CUSTOM que delega decisões à extensão de autorização.

      cat >authz-policy.yaml <<EOF
  name: authz-with-extension
  target:
    resources:
      - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
  policyProfile: CONTENT_AUTHZ
  action: CUSTOM
  customProvider:
    authzExtension:
      resources:
        - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/custom-authz-extension"
  EOF

  4. Crie a política de autorização.

    gcloud network-security authz-policies import authz-policy-with-extension \
--source=authz-policy.yaml \
--location=LOCATION

Quando uma extensão de autorização é associada a uma política de autorização usando o perfil CONTENT_AUTHZ, conforme demonstrado neste exemplo, o gateway invoca a extensão para payloads de solicitação e resposta (cabeçalhos e corpos), permitindo inspeção profunda de conteúdo, restrições de comandos e limpeza de dados para o tráfego do seu agente. Por padrão, as políticas CONTENT_AUTHZ usam o protocolo ext_proc do Envoy no modo FULL_DUPLEX_STREAMED para processar eventos de corpo.

Combinar a autorização da IAP com as proteções do Model Armor

Para uma segurança abrangente, recomendamos que você configure uma política de autorização PERSONALIZADA com um perfil de política REQUEST_AUTHZ e outra política de autorização PERSONALIZADA com um perfil de política CONTENT_AUTHZ.

O exemplo a seguir usa a IAP como um sistema de autorização de solicitação centralizado e o Model Armor para proteções de IA. Como mostrado nos exemplos anteriores, é possível trocar cada um deles por extensões de serviço para usar suas próprias soluções personalizadas.

  1. Configure uma extensão de autorização REQUEST_AUTHZ que delega ao IAP e uma política de autorização que aponta para a extensão.

    1. Defina a extensão de autorização. O campo iapPolicyVersion em metadata é obrigatório.

      cat >iap-extension.yaml <<EOF
name: iap-extension
service: iap.googleapis.com
failOpen: false
timeout: 1s
metadata:
  iapPolicyVersion: "V2"
EOF

    2. Crie a extensão de autorização.

      gcloud service-extensions authz-extensions import iap-extension \
--source=iap-extension.yaml \
--location=LOCATION

      Substitua LOCATION pela região da extensão.

    3. Configure a política de autorização REQUEST_AUTHZ que delega à extensão.

      cat >authz-policy-request-authz.yaml <<EOF
name: authz-iap
target:
  resources:
  - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
policyProfile: REQUEST_AUTHZ
action: CUSTOM
customProvider:
  authzExtension:
    resources:
    - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/iap-extension"
EOF

      Substitua:

      • PROJECT_ID: o ID do projeto.
      • LOCATION: a localização dos recursos.
      • AGENT_GATEWAY_NAME: o nome do Gateway de Agente.

    4. Crie a política de autorização.

      gcloud network-security authz-policies import authz-iap \
--source=authz-policy-request-authz.yaml \
--location=LOCATION

  2. Configure uma extensão de autorização CONTENT_AUTHZ que delega ao Model Armor e uma política de autorização que aponta para a extensão.

    1. Defina a extensão.

      cat >ma-extension-file.yaml <<EOF
name: ma-extension
service: modelarmor.LOCATION.rep.googleapis.com
metadata:
  model_armor_settings: '[
    {
    "response_template_id": "projects/MODEL_ARMOR_PROJECT_ID/locations/LOCATION/templates/RESPONSE_TEMPLATE_ID",
    "request_template_id": "projects/MODEL_ARMOR_PROJECT_ID/locations/LOCATION/templates/REQUEST_TEMPLATE_ID"
    }
  ]'
failOpen: false
timeout: 1s
EOF

      Substitua:

      • LOCATION: a região em que seus modelos do Model Armor estão localizados.
      • MODEL_ARMOR_PROJECT_ID: o ID do projeto que contém os modelos do Model Armor.
      • RESPONSE_TEMPLATE_ID: o ID do modelo de resposta.
      • REQUEST_TEMPLATE_ID: o ID do modelo de solicitação.

    2. Crie a extensão de autorização.

      gcloud service-extensions authz-extensions import ma-extension \
--source=ma-extension-file.yaml \
--location=LOCATION

    3. Configure a política de autorização CONTENT_AUTHZ que delega à extensão.

      cat >authz-policy-content-authz.yaml <<EOF
name: authz-ma
target:
  resources:
  - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
policyProfile: CONTENT_AUTHZ
action: CUSTOM
customProvider:
  authzExtension:
    resources:
    - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/ma-extension"
EOF

    4. Crie a política de autorização.

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

Quando uma extensão de autorização é associada a um perfil CONTENT_AUTHZ, ela recebe todos os eventos ext_proc, incluindo cabeçalhos de solicitação e resposta, corpo e trailers. Se a extensão de autorização baseada em ext_proc for capaz de processar a autorização no momento da solicitação e a autorização baseada em conteúdo, recomendamos configurar uma única política de autorização CUSTOM com o perfil de política CONTENT_AUTHZ. Essa política precisa apontar para sua extensão de autorização versátil. Essa abordagem permite os dois tipos de autorização por uma única extensão e conexão ext_proc, o que pode melhorar os perfis de latência.

Delegar autorização às políticas de governança semântica

É possível configurar uma extensão de autorização para delegar decisões de restrição de linguagem natural e de controle de intenção para políticas de autorização ao mecanismo de política de governança semântica (semanticGovernancePolicyEngine).

Para saber como provisionar o Policy Engine e criar a política de autorização CONTENT_AUTHZ e a vinculação de extensão de autorização necessárias no gateway, consulte Conectar o Policy Engine ao Gateway de Agente.

Autorização com base em atributos do protocolo MCP

O Gateway de Agente analisa o payload do protocolo MCP em uma solicitação e disponibiliza os atributos extraídos para políticas de autorização.

É possível restringir o acesso com base em parâmetros de método do MCP, como os nomes de ferramentas específicas. Nesta seção, mostramos dois exemplos, um para uma política ALLOW e outro para DENY.

  1. Configure a política de autorização.

    Exemplo de política de ALLOW

    Este exemplo permite o acesso a um conjunto específico de ferramentas no servidor MCP e aos recursos do protocolo de base, mas não permite o acesso a comandos e recursos.

    Ao escrever uma política ALLOW, especifique baseProtocolMethodsOption: MATCH_BASE_PROTOCOL_METHODS para que RPCs do MCP não relacionados ao acesso, como inicialização, geração de registros, conclusão, notificações e ping, continuem funcionando. Caso contrário, não será possível estabelecer uma sessão do MCP.

    cat >authz-policy-restrict-tools.yaml <<EOF
name: my-authz-policy-restrict-tools
target:
  resources:
  - "projects/PROJECT_ID/locations/LOCATION/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
EOF

    Exemplo de política de DENY

    Este exemplo não permite todos os comandos/ acessos de método a um servidor MCP por trás de um Gateway de Agente.

    cat >authz-policy-disallow-prompts.yaml <<EOF
name: my-authz-policy-disallow-prompts
target:
  resources:
  - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
policyProfile: REQUEST_AUTHZ
httpRules:
- to:
    operations:
    - mcp:
        methods:
        - name: "prompts"
action: DENY
EOF

  2. Crie a política de autorização.

    gcloud network-security authz-policies import AUTHZ_POLICY_NAME \
--source=AUTH_POLICY_YAML_FILE_PATH \
--location=LOCATION

    Substitua:

    • AUTHZ_POLICY_NAME: o nome da política de autorização.
    • AUTH_POLICY_YAML_FILE_PATH: o caminho para o arquivo YAML da política de autorização.
    • LOCATION: a localização dos recursos.

Limitações

As seguintes limitações se aplicam ao usar políticas de autorização:

  • O número máximo de políticas de autorização por gateway depende do modo do gateway:

    • Para gateways do tipo "Agente para qualquer lugar" (saída), é possível configurar até quatro políticas de autorização por gateway, independente do perfil da política (REQUEST_AUTHZ ou CONTENT_AUTHZ).
    • Para gateways de cliente para agente (entrada), é possível configurar no máximo uma política de CONTENT_AUTHZ.

    Para mais informações, consulte Configuração recomendada de entrada e saída.

  • Se você usar extensões de autorização personalizadas com o perfil CONTENT_AUTHZ, elas precisam ser compatíveis com o protocolo ext_proc e o modo FULL_DUPLEX_STREAMED para eventos de corpo.

  • Se você configurar várias políticas de autorização personalizadas que usam o mesmo perfil, a ordem de execução delas não será garantida.

Além disso, consulte as seções a seguir para mais informações sobre as limitações das extensões de autorização:

A seguir

Codelab

Aprenda a governar cargas de trabalho com agentes com o Gateway de Agente na Gemini Enterprise Agent Platform.

Guia

Saiba como monitorar o Gateway de Agente.

Solução de problemas

Saiba como resolver problemas de conectividade do Gateway de Agente.