Sécuriser les déploiements d'entreprise agentifs multicloud

1. Introduction

Dans cet atelier de programmation, vous allez déployer un agent unique / plusieurs outils de manière sécurisée à l'aide de l'Agent Development Kit (ADK), d'Agent Engine et de Google Kubernetes Engine. Vous découvrirez comment un agent d'IA initié par un utilisateur dans Gemini Enterprise navigue de manière sécurisée dans Google Cloud, en s'appuyant sur GKE Gateway avec les extensions de service pour masquer les données sensibles en transit dans les réponses de l'outil MCP.

Objectifs

Déployer un agent assistant hypothécaire ADK sur Agent Engine avec l'instrumentation OpenTelemetry
Déployer des serveurs MCP de backend sur Google Kubernetes Engine (GKE) derrière une passerelle interne
Connecter Agent Engine à un VPC de projet à l'aide d'une interface PSC et d'un appairage DNS
Exposer des API REST en tant qu'outils MCP à l'aide du proxy de découverte MCP Apigee
Configurer GKE Gateway pour la sortie d'agent régie avec les extensions de service pour la rédaction DLP et l'autorisation MCP
Appliquer des garde-fous d'IA avec Model Armor pour filtrer les requêtes et les réponses

Ce dont vous avez besoin

Un navigateur Web (par exemple, Chrome)
Un projet Google Cloud avec facturation activée
Connaissances de base de Terraform, Kubernetes et Python

Cet atelier de programmation s'adresse aux développeurs et aux professionnels de la sécurité qui souhaitent déployer et sécuriser des workflows agentiques dans des environnements d'entreprise.

2. Avant de commencer

Créez un projet Google Cloud et activez les API requises.

Dans la console Google Cloud, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud .
Assurez-vous que la facturation est activée pour votre projet Cloud. Découvrez comment vérifier si la facturation est activée sur un projet.

Rôles IAM requis

Cet atelier de programmation suppose que vous disposez du rôle Propriétaire du projet pour votre projet Google Cloud.

Activer les API

Dans la console Google Cloud, cliquez sur Activer Cloud Shell. Si vous n'avez jamais utilisé Cloud Shell, un volet s'affiche et vous permet de choisir de démarrer Cloud Shell dans un environnement de confiance avec ou sans boost. Si vous êtes invité à autoriser Cloud Shell, cliquez sur Autoriser.

Dans Cloud Shell, activez toutes les API requises :

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

Installer des dépendances

Dans Cloud Shell, assurez-vous que les outils requis sont installés. Terraform, kubectl et Go sont généralement préinstallés. Vous devez installer uv (le gestionnaire de packages Python) et 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/

Définir des variables d'environnement

Définissez les variables d'environnement suivantes, qui seront utilisées tout au long de cet atelier de programmation :

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

Créer une zone DNS publique

Cet atelier de programmation nécessite qu'une zone DNS publique existe déjà dans votre projet avant d'appliquer la configuration Terraform. Cette zone est nécessaire pour la délégation de serveurs de noms. La configuration peut ainsi automatiser la création des enregistrements requis pour Certificate Manager.

Exécutez la commande suivante dans Cloud Shell pour créer la zone :

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. Cloner un dépôt GitHub

Dans un terminal sur votre machine locale, clonez le dépôt cloud-networking-solutions :
```
git clone https://github.com/googleCloudPlatform/cloud-networking-solutions.git
```

Accédez au répertoire du dépôt téléchargé :

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

4. Déployer l'infrastructure avec Terraform

Vous utiliserez Terraform pour provisionner le réseau de base, le cluster GKE et les configurations d'identité requises.

Accédez au répertoire terraform du dépôt cloné :
```
cd terraform
```
Configurez le backend Terraform. Créez un fichier backend.conf pour la configuration partielle du backend. Remplacez par un nom de bucket unique.
```
cat <<EOF > backend.conf
bucket = "<YOUR_TERRAFORM_STATE_BUCKET>"
prefix = "terraform"
EOF
```

Copiez l'exemple de fichier de variables et mettez-le à jour avec les valeurs de votre projet :
```
cp example.tfvars terraform.tfvars
```
Modifiez terraform.tfvars et remplacez les valeurs d'espace réservé.Remplacez les éléments suivants :
- project_id : ID de votre projet Google Cloud.
- organization_id : ID numérique de votre organisation GCP.
- dns_zone_domain : domaine que vous contrôlez (par exemple, demo.example.com.). Doit se terminer par un point.
Assurez-vous que les indicateurs de fonctionnalité suivants sont activés (ils sont préconfigurés dans l'exemple de fichier) :
- enable_certificate_manager = true
- enable_model_armor = true
- enable_agent_engine = true
- enable_psc_interface = true

Initialisez et appliquez la configuration Terraform :

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

5. Déployer des exemples de charges de travail avec Skaffold

Ensuite, déployez les serveurs MCP et les services de traitement externes sur votre cluster GKE.

Connectez-vous au cluster GKE créé par Terraform :

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

Revenez à la racine du projet et configurez les modèles de fichier manifeste Kubernetes. Copiez l'exemple de configuration et définissez votre ID de projet et votre domaine de base : définissez BASE_DOMAIN pour qu'il corresponde à votre environnement. Le BASE_DOMAIN doit correspondre à votre variable Terraform dns_zone_domain (sans le point à la fin).
```
export BASE_DOMAIN=example.com
```

Générez les fichiers manifestes Kubernetes et skaffold.yaml à partir des modèles :

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

Déployez tous les services de backend :

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

Déployez la configuration de la passerelle et de l'objet HTTPRoute :
```
kubectl apply -k k8s/gateway-internal/
```

6. Appliquer des garde-fous d'IA avec Model Armor

Vous pouvez déléguer les décisions concernant la sécurité du contenu, comme la suppression des requêtes nuisibles ou la prévention des fuites de données, à Model Armor.

Prérequis : attribuer des rôles IAM

Vous devez attribuer les rôles requis au compte de service GKE Gateway. Le compte de service respecte le format suivant : service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com.

Exécutez les commandes suivantes pour accorder les autorisations nécessaires :

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

Créer l'extension d'autorisation Model Armor

Définissez une extension qui pointe vers le service Model Armor dans votre région. Enregistrez cette configuration sous le nom ma-content-authz-extension.yaml.

Exportez l'ID du modèle Model Armor créé par 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

Créer la règle d'autorisation Model Armor

Créez une règle qui associe l'extension Model Armor à votre Agent Gateway. Enregistrez cette configuration sous le nom 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. Configurer Gemini Enterprise

Activer l'observabilité

L'agent hypothécaire est déployé avec l'instrumentation OpenTelemetry et les variables d'environnement de télémétrie suivantes activées par défaut :

GOOGLE_CLOUD_AGENT_ENGINE_ENABLE_TELEMETRY=true
OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT=true
OTEL_TRACES_SAMPLER=parentbased_traceidratio

Pour savoir comment configurer les traces et les spans dans Gemini Enterprise, consultez Gérer les paramètres d'observabilité.

Activer Model Armor dans Gemini Enterprise

Appliquez le filtrage Model Armor à l'assistant Gemini Enterprise pour filtrer les requêtes utilisateur et les réponses du modèle. Les applications Gemini Enterprise mondiales nécessitent un modèle Model Armor dans la région us multirégionale. Terraform déploie donc un modèle distinct à cet effet.

Récupérez le nom du modèle à partir de la sortie Terraform :

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

Récupérez l'ID d'application de votre instance Gemini Enterprise :

Dans la console Google Cloud, accédez à la page Gemini Enterprise.
Dans le menu de navigation, cliquez sur "Applications".
Copier l'ID de l'instance Gemini Enterprise

Exportez l'ID en tant que variable d'environnement.

export APP_ID=<PASTE_APP_ID>

Corrigez l'assistant pour activer 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"
      }
    }
  }'

Définissez failureMode sur FAIL_OPEN pour autoriser les requêtes lorsque Model Armor n'est pas disponible, ou sur FAIL_CLOSED pour les bloquer.

8. Déployer un agent et l'ajouter dans Gemini Enterprise

Obtenir les détails de l'autorisation

Suivez ces étapes pour obtenir les détails de l'autorisation.

Dans la console Google Cloud, sur la page "API et services", accédez à la page "Identifiants".
Accéder à Identifiants
Cliquez sur "Créer des identifiants", puis sélectionnez "ID client OAuth".
Dans "Type d'application", sélectionnez "Application Web".
Dans la section "URI de redirection autorisés", ajoutez les URI suivants :

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

Cliquez sur Créer.
Exportez l'ID client et le code secret du client pour le déploiement.

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

Déployer l'agent hypothécaire

Le script src/mortgage-agent/deploy_agent.py déploie l'agent ADK sur Agent Engine et l'enregistre éventuellement dans Gemini Enterprise. Pour en savoir plus sur le flux d'enregistrement Gemini Enterprise, consultez Enregistrer et gérer un agent A2A.

Exporter des variables à partir du déploiement 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)

Installez les dépendances et déployez :

cd src/mortgage-agent
uv sync

Déployez l'agent dans Vertex Agent Engine et enregistrez-le dans 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

Référence du flag

Option	Valeur par défaut	Description
`--project`	`$PROJECT_ID`	ID du projet GCP
`--dms-mcp-url`	(obligatoire)	URL du serveur MCP DMS
`--income-verification-url`	(obligatoire)	URL de base de l'API Income Verification. `/mcp` est ajouté automatiquement.
`--email-mcp-url`	(obligatoire)	URL du serveur MCP de messagerie
`--region`	`$REGION`	Région GCP
`--staging-bucket`	`gs://PROJECT-staging`	Bucket GCS pour la préproduction
`--display-name`	`Mortgage Assistant Agent`	Nom à afficher de l'agent déployé
`--update`	(facultatif)	Mettre à jour un agent existant sur place (transmettre le nom complet de la ressource)
`--network-attachment`	(facultatif)	Rattachement de réseau pour l'interface PSC (chemin d'accès complet ou nom)
`--dns-peering-domain`	(facultatif)	Domaine DNS pour l'appairage DNS PSC-I (doit se terminer par un point)
`--dns-peering-target-project`	(facultatif)	Projet hébergeant le réseau VPC cible pour l'appairage DNS
`--dns-peering-target-network`	(facultatif)	Nom du réseau VPC pour l'appairage DNS
`--enable-agent-identity`	`false`	Activer les identifiants de moindre privilège par agent
`--ge-deploy`	`false`	Enregistrer l'agent dans Gemini Enterprise après le déploiement
`--app-id`	(facultatif)	ID du moteur Gemini Enterprise (obligatoire avec `--ge-deploy`)
`--oauth-client-id`	`$OAUTH_CLIENT_ID`	ID client OAuth2 (obligatoire avec `--ge-deploy`)
`--oauth-client-secret`	`$OAUTH_CLIENT_SECRET`	Code secret du client OAuth2 (obligatoire avec `--ge-deploy`)
`--model`	`gemini-3.1-flash-lite-preview`	Nom du modèle Gemini pour l'agent
`--agent-name`	`mortgage-agent`	Autorisation Gemini Enterprise et nom de l'agent
`--ge-deploy-only`	(facultatif)	Enregistrer un moteur de raisonnement existant dans Gemini Enterprise sans redéploiement (transmettre le nom complet de la ressource)

Ajouter des utilisateurs autorisés

Pour ajouter des utilisateurs autorisés à un agent ADK à l'aide de la console Google Cloud, consultez Ajouter ou modifier des utilisateurs et leurs autorisations.

9. Tester votre agent

Maintenant que vous avez déployé et configuré l'agent, GKE Gateway et tous les services de backend, testez le flux de bout en bout pour vérifier que les règles de sécurité fonctionnent comme prévu. Vous interagirez avec l'agent "mortgage-agent" dans l'interface Gemini Enterprise.

Accéder à l'agent

Accédez à la page Gemini Enterprise dans la console Google Cloud.
Sélectionnez l'application Gemini Enterprise que vous avez configurée précédemment et dans laquelle l'agent hypothécaire est enregistré.
Dans l'onglet "Vue d'ensemble", accédez à l'URL indiquée dans la section "Votre application Web Gemini Enterprise est prête".
Sélectionnez l'onglet "Agent" dans le menu de gauche intitulé Galerie d'agents.
Vous devriez maintenant pouvoir discuter avec l'agent "Assistant hypothécaire".

Scénario de test 1 : le "chemin idéal" – Résumer des données avec masquage des informations permettant d'identifier personnellement l'utilisateur

Ce test vérifie que l'agent peut accéder aux systèmes backend via la passerelle de l'agent et que les règles de protection contre la perte de données sont appliquées pour masquer les informations sensibles.

Envoyez le prompt suivant à l'agent Assistant hypothécaire :

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?

Que se passe-t-il en arrière-plan ?
- L'agent Gemini Enterprise formule des requêtes aux outils nécessaires (par exemple, le système de gestion de documents (DMS) pour les déclarations de revenus, l'API Income Verification).
- Model Armor inspecte les charges utiles des requêtes et des réponses pour détecter les menaces.
- La "stratégie d'autorisation basée sur le contenu" que vous avez configurée déclenche l'extension DLP personnalisée (dlp-content-authz-ext). Cette extension inspecte les données extraites des systèmes backend.
- Le service DLP masque toutes les informations permettant d'identifier personnellement les utilisateurs (comme les numéros de sécurité sociale) dans les données de la déclaration d'impôts avant qu'elles n'atteignent l'agent.
Résultat attendu : l'agent renvoie un récapitulatif des déclarations de revenus et un état de la validation des revenus. Examinez attentivement le résumé fourni par l'agent. Vous devriez constater que les informations sensibles, comme les numéros d'identification fiscale (numéros de sécurité sociale), ont été remplacées par des espaces réservés (par exemple, [REDACTED]). Cela confirme l'exécution de la règle DLP via la passerelle.

Observabilité et audit

Tout au long de ces tests, la plate-forme d'agent et les services associés collectent des données télémétriques :

Cloud Logging : les journaux détaillés de GKE Gateway, des charges de travail GKE et d'autres services fournissent un journal d'audit des requêtes, des évaluations des règles et des résultats.
Cloud Trace : l'instrumentation OpenTelemetry configurée dans les services d'agent et de backend vous permet de visualiser l'intégralité du flux d'appels, de Gemini Enterprise à la passerelle GKE, en passant par les outils de backend. C'est un avantage précieux pour le débogage et la compréhension du cycle de vie des requêtes.

Affichez les traces de vos sessions :

Dans la console Google Cloud, accédez à la page Vertex AI Agent Engine.
Accédez à Agent Engine. Les instances Agent Engine faisant partie du projet sélectionné apparaissent dans la liste. Vous pouvez utiliser le champ "Filtrer" pour filtrer la liste en fonction de la colonne de votre choix.
Cliquez sur le nom de votre instance Agent Engine.
Cliquez sur l'onglet "Traces".
Vous pouvez sélectionner la vue "Session" ou "Span".
Cliquez sur une session ou un segment pour inspecter les détails de la trace, y compris un graphe orienté acyclique (DAG) de ses segments, ses entrées et sorties, et ses attributs de métadonnées.

10. Facultatif : Transcoder les API REST en MCP avec Apigee

Bien que notre service de validation des revenus soit compatible avec le protocole Model Context, de nombreux anciens systèmes d'entreprise ne fournissent que des API RESTful. Dans cette étape facultative, vous allez utiliser le proxy de découverte Apigee MCP pour transcoder le point de terminaison REST du service de validation des revenus en outil MCP. Cela vous permet d'appliquer les règles avancées de gouvernance, de limitation du débit et de sécurité d'Apigee à vos anciens outils.

Pour en savoir plus, consultez la présentation d'Apigee MCP.

Prérequis

Avant de continuer, assurez-vous d'avoir provisionné et configuré le hub d'API Apigee. Suivez les étapes de la documentation Provision API Hub pour le configurer et associer votre instance Apigee.

Étape 1 : Créez un rattachement de service pour Apigee

Pour permettre à Apigee d'accéder à vos services internes exécutés sur GKE, vous devez créer un rattachement de service.

Recherchez la règle de transfert de la passerelle GKE interne :

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}')

Créez le rattachement de service :

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

Étape 2 : Activez Apigee avec Terraform

À présent, mettez à jour la configuration de votre infrastructure pour provisionner l'organisation et l'instance Apigee.

Accédez au répertoire terraform :
```
cd terraform
```
Modifiez terraform.tfvars et définissez enable_apigee = true.
Appliquez les modifications :
```
terraform apply
```

Étape 3 : Définir la spécification OpenAPI

Apigee utilise des définitions OpenAPI (OAS) standards pour découvrir et transcoder les outils. Créez un fichier nommé income-verification-oas.yaml avec le contenu suivant :

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

Étape 4 : Déployer le proxy de découverte Apigee MCP

Le proxy de découverte MCP est un proxy Apigee spécialisé qui fait office de serveur MCP.

Dans l'UI Apigee, accédez à Développer > Proxys d'API.
Cliquez sur Créer, puis sélectionnez Proxy de découverte MCP.
Nommez le proxy income-verification-discovery.
Dans la section Spécification OpenAPI, importez le fichier income-verification-oas.yaml que vous avez créé.
Définissez le groupe d'environnements sur celui où votre passerelle interne est accessible.
Cliquez sur Déployer.

(Facultatif) Ajoutez une règle de sécurité.

Avant de déployer ou de partager votre proxy, vous devez le sécuriser. Vous pouvez ajouter des règles pour appliquer des exigences de sécurité, telles que des jetons OAuth ou des clés API. Pour savoir comment ajouter une stratégie de sécurité, consultez la documentation Apigee sur la sécurisation des API.

Étape 5 : Vérifiez l'accès à l'outil de transcodage

Une fois déployé, Apigee transcode automatiquement le point de terminaison POST /verify en outil MCP verifyApplicant.

Listez les outils disponibles via le point de terminaison MCP 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": {}
  }'

L'outil verifyApplicant devrait s'afficher dans la réponse, transcodé à partir de votre spécification REST. Vous pouvez désormais appeler cet outil via Apigee. Apigee gérera la traduction vers le service REST sous-jacent tout en appliquant les règles de sécurité que vous avez configurées.

Étape 6 : Mettez à jour l'agent hypothécaire pour qu'il utilise Apigee

Maintenant qu'Apigee a transcodé votre API REST en un outil conforme à MCP, vous devez mettre à jour la configuration de déploiement de l'agent. En pointant l'agent vers le point de terminaison Apigee, toutes les demandes de validation des revenus bénéficieront désormais de la sécurité, de la journalisation et de la gestion du trafic de niveau entreprise d'Apigee.

Identifiez votre URL Apigee MCP : votre point de terminaison doit suivre le modèle https://api.internal.${DNS_PEERING_DOMAIN%%.}/income-verification-discovery/mcp.

Réexécutez le script de déploiement : utilisez l'indicateur --update avec le nouveau --income-verification-url. Cela met à jour l'agent existant dans Agent Engine sans nécessiter une suppression complète.

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}

Vérifiez la modification : revenez à l'interface Gemini Enterprise et demandez à l'agent de vérifier les revenus d'un candidat.
```
"Can you verify the joint income for the Sterlings using the verification service?"
```
Dans l'onglet Apigee Debug (Débogage Apigee), vous devriez maintenant voir la requête JSON-RPC entrante de la passerelle GKE transformée en requête POST REST standard pour votre service GKE de backend.

11. Effectuer un nettoyage

Pour éviter que les ressources créées dans cet atelier de programmation soient facturées sur votre compte Google Cloud, supprimez-les lorsque vous avez terminé.

Supprimez le rattachement de service s'il a été créé manuellement :

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

Accédez au répertoire terraform et détruisez toutes les ressources :
```
cd terraform
terraform destroy
```
Vous pouvez également supprimer entièrement le projet Google Cloud :
```
gcloud projects delete ${PROJECT_ID}
```

12. Félicitations

Vous avez terminé cet atelier de programmation et appris à sécuriser les déploiements d'agents d'entreprise multicloud.

Sujets abordés

Déployer un agent assistant hypothécaire ADK sur Agent Engine avec instrumentation OpenTelemetry
Déploiement de serveurs MCP de backend sur GKE derrière une passerelle interne
Connecté Agent Engine à un VPC de projet à l'aide d'une interface PSC et de l'appairage DNS
Passerelle GKE configurée pour la sortie d'agent contrôlée avec masquage DLP et autorisation MCP
Garde-fous de l'IA appliquée avec Model Armor pour le filtrage des requêtes et des réponses
API REST transcodées vers MCP à l'aide du proxy de découverte MCP Apigee (facultatif)

Étapes suivantes

Explorer Model Armor
En savoir plus sur Agent Engine
Découvrir Gemini Enterprise