Most cloud platforms start onboarding the same way: paste in a service account key, an access key and secret, or a JSON blob you definitely should not be emailing to yourself. You paste it. They store it—hopefully encrypted—and you move on hoping nobody on their team can read it.

The Secret Sprawl Problem

This is how credential sprawl happens at scale. According to the GitGuardian 2026 report, 28.65 million hardcoded secrets were pushed to GitHub in 2025—a 34% year-over-year increase. Most of those secrets were valid when detected. The problem isn't carelessness; it's that long-lived credentials are inherently fragile infrastructure. They work silently until they don't, and the failure mode is a breach you won't see coming. When you paste a GCP service account key into a third-party platform, you've created a credential that's valid indefinitely, scoped to whatever permissions you granted during onboarding, and stored in a system you don't control. If that platform gets breached—or if an employee with database access gets curious—that key works until someone revokes it. Nobody revokes it because nobody remembers it exists.

How Keyless Actually Works

b0gy's Zero platform took a different approach for GCP and AWS infrastructure access: federated identity tokens minted on demand, short-lived by design, never stored. The mechanism uses Workload Identity Federation on GCP and OIDC-based AssumeRoleWithWebIdentity on AWS—your cloud trusts Zero's identity rather than accepting a static credential. The flow is elegant in its simplicity. Zero runs its own OIDC issuer with a public JWKS endpoint for signature verification. When you connect a GCP project, you create a Workload Identity Pool that trusts Zero's OIDC issuer and scopes access to your specific organization via an attribute condition: attribute.workspace == "org:YOUR_ORG_ID". When Zero needs cloud access, it mints a short-lived JWT containing your org ID as a claim, presents it to GCP's Security Token Service for verification, and receives a temporary access token scoped to the roles you granted. Minutes later, that token expires. The next request starts fresh. AWS follows the same pattern—create an IAM role with OIDC trust referencing Zero's issuer and your org ID, then use AssumeRoleWithWebIdentity instead of STS exchange. Per-org scoping means one tenant can never read another's projects; the cloud itself enforces the boundary at the identity layer, not application-level query filters.

The Real Costs of Doing This Right

Keyless isn't free—in engineering complexity or onboarding friction. Setup requires creating a Workload Identity Pool (GCP) or IAM role with OIDC trust (AWS), which means clicking through the console or writing Terraform rather than pasting a key. Zero built setup wizards with copyable commands and Terraform snippets to ease this, but it's still more work than the credential-paste approach. Every cloud operation now starts with a token exchange round-trip. For bulk syncs reading thousands of resources, the impact is negligible—the exchange happens once at startup. But there's latency. Stored-key platforms don't pay this cost. Federated identity does—and b0gy accepts it because setup friction is a one-time cost while stored secrets compound in risk over time. When things break with federated identity, the error surface is wider: expired OIDC tokens, misconfigured attribute conditions, Workload Identity Pools pointing to wrong issuers, IAM roles with incorrect trust policies. Zero invested heavily in diagnostic messages that identify exactly which link in the chain failed—a solved problem but real engineering investment.

Why Teams End Up Here

The pattern isn't hypothetical. During advisory engagements, b0gy asks: "What third-party services have access to your cloud, and with what permissions?" The silence that follows is longer than it should be. The answer is usually "we don't know." Not because teams are negligent—because stored secrets are invisible by design. Teams connect a cloud account during onboarding. The service account key gets broad permissions because the person setting it up wants things to work. Six months later, nobody remembers what that key can do. Twelve months later, the person who set it up left the company. The key is still valid. The platform still uses it nightly. Nobody audits it because there's nothing visible to audit.

Key Takeaways

  • Long-lived cloud credentials are liabilities that compound over time—valid until revoked, invisible between uses
  • Federated identity (Workload Identity Federation on GCP, OIDC AssumeRoleWithWebIdentity on AWS) eliminates stored secrets entirely for high-risk cloud access
  • Short-lived tokens minted per-request mean nothing to leak and no rotation burden
  • Trust relationships are visible in your cloud's IAM configuration—one resource to revoke if you walk away

The Bottom Line

The industry standardized on "paste your key" because it's easy. Easy for the platform, hard for security teams who inherit forgotten credentials years later. Federated identity isn't magic—it's just taking the harder path upfront so you're not the person explaining a breach that happened through a service account nobody remembered to audit. The setup friction is real but one-time; the liability of stored secrets grows with every employee who touches your infrastructure.