Cloud Security Grey Zone: Who Owns the Risk of Managed Identities

Countless hours can be spent enforcing MFA, and locking down permissions. But what about the identities you don’t manage? The ones your cloud provider creates and manages for you?

These "CSP-managed non-human identities" are the automated robots that run services in the background. While they're essential, the way AWS, Google Cloud, and Microsoft have architected them creates unique, non-obvious security risks. If you think a secure setup in AWS is also secure in Azure, you might be surprised.

Let's take a moment to break down the unique risks in each cloud.

AWS: The "Confused Deputy" Problem (It's On You)

In AWS, services are global and shared by everyone. This creates a classic multi-tenant "confused deputy" risk. An attacker in their own account can potentially trick an AWS service into using its permissions to access your account's resources.

• The Catch: The only thing stopping this is a special setting in your IAM resource policies called a condition key (i.e.,  aws:SourceArn).
• The Reality: It can be very difficult to use condition keys correctly. This leaves a massive, often-overlooked hole that places the burden of prevention squarely on your shoulders.

Google Cloud: The "Black Box" Problem (It's On Them)

Google takes the opposite approach. Its CSP-managed non-human identities (Service Agents) are single-tenant and locked down in Google-controlled projects. You can't touch them, which prevents the credential abuse seen in other clouds.

• The Catch: This creates a different problem: transitive access abuse. A service might be so inherently powerful it makes for a juicy target. An attacker can trick it into acting on their behalf, bypassing a check on their own permissions.
• The Reality: This exact thing happened with the Document AI service. While Google fixed it, you have zero direct controls here. You must trust that the provider has designed all its services securely.

Microsoft Entra ID: "Service Principal Hijacking" (A Present-Day Risk)

Microsoft uses a hybrid model where a local Principal for the Microsoft-owned first-party application lives in your tenant. Historically, this design had a critical flaw: an admin (like Application Admin) could add their own credential to the Service Principal and escalate their permissions.

• The Catch: Microsoft has a fix called the appInstancePropertyLock. When enabled, it prevents this kind of hijacking.
• The Reality: The fix isn't retroactive. Microsoft must manually update the 300+ default applications installed in customer tenants. While many have been redeployed with this property enabled, as researchers recently showed, critical apps like Office 365 Exchange Online remain unprotected, making this the most immediate and high-impact risk of the three.

The Takeaway?

Security isn't one-size-fits-all in the cloud. The threat you need to obsess over in AWS is a non-issue in Google, and the biggest risk in Entra ID has a completely different cause.

• In AWS? Audit your IAM policies for missing condition keys. Confused Deputy Issues are yours to prevent.
• In Google Cloud? The security of Service Agents rests solely in the hands of Google. Stay updated on vulnerabilities, only enable the services minimally required and monitor for unusual activity.
• In Microsoft Entra ID? Monitor for credentials being added to local Service Principals. Stay up to date on Service Principal Hijacking being reported in the wild

Threats are not uniform. The most critical threat in one cloud may be a non-issue in another. Defenders and researchers must tailor their strategies, recognizing that there is no “1-to-1” approach to security controls in a multi-cloud environment.

Understanding how cloud providers implement managed identities is only the first step. The harder challenge is continuously identifying when those identities are being misused, granted excessive privileges, or leveraged in ways that create risk across your environment. Learn more about Vectra AI's approach with this podcast.

To dig into the research behind each of these threat models and varying architectures, see the accompanying whitepaper “A Comparative Threat Model of CSP-Managed Machine Identities”.

‍