Cloud IAM and supply chain controls overlap in ways that confuse a lot of teams. The IAM team owns the role bindings, the supply chain team owns the signing and attestation, and neither team owns the seam where the two meet. The seam is where most production supply chain incidents happen.
I have done IAM-side reviews of supply chain incidents in AWS, Azure, and GCP environments over the last three years. The pattern is the same in every cloud, even though the primitives are different. An attacker compromises a build identity, the IAM permissions on that identity grant more access than the supply chain team realizes, and the attacker uses the unintended permissions to escalate. The supply chain controls are not at fault. The IAM scoping is.
This is a tour of the five most common overlap mistakes I see in 2026, and what to do about them.
Mistake one: shared service accounts across pipelines
The most common mistake in every cloud is a single service account or IAM role that is used by every pipeline in the organization. The sharing is convenient — one role to grant permissions to, one identity to audit, one secret to rotate. The cost is that every pipeline inherits every other pipeline's permissions, and a compromise of any pipeline becomes a compromise of all of them.
The fix is per-pipeline identity. AWS supports this via per-CodeBuild-project IAM roles. Azure supports it via per-pipeline workload identity federation. GCP supports it via per-trigger Cloud Build service account binding. All three support per-pipeline scoping, and all three default to a single shared service account if the customer does not configure otherwise.
The migration from shared to per-pipeline is one-time and not very expensive. The pattern is to introduce a new per-pipeline identity, copy the relevant permissions from the shared identity to the new one, switch the pipeline to use the new identity, and remove the shared identity's permissions for the workload that has migrated. The shared identity ends up with progressively fewer permissions until it can be deleted.
Mistake two: production permissions on PR-triggered builds
The second most common mistake is letting pull-request-triggered builds run under an identity that has production permissions. The PR build is a low-trust event by design — it runs code that has not yet been reviewed — and the identity that runs it should have only the permissions needed to build and test, not the permissions needed to deploy.
The fix is to split the pipeline into a low-trust build and a high-trust deploy, with separate identities for each. The low-trust build runs on PR triggers under an identity that can build, run tests, and publish to a quarantine artifact location. The high-trust deploy runs on merge-to-main triggers under a different identity that can promote from the quarantine location to production. The quarantine and promotion separation gives you a clean trust boundary that an attacker cannot cross by submitting a malicious PR.
The pattern is the same in every cloud. AWS uses two CodeBuild projects with two different roles. Azure uses two Azure DevOps pipelines with two different service connections. GCP uses two Cloud Build triggers with two different service account bindings. The separation is the operational discipline; the cloud primitives all support it.
Mistake three: stale federation trust policies
Workload identity federation has been the right answer for cross-cloud and CI-to-cloud authentication for two years. Most teams have migrated. The mistake is leaving the federation trust policies wide open after the migration.
A typical federation trust policy says "any GitHub Actions workflow in this repo can assume this role." That is too wide. A malicious commit to the repo, even if reverted quickly, can run a workflow that assumes the role and persists access. The fix is to scope the trust policy to a specific workflow file, a specific branch, and ideally a specific environment, using the OIDC token's claim fields.
The same mistake happens in every cloud. AWS uses sub-claim conditions on the IAM trust policy. Azure uses subject filters on the federated identity credential. GCP uses attribute conditions on the workload identity pool provider. All three support tight scoping, and all three default to wide scoping if the customer does not configure conditions.
The audit pattern is the same too. Every quarter, list every federation trust policy in the estate, and verify that each one has explicit conditions on the OIDC token claims. Any policy that lacks conditions is a finding, and the finding is high-priority because it is actively exploitable.
Mistake four: signing keys that are not separated from build identities
The signing key for a supply chain attestation should be a separate primitive from the build's compute identity. If the build's IAM role has permission to sign, the signing key is effectively part of the build identity, and a compromise of the build is a compromise of the signing key.
The fix is to put the signing key in a separate identity surface and require the build to call the signing service rather than holding the key directly. AWS uses Signer with a service-to-service trust relationship. Azure uses Key Vault with a managed identity binding that is scoped narrowly. GCP uses KMS with a per-pipeline binding that uses asymmetric signing keys.
The build's compute identity has permission to ask the signing service to sign a specific artifact, not permission to extract the key or to sign arbitrary data. The signing service logs every request, including the principal, the artifact digest, and the signing context. The audit log is the corresponding evidence trail, and an anomaly in it is the leading indicator of a signing-path compromise.
Mistake five: deploy roles that can also modify the policy
The deploy identity should have permission to deploy, not permission to modify the supply chain policy that governs the deploy. The two permissions are different, and conflating them lets a compromised deploy path escalate to weakening the policy that should have stopped it.
The split looks different in each cloud. On AWS, the deploy role can call CodeDeploy, ECS, or Lambda APIs, but not codepipeline:UpdatePipeline or binaryauthorization:UpdatePolicy or any policy-related API. On Azure, the deploy identity can update App Service, AKS, or Container Apps, but not Azure DevOps approval checks or ACR trust policies. On GCP, the deploy identity can update GKE workloads, Cloud Run services, or Cloud Functions, but not Binary Authorization policies or attestor configurations.
The audit pattern is the same in every cloud. Every quarter, list the identities that have permission to modify supply chain policy, and verify that none of them is also an active deploy identity. Any overlap is a finding, and the finding is high-priority because the overlap is the path that lets a deploy compromise escalate to a policy compromise.
What does the right operating model look like?
Three teams, three artefacts. The platform team owns the IAM bindings. The supply chain team owns the signing and attestation configuration. The application team owns the deploy logic. The seam where the three meet is governed by a control plane that compiles a single policy intent into the per-cloud primitives each team operates.
The control plane is not a replacement for the three teams. It is the connective tissue that makes the three teams' artefacts consistent with each other, detects drift when one team's change conflicts with another's, and produces the rollup that the security team queries when an incident happens.
How Safeguard Helps
Safeguard ingests IAM, federation, and supply chain configuration from AWS, Azure, and GCP, and produces a continuous posture signal that flags every overlap mistake described above. The signal is per-pipeline, per-identity, and per-policy, with the data joined so the security team can answer "which pipelines have wide federation trust" or "which identities can both deploy and modify policy" in a single query.
Griffin AI generates per-pipeline identities, scoped federation trust policies, separated signing service bindings, and deploy-vs-policy IAM splits from an existing estate, then opens pull requests against the customer's IaC repo to roll the changes out. The PR-driven workflow keeps the IAM team, the supply chain team, and the application team in the loop for every change, which is the operating model the overlap mistakes call for.
Safeguard's drift detection catches the case where a human change to one team's artefact conflicts with another team's policy. The drift signal is the leading indicator of an in-progress supply chain weakening, and the alert lets the security team decide whether the change is legitimate or malicious. The integration with audit logs from all three clouds gives the security team a single timeline for incident response, regardless of which cloud the incident touches.
For enterprise security teams, Safeguard's overlap-detection module specifically targets the five mistakes described above, with per-finding remediation paths that the IAM and supply chain teams can run in parallel.