The Not So Boring Threat Model of CSP-Managed NHI’s

The Not So Boring Threat Model of CSP-Managed NHI’s

Speakers: Cat Traxler, Principal Security Researcher, Vector AI

Conference: BSides Las Vegas

YouTube: https://www.youtube.com/watch?v=nq1Pfhf7dDI

Overview

Cat Traxler, introducing herself as principal security researcher at Vector AI, delivers a comparative threat model of cloud service provider (CSP) managed non-human identities (NHIs) across AWS, Google Cloud, and Microsoft. She explicitly states discomfort with the NHI moniker as an industry catch-all but uses it as the shared vocabulary for identities that are not end users—especially the background principals CSPs create and manage on customers’ behalf. The talk’s structure follows a simple threat-modeling scaffold: what object is in scope, what is unique about each cloud’s architecture, what vulnerability patterns follow from those design choices, and what customers can actually prevent versus only detect. The tone is direct and comparative (“who wore it best”), culminating in a blunt grading slide and a promise of a forthcoming white paper with deeper references.

Background

▶ Watch: Cat Traxler introduces Vector AI, research focus on CSP identity boundaries, ... (2:00)

Traxler anchors her research philosophy in boundary conditions: places where technologies intersect, protocols are awkward, and assumptions accumulate. The three resource families in scope are:

• AWS service-linked roles — roles tied to AWS service principals that can be assumed into customer accounts.
• Google Cloud service agents — Google-owned service accounts associated with products/projects.
• Microsoft first-party app registrations — applications published by Microsoft that manifest as associated service principals in customer Entra ID tenants.

She highlights recurring architectural traits: multi-tenant versus single-tenant principal usage, hybrid split ownership (provider-controlled object plus customer-account role or principal), locked trust policies (AWS example: only a specific service principal can assume the linked role), birthright permissions (especially emphasized for Google), and customer-visible role bindings in Microsoft’s directory world.

Key Findings

▶ Watch: AWS architecture: multi-tenant service principals, hybrid provider/customer s... (6:00)

AWS: multi-tenant service principals and confused deputy risk. Traxler argues AWS’s model—where the same global service principal can operate across many customer accounts—creates a natural confused deputy pattern. She uses CloudTrail writing to a customer S3 bucket as the canonical example: many customers grant the shared CloudTrail service principal write access; if an attacker can influence where logs go, the multi-tenant principal becomes a pivot for cross-customer misdirection. She notes AWS calls this class of issue a cross-service concern.

Google: single-tenant agents but dangerous birthrights. Google’s design is described as single-tenant in the sense of per-project/per-product principals rather than one global principal spanning all customers. However, she argues automatic high-powered permissions assigned to service agents enable a different confused-deputy pattern: a principal you cannot directly control may still be able to read/write resources you cannot, and a customer who can manipulate a product workflow may leverage the agent’s privileges—framed as privilege escalation within a project boundary.

Microsoft: multi-tenant first-party apps and credential add risk. Microsoft’s first-party apps are described as similar to AWS in multi-tenancy: the same first-party identity can appear across many tenants. Traxler highlights a specific issue she calls service principal hijacking: the ability (in her description) to add long-term credentials to the local service principal associated with a first-party application, then authenticate as that principal and use permissions assigned in the customer tenant. She contrasts this with AWS and Google, where she states long-term credential attachment is not available in the same way.

Preventative controls are asymmetric. Traxler claims AWS customers can positively prevent the bucket-style confused deputy using condition keys that constrain actions to expected accounts or organizations. For Google, she states there is no customer-side preventative fix for the service-agent confused deputy pattern she describes; mitigation requires Google implementing caller permission checks. For Microsoft, she references app instance property lock as a publisher-side control that could block long-term credential addition, but says Microsoft has applied it inconsistently, leaving customers unable to fully prevent the credential-based escalation path for some critical first-party applications.

Technical Deep Dive

▶ Watch: Vulnerability section opens: AWS confused deputy via multi-tenant principals ... (10:00)

The analysis hinges on separating “the principal” from “the permissions customers grant.” For AWS service-linked roles, automatic creation does not automatically grant broad powers—customers still attach policies—but the trust relationship’s shape (who can assume the role) interacts dangerously with resource policies that reference global service principals.

For Google service agents, the technical story is less about cross-tenant principal reuse and more about internal privilege asymmetry: the agent may have capabilities the calling user lacks, so abuse becomes a question of whether an attacker can cause the managed service to act on their behalf.

For Microsoft, the discussion moves into Entra ID object relationships: first-party app registration in Microsoft’s tenant, service principal instance in the customer tenant, and role assignments that confer effective access. The hijacking claim is not fully specified at the protocol level in the talk; it is presented as a known, documented industry issue with years of discussion, with a white paper promised for references.

Readers should keep the trust-boundary diagram straight because the same English words (“service account,” “managed identity,” “service principal”) get overloaded across clouds. In Traxler’s framing, the CSP-managed objects are not the identities your developers create to run batch jobs; they are the machinery CSPs instantiate so their own services can operate on your resources. That distinction matters for access reviews: many enterprises audit human accounts quarterly while never reviewing the graph of first-party principals that have become embedded in tenant defaults since day one.

The AWS confused deputy story is also a useful lesson in resource policy ergonomics. S3 bucket policies are powerful because they are expressive; they are dangerous because a single overly broad statement can create cross-account effects that are invisible until someone notices odd objects landing in a bucket or unexpected write patterns in logs. Traxler’s CloudTrail example is intentionally “simple and dumb,” as she says, because the point is structural: a global principal plus a resource grant is a pattern that can scale a mistake across customers.

The Google section is a different moral: even “single-tenant” service agents can still become internal privilege amplifiers if the platform assigns powerful defaults and if product workflows can be coerced into acting on sensitive resources. That is closer to classic application-security confused deputy problems, just relocated into managed cloud services. Traxler’s recommendation pathway is not “turn off Google,” but “report to the vendor” when the behavior matches a recognized vulnerability class—an admission that some risks are not customer-tunable.

Microsoft’s section is where identity governance teams should feel the most acute discomfort. If a first-party principal can receive durable credentials in a customer tenant in the way Traxler describes, then detection engineering must include monitoring for credential materialization events on sensitive principals, not only user accounts. It also means procurement and SaaS governance need to grapple with publisher controls that customers cannot enforce—shifting the work to contractual pressure, support escalations, and regulatory attention.

Demo / Proof of Concept

▶ Watch: GCP confused deputy framed as privilege escalation; Microsoft ‘service princi... (12:00)

This session does not include a live exploitation demo. It is architecture-driven comparative threat modeling with narrative examples (for example CloudTrail bucket write permissions) rather than step-by-step exploit walkthroughs.

Defensive Implications

▶ Watch: Closing grading and CSP design recommendations; white paper teased; Q&A on pr... (20:00)

AWS: Review resource policies that grant access to global service principals; apply condition keys that bind access to your accounts/organization as described in the talk. Treat “service-linked role exists” as the beginning of governance work, not the end—permissions still need least privilege.

Google: Assume certain service-agent risks require vendor fixes; report issues through Google’s vulnerability channel when behavior matches Google-recognized bug classes. Detective controls and internal monitoring become central because customer-side prevention may be incomplete.

Microsoft: Until publisher locks are uniformly enforced, treat first-party service principals as part of identity attack surface—monitor for credential additions and anomalous usage; pressure vendors and align procurement/security assessments around identity lifecycle controls. Traxler explicitly invites more Microsoft-focused research on multi-tenant confused deputy analogs.

Operationally, teams should translate this talk into three artifacts: a cloud identity inventory that explicitly tags CSP-managed principals, a conditional policy review for AWS resource policies that reference global service principals, and a detection backlog for Google- and Microsoft-style issues where prevention is partial or absent. Without those artifacts, the talk remains interesting; with them, it becomes an audit-ready gap analysis.

If you are a defender feeling whiplash from cloud marketing symmetry—“every cloud has service accounts”—this talk is an antidote because it forces non-symmetric controls. Your AWS runbooks will emphasize policy conditions; your Google runbooks may emphasize vendor reports and internal detection; your Microsoft runbooks may emphasize Entra auditing and publisher-side lock status. Same headline risk, different owners.

Key Takeaways

• CSP-managed NHIs are not interchangeable across clouds; multi-tenancy and birthright permissions change the failure modes.
• Confused deputy risk shows up differently: AWS-style cross-customer principal reuse versus Google-style intra-project privilege escalation via privileged agents.
• Microsoft’s discussed differentiator is long-term credential attachability to certain first-party service principals—a pattern the speaker claims does not mirror AWS/GCP.
• Customer control varies: AWS condition keys are framed as real preventative tools; Google and Microsoft gaps push teams toward detection, vendor reliance, and risk acceptance documentation.
• The speaker’s design ideals for CSPs: prefer single-tenant NHIs, avoid birthright permissions, keep resources wholly provider-controlled rather than partially customer-editable in ways attackers can abuse.

About the Speaker(s)

Cat Traxler identifies herself as principal security researcher at Vector AI, focusing on CSP architectures (primarily Google Cloud, with some AWS, and increasingly Microsoft). She references a link tree for social profiles during the talk. She announces an upcoming multi-page white paper expanding references on the Microsoft credential issue.