"We use a service account key file to aggregate billing data in a nightly batch run. That key was left behind by the development firm we hired, and it's on the server, the staff member's laptop, and somewhere in GitHub... I think." This was the response we received when asking an IT manager to inventory their company's external integrations. Not knowing how many keys exist, where they are, or what they are for is an alarmingly common state among companies that outsource automation, and it is also the most dangerous. If a single key is compromised, attackers can impersonate that account indefinitely.
For automating tasks using Google Cloud or Google Workspace APIs, issuing service account key files (JSON keys) and distributing them across various systems has long been the standard approach. As of 2026, however, the keyless method (Workload Identity Federation), which authenticates workflows like GitHub Actions without downloading any keys, has become the practical standard. In this article, we explain why key files cause security incidents and what changes when shifting to keyless authentication, using the familiar example of automated internal document distribution.
Why key files become the root of security incidents
A service account key file is essentially a master duplicate key that lets anyone impersonate that account. While convenient, its inherent properties introduce severe risks:
- Long validity periods: Once issued, keys remain usable for years unless explicitly revoked. Leaks often go unnoticed.
- Effortless duplication: Being plain files, they easily spread across PCs, code repositories, and chat attachments.
- Unmanageable auditing: Spreadsheets fail to track where every copy lives, leaving unused keys neglected.
- Leakage equals immediate impersonation: Keys mistakenly committed to GitHub are automatically scraped and abused, representing a textbook incident pattern.
How widely leaks of source code or secrets can propagate is a recurring topic in designing confidential data and trust boundaries in custom development. Key files are particularly hazardous because your attack surface multiplies with every copy distributed.
The keyless concept: stopping key distribution
Keyless authentication (Workload Identity Federation) is an approach that eliminates downloadable keys entirely. Breaking down the mechanism, the executing workload (such as GitHub Actions) presents identity credentials proving "I am this specific workflow in this repository." Google verifies that proof and issues a short-lived, ephemeral token valid only on the spot. Once the task finishes, the token expires, leaving nothing behind.
In other words, long-lived key files that pose a theft risk do not exist in the first place. With no tangible asset to leak, the entire category of key leak incidents disappears. In terms of centralizing authentication, the concept resembles consolidating logins via SSO; however, while SSO unifies human logins, keyless authentication eliminates keys from machine-to-machine authentication.
A clear example of impact: automated internal document distribution
Because the concept is abstract, let us examine a relatable example. Suppose you build a mechanism where internal manuals written in Markdown and pushed to GitHub are automatically converted to PDF, with the latest version continuously placed in a shared Google Drive folder.
Under the traditional method, you would issue a service account key with write permissions to Drive and paste it into GitHub repository settings. If that key leaks, attackers gain unrestricted write access to your Drive. Under a keyless setup, GitHub Actions retrieves a short-lived token each time it writes to Drive, meaning there is no static key to store. You retain the convenience of pushing code to distribute updated manuals without maintaining risky duplicate keys. Systematizing these modest, recurring distribution routines also helps prevent the common trap where no one can touch automations left by former employees—individualized scripts and scattered keys invariably break down in the same way.
Decisions to make for the transition
While keyless authentication is powerful, it is not meant to replace existing environments overnight. A practical adoption sequence proceeds as follows: First, inventory existing keys by identifying which service account keys are currently active and what each is used for. As part of a security configuration checklist, revoke any unused keys during this review. Next, establish a policy to build all new integrations using keyless methods, and migrate existing ones starting from high-risk, highly privileged integrations. In doing so, narrow down trust conditions to specify exactly which repository and workflow can obtain tokens, minimizing the attack surface.
Finding yourself unsure of how many keys exist or where they live after years of outsourcing automation only gets harder to resolve the longer it is left unaddressed. If you want to inventory external integration and batch processing keys or build new automations securely using keyless architecture, feel free to contact GleamHub's development and automation consulting desk. We will support you from identifying legacy keys to designing your keyless migration.
