Confused Deputy Vulnerabilities in Multi-Tenant SaaS Architectures

Confused deputy vulnerabilities in multi-tenant SaaS exploit a gap between valid identity and legitimate intent. A service can authenticate a request correctly and still misuse its authority on the caller’s behalf. Cloud services, bundled APIs, and AI agents expose different versions of this problem. Closing it requires more than checking credentials. Systems must preserve whose authority a request represents, what that authority permits, and which tenant it applies to.

Why multi-tenant SaaS is structurally prone to confused deputy attacks

Multi-tenant SaaS puts shared services in a difficult position. They need enough authority to serve many customers, but each request should exercise only the authority appropriate to its caller. Cloud-native, microservices-based systems spread that responsibility across service-to-service calls. A downstream service may hold permissions its caller does not, while the caller’s tenant context must survive every hop. Delegation is necessary, but it is not self-policing.

Computer scientist Norm Hardy coined “confused deputy” in a 1988 paper after discovering the problem in a compiler at Tymshare, a commercial time-sharing firm. The distinction remains straightforward. Authentication asks who is making a request, while authorization asks whether that caller may cause this action against this tenant’s data. A service’s valid credentials answer only part of the second question.

Headers may be trusted because they arrived from an internal network, or over-scoped tokens may be reused beyond their intended purpose. Downstream components may skip checks because they trust an upstream service. These are different ways to lose request provenance, the connection between an action and the principal entitled to request it. Spotting that loss helps defenders find flaws in what looks like ordinary, authenticated service traffic.

What confused deputy exploitation actually looks like across cloud platforms

AWS IAM documentation describes the canonical pattern through an overly permissive bucket policy. Any AWS account can instruct ELB to write logs to a bucket it does not own. The service has permission to write, but the caller’s entitlement to select that destination is not sufficiently constrained. The credentials work exactly as expected.

Azure Automation CVE-2025-29827, rated CVSS 9.9 and patched in May 2025, crossed a tenant boundary more directly. An attacker with access to their own Azure Automation account could assume another tenant’s automation identity. The chain used a default configuration that left automation accounts open to the public, along with two separate code-level bugs. Its impact included creating or modifying automation scripts, accessing sensitive configuration data or credentials, and creating, changing, or deleting resources across an organization’s cloud workloads.

O’Leary disclosed GCP Config Connector’s “ConfigConfusion” on June 18, 2026, and rated it CVSS 9.9. The connector accepts instructions from Kubernetes and executes them against GCP IAM using its own elevated credentials, without verifying that the Kubernetes user has equivalent GCP IAM permissions. O’Leary calls this a systemic problem, following the pattern Google had already patched in ImageRunner and ConfusedComposer. As of late 2026, the issue remained unpatched.

Google’s response places responsibility on customers to set appropriate permissions. O’Leary counters that configuration cannot supply a check the connector has no means to perform, namely whether that user may request those permissions on that target. Attribution fails at the same boundary. The attacker’s actions are logged as service account activity, masking the attacker’s identity in IAM audit logs.

SANS’s analysis also describes a confused deputy vulnerability in Microsoft Defender for Cloud, reported by instructors Brandon Evans and Eric Johnson. Customers give the service broad rights to scan their cloud environments. Under certain conditions, one customer’s security findings could be disclosed to unauthorized third parties. Microsoft rated the vulnerability Critical, showing that security tooling can occupy the deputy’s position too.

How Temporal CVE-2025-14986 shows the flaw operating inside application logic, not just cloud configuration

Temporal CVE-2025-14986 needs no misconfiguration to produce a confused deputy. The authorization check passes, but request preparation uses a different namespace without flagging the mismatch. The system behaves as specified. The specification is the vulnerability, because the outer request and inner payload supply competing sources of namespace identity.

In the cross-tenant exploit, the attacker authenticates against AttackerNS while naming VictimNS inside the payload. The outer authorization check approves the attacker’s namespace, but request preparation uses the victim’s private schema, including custom Search Attributes. The attacker’s database stores the result. Temporal breaches isolation by touching the victim’s configuration to process someone else’s request.

The “Bring Your Own Policy” variant reverses the relationship. A developer authenticates against CorporateNS, which enforces execution timeouts, retry limits, and archival settings, but points the inner payload at a permissive PersonalNS. The workflow executes inside the corporate environment while ignoring its rules. An otherwise-authorized user has injected a shadow policy through a nested field.

Bundled APIs create this seam by chaining operations into one request. If stages get identity from different fields, passing a check at the start does not give the caller authority for every step that follows. The deputy becomes confused inside the request, before any cloud configuration needs to enter the story.

Why AI agents are the most exposed confused deputies in enterprise infrastructure today

SANS’s May 2026 analysis by Kenneth G. Hartman focuses on the risk from all the access an agent has at once. A single agent may hold credentials for a cloud provider, email, a code repository, a ticketing system, and multiple SaaS applications. Each credential may satisfy least privilege individually. Together, however, they create a scope of action far beyond what a single service account was designed to hold.

The same analysis finds that prompt injection and changes in what a task needs also break with what traditional IAM assumes. An instruction inside an email, document, or API response can redirect the agent, while its legitimate access needs change with each task. Static permissions fit that movement poorly. The Model Context Protocol, becoming a standard interface between agents and tools, relies on OAuth 2.0 for authorization but does not address credential storage, lifecycle management, or policy governance before issuance to agents.

A 2026 GitHub escalation chain shows how that exposure becomes an attack. An authenticated issue-triage bot with broad repository access processed a crafted issue title containing an instruction. The attacker then flooded the shared GitHub Actions cache with over 10 GB of junk data, evicting legitimate entries through LRU eviction and replacing them with poisoned entries. A privileged nightly release workflow restored the poisoned cache. The attacker gained execution inside a job holding the project’s npm publishing token.

The March 2026 TeamPCP campaign illustrates the related danger of credential concentration. Attackers compromised LiteLLM, an AI gateway proxy used by thousands of enterprises to route requests to LLM providers. Its role holding API keys for dozens of AI services made it a high-density target. The attack harvested SSH keys, cloud credentials, LLM API keys, and database passwords. This attack stole credentials, while the GitHub attack had an agent follow injected instructions, but both used the reach that AI infrastructure brings together [1][16].

Cross-tenant credentials give an attacker even more reach, because a compromised agent can read data with the authority it already has, without bypassing a control. Reference frameworks have not fully caught up. Crew Scaler’s analysis submitted to NIST found Non-Determinism and Data Leakage were the most under-addressed domains for multi-agent systems across sixteen reviewed frameworks.

How prompt injection turns the agent's legitimate credentials into the attack's delivery mechanism

Cloud Security Alliance AI Safety Initiative’s March 2026 research note describes prompt injection as a way to turn tool-using agents into confused deputies [1][16]. The attacker need not steal a credential. Instead, the attacker gives the agent words that make it use credentials it already has. The authentication layer sees the identity it expects, but the instruction now comes from someone else.

An attacker with access to a single project hides instructions inside an HTML comment. The comment is invisible in the Azure DevOps UI but arrives verbatim in the agent’s context when a victim asks for a pull request review. Those instructions hijack the agent’s goal, causing it to act across projects the attacker cannot reach directly.

The agent’s credentials remain legitimate throughout the attack. The agent’s technically permitted, attacker-directed cross-project action parallels Config Connector executing against GCP IAM without checking the Kubernetes caller’s equivalent permissions. In the agent case, the missing check concerns whether an instruction came from the principal or from adversarial content encountered during the task.

IAM policies, firewall rules, and MFA do not establish that distinction merely by accepting a legitimately routed request. They constrain identity and access. The deputy has a valid badge and the wrong instructions. That is the same gap between authenticated identity and verified intent that made Tymshare vulnerable decades earlier, despite the very different interface.

Where defenders have actual controls, and where the structural gap remains open

Defenders do have tools, and those tools reduce exposure. AWS recommends using aws:SourceArn, aws:SourceAccount, aws:SourceOrgID, or aws:SourceOrgPaths in resource policies wherever an AWS service principal gets access to a resource. These conditions directly address the overly permissive bucket-policy class of flaw. In OIDC-federated architectures, complete JWT validation must include the aud and iss claims. Skipping checks on the intended audience or issuer leaves a gap as more CI/CD pipelines use non-human identities and Workload Identity Federation.

For Temporal, patched code must use one authoritative namespace identity throughout request processing, with explicit reconciliation of identity fields in nested operations. A check at the boundary alone cannot fix a clash between sources of identity later in the chain. The request must retain the same authority as its meaning develops.

For agents, SANS advocates a credential broker using SPIFFE/SPIRE. Each agent receives a cryptographic workload identity through an X.509 certificate tied to its runtime environment and subject to periodic re-attestation. The approach dynamically bounds access to the current task instead of leaving broad credentials permanently attached to the agent. It addresses standing authority, though identity attestation is not itself proof that an instruction reflects the principal’s intent.

Config Connector shows where actionable configuration advice reaches its limit. Appropriate permissions cannot replace an absent mechanism for checking whether a Kubernetes user may request particular GCP IAM permissions against a particular target. Enforceable policy controls must therefore be paired with runtime visibility into what agents and service principals actually do.

Complete audit logs also need meaningful attribution to support investigation. ConfigConfusion’s service-account attribution shows why reviewing logs afterward is insufficient when the attacker has disappeared into the deputy’s identity. Runtime monitoring gives operators a chance to detect misuse as it happens. Otherwise, the investigation begins with a record identifying only the credential holder.

How to recognize confused deputy exposure in your own SaaS architecture

Authority transitions warrant inspection, starting with requests that contain more than one identity field. Temporal supplies the question to ask. Does the same verified namespace govern authorization, routing, schema lookup, and policy evaluation, or can an inner payload select a different one? An envelope-and-payload API deserves scrutiny wherever those answers diverge.

Next, check services that translate between permission systems. Config Connector shows the risk when Kubernetes RBAC permits an instruction but no layer maps that permission to the GCP IAM target. Defender for Cloud adds a related tenant-isolation question. Can one customer’s action influence another customer’s data or findings because a shared vendor service fails to partition its output?

Agent access calls for an inventory of combined authority alongside separate credential reviews. The GitHub case shows how an input-processing bot can become an entry point to a privileged release job. Audits should check whether a single identity token authorizes actions against more than one tenant’s resources. LiteLLM also shows the risk built into standing, broad-scope credentials, including when agents or automation services get them without re-attestation.

Finally, inspect the attribution attached to privileged actions. ConfigConfusion shows the danger when an action that needs principal-level authority is logged only under a service account or managed identity. Such a record cannot distinguish legitimate delegation from exploitation. The aim is not to catalogue every possible deputy, but to recognize the recurring substitution wherever it appears, when valid identity is accepted as sufficient proof of legitimate intent.