The deputy problem never left: cloud privilege escalation through delegated trust

The deputy problem outlives every re-architecture because delegation is not a defect you can remove. It is a feature every cloud sells: a monitoring service that pages your on-call, a backup vendor that reads your buckets, your own automation assuming a role in a sibling account. Each is a decision to let a more privileged component act on your instruction, and each is safe only if the deputy can prove the instruction came from you before it spends your authority.

The class in one paragraph

A confused deputy is a privileged intermediary that performs a sensitive action for a requester without verifying the request was truly authorized for that context. The privilege belongs to the deputy; the intent is supposed to belong to you; the vulnerability is the gap where the deputy conflates the two. Nothing about the deputy is subverted at the code level, which is why these findings survive code review, single-account penetration tests, and vendor security questionnaires. The flaw lives in the trust boundary between two components, not inside either one.

Azure Monitor: CVE-2026-41105

Microsoft assigned CVE-2026-41105 to an elevation-of-privilege issue in Azure Monitor's Action Groups, the component that decides who gets notified and which automated response fires when an alert triggers. The MSRC advisory, published around 8 May 2026 and rated near CVSS 8.1, describes an elevation of privilege in which the Action Group notification and authorization handling let a lower-privileged principal drive privileged operations, moving from a reader-level position toward modifying Action Groups and the alerting they govern. Microsoft publishes limited root-cause detail here, so we will not invent internal mechanics it did not disclose. What matters is the shape: a principal with read-level access gained leverage over a configuration surface it was never granted, because a privileged handler trusted the request more than it should. That shape is a confused deputy, and the fix is the ordinary one: install the update and tighten Action Group RBAC.

AWS cross-account trust: the mechanism in full

The Azure item shows the pattern at the level Microsoft published. The AWS cross-account version shows the mechanism in full, because it is public and it is a configuration class rather than a single CVE. Here is how it goes wrong.

Suppose you run Account A and use a third-party service in Account B. To let B act for you, you create an IAM role in A whose trust policy names B's account as a Principal allowed to call sts:AssumeRole. B's automation then assumes your role and does its job. The catch is that B is a deputy for many customers at once. If your trust policy only asks "is the caller Account B?", the answer is yes for every operation B runs for anyone. As Praetorian's research puts it, the deputy "cannot differentiate between a legitimate target of a privileged action and an incorrect target." An attacker who is a customer of B, or who drives B's portal and learns your role ARN, submits your account ARN and gets B to assume your role.

The intended fix is a per-tenant discriminator called the sts:ExternalId. You add a Condition to your trust policy requiring that the assume call carry a specific external ID, a value B assigns uniquely to you and passes on every AssumeRole it makes for your account. An attacker who does not know your external ID cannot make B assume your role, even when B's automation is willing to try. The safeguard only holds when it is done correctly, and correctly is a narrow target. Praetorian tested ninety vendors and found 37 percent had not implemented the external ID correctly, and another 15 percent had interface protections that were never enforced on the server. A guessable default, a customer-selectable value, or an external ID that is not validated server-side collapses the control. The rule is blunt: only the trusted third party should generate external IDs, they should be cryptographic and non-modifiable, and the deputy must verify the customer actually uses the assigned value.

Same root cause on both clouds: delegated trust with no per-tenant discriminator. The external ID is the discriminator. Conceptual, not from any specific tenant.

The two stories share one sentence: delegated trust without a per-tenant discriminator lets a privileged component act for the wrong requester. On Azure that discriminator was missing inside a managed service's authorization handling, and Microsoft fixed it in code. On AWS it is a condition you own in your own trust policy, and you fix it in configuration. The cloud differs. The class does not.

The security question is never whether to delegate. It is whether the deputy can prove the instruction came from you, and only you, before it spends your authority.

How to recognize your exposure

You do not need to reproduce any exploit to know whether you carry this risk. Delegated trust is declared, not hidden, so the exposure is readable from policy and role metadata you already hold.

• Enumerate every cross-account and cross-tenant trust relationship. In AWS, list the roles whose trust policy allows an external account or service to assume them; in Azure, list role assignments and Action Group permissions granted to lower-privileged principals.
• Flag AWS trust policies missing an external ID or using a broad principal. A cross-account role assumable by a third party with no sts:ExternalId condition, or with a wildcard Principal, is a confused-deputy candidate on its face.
• Check whether privileged managed-service surfaces answer to read-level identities. Where a low-privilege role can influence a privileged operation, as in the Azure case, treat the delegation as suspect until proven scoped.

How Celvex catches this

The deputy problem is nearly four decades old, and it keeps resurfacing because delegation is what the cloud is for. The discipline is to make each deputy prove that a privileged action was truly requested by the principal entitled to request it, and to check that proof on the server, every time. Do that, and delegation stays a feature. Skip it, and you have handed a stranger the right to act as you.

Verifiable security. Find it. Prove it. Fix it. Verify the fix held. That is what we ship.