Who is accountable when cross-project trust and workload identity misconfigurations expose production resources in GCP?

Why This Matters for Security Teams

Cross-project trust in GCP is not just an IAM hygiene issue. When service account bindings, Shared VPC relationships, and workload identity mappings span multiple projects, the blast radius crosses team boundaries and ownership lines. That makes accountability harder to assign after the fact, especially when a production workload can impersonate another project’s resources without a corresponding business owner explicitly approving that trust path.

The practical risk is that cloud platform teams often own the primitives, application teams own the workload, and security owns the policy, but no one owns the end-to-end trust chain. In machine identity programs, this is a common failure mode: Ultimate Guide to NHIs notes that 59% of companies struggle to audit machine identities because of unclear ownership and limited visibility. That pattern is especially dangerous in GCP because a single misbound service account or overly broad workload identity pool can expose production services across projects. In practice, many security teams discover this only after an unintended cross-project access path has already been used, rather than through deliberate trust review.

How It Works in Practice

Accountability should be assigned by control plane, not by incident blame. The cloud platform owner is typically accountable for org policies, project hierarchy, Shared VPC design, and baseline IAM guardrails. The identity owner is accountable for service account lifecycle, trust boundaries, and workload identity federation. Application and platform engineering teams are accountable for the specific workload configuration that consumes those identities. That split matters because GCP exposure usually emerges where these layers meet.

For autonomous or high-change platforms, static role ownership is not enough. Current guidance suggests building a control map that ties each cross-project trust relationship to a named owner, review cadence, and revocation path. Use workload identity as the primary identity primitive, and prefer short-lived credentials over long-lived service account keys. The SPIFFE workload identity specification is useful here because it frames identity as cryptographic proof of workload identity, not just an IAM binding. NHI Management Group also documents how weak visibility and excessive privileges amplify machine identity risk in the Ultimate Guide to NHIs.

• Map every cross-project trust edge to a single accountable owner.
• Review service account impersonation, IAM bindings, and workload identity pools together.
• Prefer JIT access and short TTLs for production workloads.
• Log who approved the trust, who can revoke it, and how quickly revocation takes effect.
• Use policy-as-code to detect drift before it becomes an exposure path.

For detection and assurance, pair cloud audit logs with identity inventory and explicit ownership registers. NIST controls for least privilege and system accountability support this approach, while The Critical Gaps in Machine Identity Management report shows how manual processes and poor ownership routinely leave machine identities exposed. These controls tend to break down in fast-moving GCP environments where teams create new projects, trust relationships, and workload identities faster than the review process can keep up.

Common Variations and Edge Cases

Tighter accountability often increases coordination overhead, so organisations have to balance faster platform delivery against stronger approval and review discipline. That tradeoff becomes more visible in multi-project GCP estates, where central platform teams want standardisation but product teams want autonomy.

There is no universal standard for this yet, but current guidance suggests a few edge cases deserve special handling. First, Shared VPC host and service project splits can obscure who owns the trust decision versus who owns the runtime workload. Second, Kubernetes workload identity can look clean in architecture diagrams while still inheriting overly broad project-level permissions. Third, when contractors or external integrators manage parts of the stack, the accountability model must distinguish operational responsibility from approval authority. The right answer is not to assign blame to whichever team found the issue first, but to define who owns policy, who approves exceptions, and who can revoke access immediately.

For teams hardening these environments, the main takeaway is to make cross-project trust visible, reviewable, and revocable. That is the practical meaning of accountability in GCP: not just naming an owner, but ensuring the owner can actually reduce exposure when a workload identity is misconfigured.

Related resources from NHI Mgmt Group

• Who is accountable when a leaked non-human identity is used to access production systems?
• Who is accountable when workload secrets are exposed or rotated too late in a zero-trust design?
• Who is accountable when a red team compromise exposes both endpoint and cloud identity gaps?
• Who is accountable when a public bug report exposes internal identity data?