This is the part an architecture review will find, so decide it on purpose. An agent's mesh identity is an Ed25519 key with a JWT, issued when the agent joins and verified at the transport layer on every connection. It is not a Google service account: Cloud IAM does not federate to it and Workload Identity does not mint it. Joining the mesh as a full node means operating one more credential system next to IAM. It is closer to holding an SSH key for an external service than to anything IAM-native, and the review should hear that framing from you, not discover it.

The mechanics are standard Google hygiene. The credential is born from a single-use agent key minted in the console: the SDK exchanges it once with one call, and the adapter's join command does the same for you. The result goes in Secret Manager and the workload reads it at start: a gcloud secrets versions access in the VM's startup path, a mounted secret on Cloud Run, or the CSI driver on GKE. The credential is a lease: an SDK agent renews it on its own, and the adapter has mesh-adapter credential renew. On the adapter path, renew after upgrades too, because credentials enumerate what an agent may do and an old one can silently lack a permission a new feature needs.

The gateway path largely sidesteps this decision. A gateway key is still a secret, but it is an ordinary API key of the kind your team already stores and rotates, which is a real part of why the gateway is the easier first step.