Zabezpieczanie wdrożeń agentów w przedsiębiorstwach w wielu chmurach

1. Wprowadzenie

W tym ćwiczeniu wdrożysz bezpiecznie pojedynczego agenta / wiele narzędzi za pomocą pakietu Agent Development Kit (ADK), Agent Engine i Google Kubernetes Engine. Dowiesz się, jak agent AI zainicjowany przez użytkownika w Gemini Enterprise bezpiecznie porusza się po Google Cloud, korzystając z GKE Gateway z rozszerzeniami usługi, aby redagować dane wrażliwe w odpowiedziach narzędzia MCP.

Czego się dowiesz

Wdrażanie agenta ADK do obsługi kredytów hipotecznych w Agent Engine z instrumentacją OpenTelemetry
Wdrażanie serwerów backendu MCP w Google Kubernetes Engine (GKE) za wewnętrzną bramą
Połącz Agent Engine z siecią VPC projektu za pomocą interfejsu PSC i połączenia równorzędnego DNS.
Udostępnianie interfejsów API typu REST jako narzędzi MCP za pomocą serwera proxy wykrywania MCP Apigee
Skonfiguruj bramę GKE na potrzeby kontrolowanego ruchu wychodzącego agenta za pomocą Service Extensions do DLP w celu redagowania i autoryzacji MCP.
Stosowanie zabezpieczeń AI za pomocą Model Armor do sprawdzania promptów i odpowiedzi

Wymagania

przeglądarka, np. Chrome;
projekt Google Cloud z włączonymi płatnościami;
podstawowa znajomość Terraform, Kubernetes i Pythona,

To ćwiczenie jest przeznaczone dla programistów i specjalistów ds. bezpieczeństwa, którzy chcą wdrażać i zabezpieczać przepływy pracy agentów w środowiskach firmowych.

2. Zanim zaczniesz

Utwórz projekt Google Cloud i włącz wymagane interfejsy API.

W konsoli Google Cloud na stronie selektora projektów wybierz lub utwórz projekt w chmurze Google Cloud .
Sprawdź, czy w projekcie Cloud włączone są płatności. Dowiedz się, jak sprawdzić, czy w projekcie są włączone płatności.

Wymagane role uprawnień

W tym ćwiczeniu zakłada się, że masz rolę Właściciel projektu w projekcie Google Cloud.

Włącz interfejsy API

W konsoli Google Cloud kliknij Aktywuj Cloud Shell. Jeśli używasz Cloud Shell po raz pierwszy, pojawi się panel z opcjami uruchomienia Cloud Shell w zaufanym środowisku z wzmocnieniem lub bez niego. Jeśli pojawi się prośba o autoryzację Cloud Shell, kliknij Autoryzuj.

W Cloud Shell włącz wszystkie wymagane interfejsy API:

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

Instalowanie zależności

Sprawdź, czy w Cloud Shell masz zainstalowane wymagane narzędzia. Terraform, kubectl i Go są zwykle wstępnie zainstalowane. Musisz zainstalować uv (menedżer pakietów Pythona) i 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/

Ustawianie zmiennych środowiskowych

Ustaw następujące zmienne środowiskowe, które są używane w tym ćwiczeniu z programowania:

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

Tworzenie publicznej strefy DNS

Zanim zastosujesz konfigurację Terraform, musisz mieć w projekcie publiczną strefę DNS. Ta strefa jest potrzebna do delegowania serwerów nazw, aby konfiguracja mogła automatycznie tworzyć wymagane rekordy dla menedżera certyfikatów.

Aby utworzyć strefę, uruchom w Cloud Shell to polecenie:

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. Klonowanie repozytorium GitHub

W terminalu na komputerze lokalnym sklonuj repozytorium cloud-networking-solutions:
```
git clone https://github.com/googleCloudPlatform/cloud-networking-solutions.git
```

Przejdź do pobranego katalogu repozytorium:

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

4. Wdrażanie infrastruktury za pomocą Terraform

Do udostępnienia podstawowej sieci, klastra GKE i wymaganych konfiguracji tożsamości użyjesz Terraform.

Przejdź do katalogu terraform w sklonowanym repozytorium:
```
cd terraform
```
Skonfiguruj backend Terraform. Utwórz plik backend.conf na potrzeby częściowej konfiguracji backendu. Zastąp globalnie niepowtarzalną nazwą zasobnika.
```
cat <<EOF > backend.conf
bucket = "<YOUR_TERRAFORM_STATE_BUCKET>"
prefix = "terraform"
EOF
```

Skopiuj przykładowy plik zmiennych i zaktualizuj go o wartości z Twojego projektu:
```
cp example.tfvars terraform.tfvars
```
Edytuj terraform.tfvars i zastąp wartości symboli zastępczych.Zastąp te elementy:
- project_id: identyfikator Twojego projektu Google Cloud.
- organization_id: numeryczny identyfikator organizacji GCP.
- dns_zone_domain: domena, nad którą masz kontrolę (np. demo.example.com.). Musi kończyć się kropką.
Sprawdź, czy włączone są te flagi funkcji (są one wstępnie skonfigurowane w przykładzie pliku):
- enable_certificate_manager = true
- enable_model_armor = true
- enable_agent_engine = true
- enable_psc_interface = true

Zainicjuj i zastosuj konfigurację Terraform:

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

5. Wdrażanie przykładowych zadań za pomocą Skaffold

Następnie wdróż serwery MCP i zewnętrzne usługi przetwarzania w klastrze GKE.

Połącz się z klastrem GKE utworzonym przez Terraform:

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

Wróć do katalogu głównego projektu i skonfiguruj szablony plików manifestu Kubernetes. Skopiuj przykładową konfigurację i ustaw identyfikator projektu oraz domenę podstawową:ustaw wartość BASE_DOMAIN tak, aby pasowała do Twojego środowiska. Wartość BASE_DOMAIN powinna być zgodna ze zmienną dns_zone_domain Terraform (bez kropki na końcu).
```
export BASE_DOMAIN=example.com
```

Wygeneruj manifesty Kubernetes i skaffold.yaml na podstawie szablonów:

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

Wdróż wszystkie usługi backendu:

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

Wdróż konfigurację bramy i trasy HTTP:
```
kubectl apply -k k8s/gateway-internal/
```

6. Stosowanie zabezpieczeń AI za pomocą Model Armor

Możesz przekazać decyzje dotyczące bezpieczeństwa treści, takie jak usuwanie szkodliwych promptów lub zapobieganie wyciekom danych, do Model Armor.

Wymagania wstępne: przyznawanie ról uprawnień

Musisz przypisać wymagane role do konta usługi GKE Gateway. Konto usługi ma format: service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com.

Aby przyznać niezbędne uprawnienia, uruchom te polecenia:

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

Tworzenie rozszerzenia autoryzacji Model Armor

Zdefiniuj rozszerzenie, które wskazuje usługę Model Armor w Twoim regionie. Zapisz tę konfigurację jako ma-content-authz-extension.yaml.

Wyeksportuj identyfikator szablonu Model Armor utworzony przez 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

Tworzenie zasady autoryzacji Model Armor

Utwórz zasadę, która powiąże rozszerzenie Model Armor z bramą agenta. Zapisz tę konfigurację jako 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. Konfigurowanie Gemini Enterprise

Włączanie dostrzegalności

Agent hipoteczny jest wdrażany z instrumentacją OpenTelemetry i domyślnie włączonymi tymi zmiennymi środowiskowymi telemetrycznymi:

GOOGLE_CLOUD_AGENT_ENGINE_ENABLE_TELEMETRY=true
OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT=true
OTEL_TRACES_SAMPLER=parentbased_traceidratio

Szczegółowe informacje o konfigurowaniu logów czasu i spanów w Gemini Enterprise znajdziesz w artykule Zarządzanie ustawieniami dostrzegalności.

Włączanie Model Armor w Gemini Enterprise

Zastosuj filtrowanie Model Armor w przypadku asystenta Gemini Enterprise, aby filtrować zarówno prompty użytkownika, jak i odpowiedzi modelu. Aplikacje globalne Gemini Enterprise wymagają szablonu Model Armor w us wielu regionach, więc Terraform wdraża w tym celu osobny szablon.

Pobierz nazwę szablonu z danych wyjściowych Terraform:

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

Pobierz identyfikator aplikacji instancji Gemini Enterprise:

W konsoli Google Cloud otwórz stronę Gemini Enterprise.
W menu nawigacyjnym kliknij Aplikacje.
Skopiuj identyfikator instancji Gemini Enterprise

Wyeksportuj identyfikator jako zmienną środowiskową.

export APP_ID=<PASTE_APP_ID>

Zastosuj poprawkę do asystenta, aby włączyć 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"
      }
    }
  }'

Ustaw wartość failureMode na FAIL_OPEN, aby zezwalać na żądania, gdy Model Armor jest niedostępny, lub na FAIL_CLOSED, aby je blokować.

8. Wdrażanie agenta i dodawanie go w Gemini Enterprise

Uzyskiwanie szczegółów autoryzacji

Aby uzyskać szczegółowe informacje o autoryzacji, wykonaj te czynności.

W konsoli Google Cloud na stronie Interfejsy API i usługi otwórz stronę Dane logowania.
Otwórz Dane logowania.
Kliknij Utwórz dane logowania i wybierz Identyfikator klienta OAuth.
W sekcji Typ aplikacji wybierz Aplikacja internetowa.
W sekcji Autoryzowane identyfikatory URI przekierowania dodaj te identyfikatory URI:

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

Kliknij Utwórz.
Wyeksportuj identyfikator klienta i tajny klucz klienta na potrzeby wdrożenia.

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

Wdrażanie agenta hipotecznego

src/mortgage-agent/deploy_agent.py Skrypt wdraża agenta ADK w Agent Engine i opcjonalnie rejestruje go w Gemini Enterprise. Więcej informacji o procesie rejestracji w Gemini Enterprise znajdziesz w artykule Rejestrowanie agenta A2A i zarządzanie nim.

Eksportuj zmienne z wdrożenia 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)

Zainstaluj zależności i wdroż:

cd src/mortgage-agent
uv sync

Wdróż agenta w Vertex Agent Engine i zarejestruj go w 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

Odwołanie do flagi

Flaga	Domyślny	Opis
`--project`	`$PROJECT_ID`	Identyfikator projektu GCP
`--dms-mcp-url`	(wymagane)	Adres URL serwera MCP DMS
`--income-verification-url`	(wymagane)	Podstawowy adres URL interfejsu Income Verification API; `/mcp` jest dołączany automatycznie
`--email-mcp-url`	(wymagane)	Adres URL serwera MCP do wysyłania e-maili
`--region`	`$REGION`	Region GCP
`--staging-bucket`	`gs://PROJECT-staging`	Zasobnik GCS na potrzeby przesyłania etapowego
`--display-name`	`Mortgage Assistant Agent`	Wyświetlana nazwa wdrożonego agenta
`--update`	(opcjonalnie)	Aktualizowanie istniejącego agenta w miejscu (przekazywanie pełnej nazwy zasobu)
`--network-attachment`	(opcjonalnie)	Przyłącze sieciowe interfejsu PSC (pełna ścieżka lub nazwa)
`--dns-peering-domain`	(opcjonalnie)	Domena DNS dla połączenia równorzędnego DNS PSC-I (musi kończyć się kropką)
`--dns-peering-target-project`	(opcjonalnie)	Projekt, w którym znajduje się docelowa sieć VPC na potrzeby równorzędności DNS
`--dns-peering-target-network`	(opcjonalnie)	Nazwa sieci VPC na potrzeby połączenia równorzędnego DNS
`--enable-agent-identity`	`false`	Włącz dane logowania z zasadą jak najmniejszych uprawnień dla każdego agenta
`--ge-deploy`	`false`	Rejestrowanie agenta w Gemini Enterprise po wdrożeniu
`--app-id`	(opcjonalnie)	Identyfikator wyszukiwarki Gemini Enterprise (wymagany w przypadku `--ge-deploy`)
`--oauth-client-id`	`$OAUTH_CLIENT_ID`	Identyfikator klienta OAuth2 (wymagany w przypadku `--ge-deploy`)
`--oauth-client-secret`	`$OAUTH_CLIENT_SECRET`	Tajny klucz klienta OAuth2 (wymagany w przypadku `--ge-deploy`)
`--model`	`gemini-3.1-flash-lite-preview`	Nazwa modelu Gemini dla agenta
`--agent-name`	`mortgage-agent`	Autoryzacja Gemini Enterprise i nazwa agenta
`--ge-deploy-only`	(opcjonalnie)	Rejestrowanie w Gemini Enterprise istniejącego silnika wnioskowania bez ponownego wdrażania (przekazywanie pełnej nazwy zasobu)

Dodawanie użytkowników z uprawnieniami

Aby dodać użytkowników z uprawnieniami do agenta ADK za pomocą konsoli Google Cloud, zapoznaj się z artykułem Dodawanie i modyfikowanie użytkowników oraz ich uprawnień.

9. Testowanie agenta

Po wdrożeniu i skonfigurowaniu agenta, GKE Gateway i wszystkich usług backendu przetestuj kompleksowy przepływ, aby sprawdzić, czy zasady bezpieczeństwa działają zgodnie z oczekiwaniami. Będziesz wchodzić w interakcje z agentem „mortgage-agent” w interfejsie Gemini Enterprise.

Otwieranie agenta

W konsoli Google Cloud otwórz stronę Gemini Enterprise.
Wybierz aplikację Gemini Enterprise, którą skonfigurowano wcześniej i w której zarejestrowano „mortgage-agent”.
Na karcie Przegląd otwórz adres URL widoczny w sekcji „Aplikacja internetowa Gemini Enterprise jest gotowa”.
W menu po lewej stronie wybierz kartę Agenta o nazwie Galeria agentów.
Powinna się teraz otworzyć możliwość rozmowy na czacie z „Asystentem ds. kredytów hipotecznych”.

Przypadek testowy 1. „Ścieżka optymistyczna” – podsumowywanie danych z redagowaniem informacji umożliwiających identyfikację

Ten test sprawdza, czy agent może uzyskiwać dostęp do systemów backendu za pomocą bramy agenta oraz czy zasady zapobiegania utracie danych (DLP) są egzekwowane w celu redagowania informacji wrażliwych.

Wyślij do agenta ds. asystenta hipotecznego ten prompt:

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?

Co się dzieje za kulisami:
- Agent w Gemini Enterprise formułuje żądania do niezbędnych narzędzi (np. systemu zarządzania dokumentami w przypadku zeznań podatkowych, interfejsu Income Verification API).
- Model Armor sprawdza ładunki żądań i odpowiedzi pod kątem zagrożeń.
- Skonfigurowane przez Ciebie „Zasady autoryzacji oparte na treści” wyzwalają niestandardowe rozszerzenie DLP (dlp-content-authz-ext). To rozszerzenie sprawdza dane pobrane z systemów backendowych.
- Usługa DLP usuwa z danych z deklaracji podatkowej wszelkie informacje umożliwiające identyfikację (PII), takie jak numery PESEL, zanim trafią one do agenta.
Oczekiwany rezultat: agent zwróci podsumowanie deklaracji podatkowych i stan weryfikacji dochodów. Dokładnie sprawdź podsumowanie podane przez agenta. Zwróć uwagę, że informacje poufne, takie jak identyfikatory podatników (numery PESEL), zostały zastąpione symbolami zastępczymi (np. [REDACTED]). Potwierdza to wykonanie zasady DLP za pomocą bramy.

Dostrzegalność i kontrola

Podczas tych testów platforma agenta i powiązane usługi zbierają dane telemetryczne:

Cloud Logging: szczegółowe logi z bramy GKE, zadań GKE i innych usług zapewniają ścieżkę audytu żądań, ocen zasad i wyników.
Cloud Trace: instrumentacja OpenTelemetry skonfigurowana w usługach agenta i backendu umożliwia wizualizację całego przepływu wywołań, od Gemini Enterprise przez bramę GKE po narzędzia backendu. Jest to nieocenione narzędzie do debugowania i poznawania cyklu życia żądania.

Wyświetlanie logów czasu sesji:

W konsoli Google Cloud otwórz stronę Vertex AI Agent Engine.
Otwórz Agent Engine. Na liście pojawią się instancje Agent Engine, które są częścią wybranego projektu. W polu Filtr możesz filtrować listę według określonej kolumny.
Kliknij nazwę instancji Agent Engine.
Kliknij kartę Ślady.
Możesz wybrać widok Sesja lub Zakres.
Kliknij sesję lub span, aby zbadać szczegóły logu czasu, w tym skierowany graf acykliczny (DAG) jego spanów, dane wejściowe i wyjściowe oraz atrybuty metadanych.

10. Opcjonalnie: transkodowanie interfejsów API REST na MCP za pomocą Apigee

Nasza usługa weryfikacji dochodów natywnie obsługuje protokół Model Context Protocol, ale wiele starszych systemów klasy enterprise udostępnia tylko interfejsy RESTful API. W tym kroku opcjonalnym użyjesz serwera proxy wykrywania MCP Apigee, aby przekodować punkt końcowy REST usługi weryfikacji dochodów na narzędzie MCP. Umożliwia to stosowanie zaawansowanych zasad zarządzania, ograniczania liczby żądań i bezpieczeństwa Apigee do starszych narzędzi.

Więcej informacji znajdziesz w omówieniu Apigee MCP.

Wymagania wstępne

Zanim przejdziesz dalej, upewnij się, że masz udostępnione i skonfigurowane centrum interfejsów API w Apigee. Aby skonfigurować centrum interfejsów API i dołączyć do niego instancję Apigee, wykonaj czynności opisane w dokumentacji Provision API Hub (Wdrażanie centrum interfejsów API).

Krok 1. Utwórz połączenie usługi dla Apigee

Aby umożliwić Apigee dostęp do usług wewnętrznych działających w GKE, musisz utworzyć przyłącze usługi.

Wyszukaj regułę przekierowania wewnętrznej bramy 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}')

Utwórz przyłącze usługi:

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

Krok 2. Włącz Apigee za pomocą Terraform

Teraz zaktualizuj konfigurację infrastruktury, aby udostępnić organizację i instancję Apigee.

Przejdź do katalogu terraform:
```
cd terraform
```
Edytuj terraform.tfvars i ustaw enable_apigee = true.
Zastosuj zmiany:
```
terraform apply
```

Krok 3. Zdefiniuj specyfikację OpenAPI

Apigee używa standardowych definicji OpenAPI (OAS) do wykrywania i transkodowania narzędzi. Utwórz plik o nazwie income-verification-oas.yaml z tą zawartością:

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

Krok 4. Wdróż serwer proxy wykrywania Apigee MCP

Serwer proxy wykrywania MCP to specjalny serwer proxy Apigee, który działa jako serwer MCP.

W interfejsie Apigee kliknij Develop > API Proxies (Programowanie > Proxy interfejsów API).
Kliknij Utwórz nowy i wybierz Serwer proxy odkrywania MCP.
Nazwij serwer proxy income-verification-discovery.
W sekcji Specyfikacja OpenAPI prześlij utworzony plik income-verification-oas.yaml.
Ustaw Grupę środowisk na tę, w której dostępna jest Twoja brama wewnętrzna.
Kliknij Wdróż.

(Opcjonalnie) Dodawanie zasady zabezpieczeń

Zanim wdrożysz lub udostępnisz serwer proxy, musisz go zabezpieczyć. Możesz dodać zasady, aby egzekwować wymagania dotyczące zabezpieczeń, takie jak tokeny OAuth lub klucze API. Instrukcje dodawania zasad bezpieczeństwa znajdziesz w dokumentacji Apigee dotyczącej zabezpieczania interfejsów API.

Krok 5. Sprawdź dostęp do narzędzia do transkodowania

Po wdrożeniu Apigee automatycznie przekoduje punkt końcowy POST /verify na narzędzie MCP verifyApplicant.

Wyświetl listę narzędzi dostępnych w punkcie końcowym 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": {}
  }'

W odpowiedzi powinien pojawić się element verifyApplicant, który został przekodowany ze specyfikacji REST. Możesz teraz wywoływać to narzędzie za pomocą Apigee, a Apigee zajmie się tłumaczeniem na bazową usługę REST, stosując jednocześnie skonfigurowane przez Ciebie zasady zabezpieczeń.

Krok 6. Zaktualizuj aplikację Mortgage Agent, aby korzystała z Apigee

Apigee przekodowuje interfejs API REST na narzędzie zgodne z MCP. Musisz teraz zaktualizować konfigurację wdrożenia agenta. Dzięki skierowaniu agenta do punktu końcowego Apigee wszystkie żądania weryfikacji dochodów będą teraz korzystać z zabezpieczeń klasy biznesowej, rejestrowania i zarządzania ruchem Apigee.

Określ adres URL platformy Apigee MCP: punkt końcowy powinien mieć format https://api.internal.${DNS_PEERING_DOMAIN%%.}/income-verification-discovery/mcp.

Ponownie uruchom skrypt wdrażania: użyj flagi --update wraz z nowym parametrem --income-verification-url. Spowoduje to zaktualizowanie istniejącego agenta w Agent Engine bez konieczności jego usuwania.

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}

Weryfikacja zmiany: wróć do interfejsu Gemini Enterprise i poproś agenta o zweryfikowanie dochodów kandydata.
```
"Can you verify the joint income for the Sterlings using the verification service?"
```
Na karcie Debugowanie Apigee powinna być teraz widoczna przychodząca z bramy GKE żądanie JSON-RPC przekształcone w standardowe żądanie REST POST do usługi GKE backendu.

11. Czyszczenie danych

Aby uniknąć obciążenia konta Google Cloud opłatami za zasoby utworzone w tym ćwiczeniu, po zakończeniu usuń je.

Jeśli przyłącze usługi zostało utworzone ręcznie, usuń je:

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

Przejdź do katalogu terraform i usuń wszystkie zasoby:
```
cd terraform
terraform destroy
```
Opcjonalnie możesz całkowicie usunąć projekt Google Cloud:
```
gcloud projects delete ${PROJECT_ID}
```

12. Gratulacje

Ukończono to ćwiczenie i dowiedziano się, jak zabezpieczać wdrożenia agentowe w różnych chmurach.

Omówione kwestie

Wdrożono agenta ADK do obsługi kredytów hipotecznych w Agent Engine z instrumentacją OpenTelemetry.
Wdrożono serwery MCP backendu w GKE za wewnętrzną bramą
Połączono Agent Engine z siecią VPC projektu za pomocą interfejsu PSC i połączenia równorzędnego DNS.
Skonfigurowana brama GKE na potrzeby kontrolowanego ruchu wychodzącego agenta z redakcją DLP i autoryzacją MCP
Zastosowane zabezpieczenia AI z Model Armor do sprawdzania promptów i odpowiedzi
Opcjonalnie transkodowane interfejsy API REST do MCP za pomocą serwera proxy odkrywania MCP Apigee

Dalsze kroki

Poznaj Model Armor
Więcej informacji o Agent Engine
Poznaj Gemini Enterprise