TL;DR: CSP-managed non-human identities create different security failure modes across AWS, Google Cloud and Microsoft Entra ID, from confused deputy exposure and transitive access abuse to service principal hijacking, according to Vectra AI. The governance problem is not uniform cloud hardening, but provider-specific control ownership, because the effective defence changes with each identity model.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Vectra AI's blog post: Cloud-managed non-human identities fail differently in AWS, Google Cloud and Microsoft Entra ID, with risk shaped by provider architecture rather than a single universal control model.
Why it matters: IAM, cloud security and NHI teams need to treat managed identities as provider-specific governance problems, because the control owner, attack path and containment strategy change across platforms.
Context
CSP-managed non-human identities are identities created and operated by a cloud provider to run services, background processes and platform functions. The security challenge is that control ownership is split between the customer and the provider, so a familiar IAM model does not always map cleanly across clouds. Non-Human Identities are therefore governed differently depending on who can configure, observe and revoke them.
The article's core point is that multi-cloud identity risk is architectural, not cosmetic. AWS, Google Cloud and Microsoft Entra ID each create a different trust boundary, so defenders need separate assumptions for service permissions, transitive access and credential placement. That makes this a cloud governance problem with a direct identity-security intersection, not just another hardening exercise.
Key questions
A: Teams lose sight of who actually controls the trust boundary. In AWS the customer must configure source-binding conditions, in Google Cloud the provider owns the service agent, and in Entra ID tenant-local principals can be abused for escalation. A single IAM model hides those differences and leads to the wrong control assumptions.
Q: Why do multi-cloud environments create more identity risk than single-cloud estates?
A: Because the risk sits in the gaps between providers. Each cloud has different permission semantics, log formats, and trust boundaries, so the same over-privilege or federation mistake can be harder to see and easier to exploit when activity crosses clouds.
Q: What should security teams look for when a cloud service can act on behalf of another principal?
A: Look for explicit source binding, narrow service scope and evidence that the service cannot be redirected into broader action than intended. If the service can be triggered across tenants or extended through transitive permissions, the organisation needs tighter policy conditions and stronger monitoring of delegated activity.
A: Credential insertion into tenant-local service principals should be treated as a high-priority escalation path. If administrators can add credentials to a principal tied to a first-party application, the tenant inherits a powerful identity risk that can bypass the intended separation between provider-managed and customer-managed control.
Technical breakdown
Why AWS confused deputy risk depends on resource policy conditions
AWS's confused deputy problem appears when a shared service can be tricked into exercising permissions against another tenant's resources. The defensive control is not a generic deny-by-default rule but a precise resource policy condition such as aws:SourceArn that binds the request to the expected source. Without that binding, the service can become an unwitting deputy carrying out an attacker-controlled action. This is a classic multi-tenant trust failure, not a credential theft problem. The key issue is that the service already has legitimate authority, so the attack works by redirecting that authority toward the wrong target.
Practical implication: Validate every cross-service trust path in AWS for source-binding conditions and treat missing condition keys as a privilege boundary failure.
How Google Cloud service agents shift the risk from direct control to provider trust
Google Cloud's service agents are single-tenant and provider-managed, which reduces direct customer control over the credential surface. That design limits one class of abuse, but it creates a different exposure: transitive access abuse, where a powerful service is manipulated into acting on the attacker's behalf. Because customers cannot tune the agent directly, the security question becomes whether the provider has built the service safely and whether the enabled service set is narrower than the default footprint. In other words, the customer inherits assurance obligations without corresponding administrative control. See the Multi-Cloud Identity Guide.
Practical implication: Limit enabled services to the minimum needed and continuously review provider-reported service behaviour for unexpected delegated actions.
Why Microsoft Entra service principal hijacking is a tenant-level identity risk
Microsoft's hybrid model places a local principal for a first-party application in the tenant, which means the tenant can hold a powerful identity that is still tied to a Microsoft-managed service. If an administrator can add credentials to that service principal, they may expand access beyond the intended scope and convert administrative control into privilege escalation. The appInstancePropertyLock reduces that risk by preventing credential insertion, but the article notes that the fix is not universally or retroactively applied. This makes service principal governance a live identity issue rather than a theoretical platform nuance. See the Identity Security Programme Guide.
Practical implication: Inventory tenant-local service principals and verify whether appInstancePropertyLock is enabled on high-impact applications.
Threat narrative
Attacker objective: The attacker wants to turn a cloud-managed identity into an authority amplifier that reaches resources, actions or privileges they could not access directly.
- Entry occurs when an attacker leverages a cloud provider's trust model, policy gap or tenant-local application surface rather than stealing a normal user password.
- Credential or authority abuse follows when a managed identity, service principal or service agent can be influenced to act with broader permissions than intended.
- Impact appears as cross-resource access, delegated action abuse or privilege escalation inside the tenant, depending on the provider model.
Breaches seen in the wild
- AI LLM hijack breach: attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Managed identity risk is now a provider-architecture problem, not a single cloud-control problem. AWS, Google Cloud and Microsoft Entra ID each shift trust and control in different ways, so the same defensive checklist will miss the real failure mode in at least one environment. Multi-cloud identity programmes need separate assumptions for who can configure, who can observe, and who can revoke. Practitioners should govern each platform on its own terms rather than assuming managed identities are interchangeable.
Cloud-managed identities expose a governance gap that many identity programmes still understate: control ownership is fragmented. In AWS, the customer must configure resource-policy conditions correctly; in Google Cloud, the provider owns the service agent surface; in Microsoft Entra ID, tenant-local principals can become escalation points. That means the question is not only whether a control exists, but who can actually enforce it. Practitioners should map control ownership before deciding which risk can be reduced internally and which must be monitored through provider assurance.
Service principal hijacking is a named concept worth tracking across enterprise identity reviews. It describes the moment when a tenant-local principal for a first-party application becomes an escalation path because credential addition or equivalent trust expansion is possible. That is materially different from ordinary role misassignment, because the identity is partly provider-owned and partly customer-visible human and non-human identity. Practitioners should treat these principals as high-risk governance objects, not just admin artefacts.
Confused deputy risk and transitive access abuse are two sides of the same cloud identity problem. In both cases, the attacker does not need to own the target identity outright; they only need to redirect legitimate authority through the provider's trust chain. That makes policy precision, service scoping and provider assurance the real control plane. Practitioners should align cloud identity governance to the specific provider pattern they are running, not to the abstract idea of 'managed identity'.
From our research library:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
- Read next: Cloud Workload Identity Guide
What this signals
Cloud identity governance now needs a provider-specific trust map. The old assumption that one managed-identity policy can cover every cloud is too coarse for modern environments. AWS, Google Cloud and Microsoft each move the control boundary differently, so the programme response has to distinguish customer-owned policy, provider-owned service behaviour and tenant-local escalation points.
Identity control ownership is the real grey zone. Managed identities are often described as background automation, but the more important question is who can actually constrain them when things go wrong. Security teams should build governance around that ownership boundary, not around the label 'managed identity' alone.
NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs, which means cloud-managed identities are part of a much larger governance problem, not an isolated edge case. As machine identities scale, the practical challenge shifts from awareness to platform-specific containment, revocation and continuous verification.
For practitioners
- Audit AWS resource policy condition keys Review every cross-service trust relationship for aws:SourceArn or equivalent source-binding conditions, especially where services can act on behalf of another principal.
- Restrict Google Cloud service exposure Keep only the services that are operationally required enabled, then monitor service-agent behaviour for unexpected delegated actions or unusual access patterns.
- Verify Entra service principal protections Check whether appInstancePropertyLock is enabled on high-impact Microsoft first-party applications and confirm which tenant-local principals can accept added credentials.
- Map identity control ownership by cloud Document which managed-identity controls are customer-configurable, provider-controlled or jointly governed so that review, detection and remediation responsibilities are explicit.
Key takeaways
- Cloud-managed identities are not governed uniformly, because each provider exposes a different trust boundary and a different failure mode.
- The AWS, Google Cloud and Microsoft examples show that confused deputy risk, transitive access abuse and service principal hijacking are separate problems.
- Identity teams should map control ownership by cloud platform before deciding which managed-identity risks can be reduced internally.
Related NHI Mgmt Group resources: Cloud Workload Identity Guide · Ultimate Guide to NHIs · Identity Security Programme Guide · Cloud Security Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on cloud-managed identities whose trust boundaries fail when source binding or tenant controls are weak. |
| NHI-05 — Overprivileged NHI | Service agents and tenant-local principals can expose excessive authority when their scope is broader than intended. | |
| NHI-08 — Environment Isolation | Cross-tenant and cross-service trust boundaries are central to the confused deputy and transitive access problems described. | |
| Recommendation — Strengthen managed-identity authentication paths so platform trust cannot be redirected across tenants or services. Reduce managed-identity privilege scope to the minimum required for each service and application. Separate trust boundaries so one cloud identity cannot be reused to influence another environment or tenant. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about how cloud identity permissions are assigned and constrained across providers. |
| Recommendation — Review entitlements for cloud-managed identities and remove permissions that are not explicitly required. | ||
| MITRE ATT&CK | TA0004;TA0008 — Privilege Escalation; Lateral Movement | The attack patterns described move from trust abuse into broader authority and cross-resource reach. |
| Recommendation — Map managed-identity abuse paths to escalation and lateral movement so detections target authority misuse, not just logons. | ||
Key terms
- CSP-Managed Non-Human Identity: A cloud provider managed identity used by services, background jobs or platform components to perform actions without human interaction. It is still an identity with permissions, trust relationships and lifecycle risk, even when the customer cannot directly administer every part of it.
- Confused Deputy: A confused deputy is a privileged system that is tricked into performing an action on behalf of an untrusted requester. In agentic AI, the agent may misread malicious input as legitimate intent and then use its own authority to act, which turns a logic problem into a security incident.
- Service Principal Hijacking: Service principal hijacking is the abuse of a tenant-local application principal by adding credentials or expanding trust in ways that increase access beyond the intended scope. It becomes especially dangerous when the principal is tied to a provider-managed or first-party application.
- Transitive Access: Transitive access is indirect reach gained through chained systems, integrations, or delegated workflows rather than through explicit direct permissions. It is a common source of hidden risk for AI agents because one allowed connection can open pathways into other services and data stores.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It helps practitioners build the governance skills needed to manage machine identities, secrets and workload access across modern environments.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org