We’re testing out trustcloud. It looks like a good option for us. We’re on GCP and when I went to follow TrustCloud’s integration instructions and GCP and ran into my first big issue.

Your GCP integration currently requires creating and uploading a long-lived JSON service-account key (steps 7–9 in your guide). Many orgs—including ours—block key creation by policy because keys are a common leak vector; Google now steers customers to keyless auth and even flags that if you’re prevented from making a key, it’s due to an org policy that’s meant to reduce risk. Requiring keys puts TrustCloud at odds with Google’s secure-by-default posture and forces customers to weaken controls just to integrate.

What you could do: please add a keyless integration using Workload Identity Federation (WIF) so customers can grant TrustCloud short-lived, scoped access via OIDC/SAML—this is Google’s recommended pattern for third-party products and removes the need to distribute keys entirely. If keys must remain as a fallback, document a safe, least-privilege path (project-scoped exception only, tight roles, rotation, and monitoring) aligned with Google’s key-management guidance. That would let teams stay compliant without undermining their own controls—and it’s exactly the bar we expect from a compliance platform.