Disabling the guardrails before the heist (GCP Org Policy)
GCP Organization Policies are the guardrails that stop public buckets, key creation, and external sharing. An attacker with org-level rights turns them off first, quietly, then does the damage. Here is the move, and the fix.
The smartest attackers do not break the guardrail. They turn it off, then walk through.
What it is
GCP Organization Policy constraints enforce guardrails across an org: block service-account key creation, prevent public buckets, restrict external sharing and resource locations. An attacker with organization or folder administration rights weakens or removes a constraint, which then no longer blocks the very action they want next, like minting a long-lived key or making data public. This is T1098 (account manipulation) with T1562 (impair defenses).
Why it works
Policy changes are quiet administrative actions, and once a guardrail is off, the follow-on action looks allowed. The tampering and the abuse can be seconds apart.
How to detect it
In Cloud Audit Logs, look for SetOrgPolicy or constraint deletions by a principal that does not normally manage org policy, especially right before key creation or public-sharing actions.
The fix that holds
Tightly restrict organization and folder administration, alert on any Org Policy change, and use policy-as-code with review so guardrails are versioned and restorable. Treat a guardrail change as a high-severity event in its own right.
Practice it
We built a GCP Org Policy tampering scenario in GraphLattice Range so teams learn to watch the guardrail itself, not just the action it was meant to block.