On the same day NVIDIA stood up a 37-member coalition to build safer AI, and Microsoft rolled out a new AI stack it says will change the “physics” of cybersecurity, a much quieter story ran in Dark Reading. Researchers had found confused deputy flaws still alive in Google Cloud and Azure, the same two platforms half the alliance’s members run their workloads on. Nobody planned that juxtaposition. It happened anyway, and it’s the more honest story of the two.

The Open Secure AI Alliance is a genuinely big deal on paper: Microsoft, Cisco, Cloudflare, CrowdStrike, Hugging Face, IBM, Palo Alto Networks, Red Hat, and dozens more, all agreeing to share tooling for securing AI agents. Microsoft used the same week to introduce MAI-Cyber-1-Flash, a model purpose-built for vulnerability hunting, and Project Perception, which it’s pitching as a rethink of the entire security stack for an AI-driven threat landscape. That’s a lot of forward motion. It’s also a lot of attention pointed at the frontier while a decades-old class of bug sits unresolved in the infrastructure underneath it.

What a Confused Deputy Actually Is, and Why It Never Really Goes Away

The confused deputy problem is old enough to predate the term “cloud computing.” A deputy is any service that holds more authority than the party asking it to act, and gets tricked into using that authority on someone else’s behalf. In a cloud context, that usually means one service assumes a role or crosses a trust boundary to do work for a customer, and the provider’s plumbing doesn’t verify closely enough who actually asked for it. Get that verification wrong and an attacker can ride along on a legitimate service’s permissions straight into administrative access, no credential theft required.

What Dark Reading’s reporting makes clear is that this isn’t a one-off misconfiguration somebody will patch and forget. It’s a structural risk in how major clouds broker trust between their own internal services and customer accounts. Google Cloud and Azure have both shipped fixes for specific instances of it. The category keeps producing new instances, because the underlying pattern, service A trusting service B’s identity without adequately scoping what B is allowed to do on A’s behalf, is baked into how these platforms are built for scale.

Now the Deputies Are Agents, and They Have More Access Than Ever

Here’s where the two stories actually touch. The entire pitch behind the Open Secure AI Alliance, and behind Microsoft’s new cyber stack, is that AI agents are becoming first-class actors in enterprise environments: reading tickets, querying databases, calling APIs, sometimes provisioning infrastructure. Every one of those agents is, functionally, a deputy. It’s been handed some scoped authority and asked to act on a human’s behalf across a trust boundary. That’s precisely the architecture confused deputy attacks exploit.

An AI agent with broad service-account permissions, invoked through a chain of intermediary calls it didn’t originate, is a textbook setup for this bug class, just with a chatty new front end. Alliance members can publish all the shared threat-protection frameworks they want; none of it closes a hole in the identity brokering underneath the agent. Defense in depth has to include the layer nobody’s demoing at a keynote.

Hardening the Trust Boundary, Not Just the Model

None of this requires waiting on a cloud provider’s next security bulletin. There’s concrete work available right now for anyone running production workloads on Google Cloud, Azure, or AWS, agentic or not.

Start with an audit of every resource-based policy and role trust relationship in the environment, looking specifically for wildcard principals or overly permissive cross-account assumptions that were set up for convenience and never revisited. Require external IDs on any role that can be assumed by a third party or another internal service, and reject assumption requests that omit one. Instrument logging so that cross-tenant or cross-account API calls generate a distinct signal your threat detection stack actually watches, rather than blending into normal service traffic. If you’re deploying AI agents with service credentials, treat those credentials as a distinct identity class in your incident response runbooks, with their own least-privilege scoping and their own alerting thresholds, not an extension of whatever human account provisioned them.

None of this is glamorous. It’s the unsexy security hardening work of narrowing what a deputy is allowed to do and verifying who’s actually asking it to act. It won’t get a keynote slot, but it closes the gap the alliance’s own premise depends on.

Frequently Asked Questions

What is a confused deputy vulnerability?

It’s a flaw where a service with elevated permissions gets tricked into performing an action on behalf of an attacker, because the system didn’t properly verify who originated the request. The service isn’t compromised directly; it’s misused.

Are the Google Cloud and Azure confused deputy flaws patched?

Specific instances reported to date have been addressed by the providers, but security researchers argue the underlying architectural pattern that produces this bug class remains present and will keep generating new cases.

Does this affect companies not using AI agents?

Yes. Confused deputy risk exists anywhere services assume roles or cross trust boundaries on a customer’s behalf. AI agents raise the stakes because they’re increasingly granted broad, automated permissions with less human review of each individual action.

Sources

• ‘Confused Deputy’ Flaws Persist in Google Cloud, Microsoft Azure
• NVIDIA Forms 37-Member Open Secure AI Alliance and Open-Sources NOOA Framework
• CrowdStrike Joins the Open Secure AI Alliance to Advance AI Safety and Security
• Rethinking security for the age of AI
• Microsoft unveils MAI-Cyber-1-Flash, promises cybersecurity AI at half the cost