How Arcade Proactively Addressed The First Major Identity Vulnerability in Agentic AI

While building an AI demo has become trivially easy, production-grade deployments in enterprises have been stifled by performance issues, costs, and security vulnerabilities that their teams have been warning about.

Today, we're addressing one of those vulnerabilities head-on.

A new class of identity attack

Security researchers at The Chinese University of Hong Kong recently identified new variants of COAT (Cross-app OAuth Account Takeover), an identity phishing attack targeting agentic AI and integration platforms. They presented their findings at Black Hat 2025, demonstrating how connection-based OAuth architectures used in these platforms can be exploited to gain unauthorized access to enterprise systems.

The attack mechanism is straightforward but dangerous:

1. A malicious actor (Mallory) initiates an authorization flow for (as an example) a GitHub integration
2. Instead of completing the flow themselves, Mallory sends the authorization link to a victim (Bob)
3. If Bob clicks the link and authorizes (or if GitHub auto-authorizes because Bob has previously connected a similar integration), the authorization completes
4. Because the original session belonged to Mallory, Mallory now owns the GitHub integration with Bob's access – resulting in an account takeover.

This isn't a passive vulnerability. It requires active phishing. The victim must click a malicious link and, in most cases, actively consent to authorization. But as any security team knows, phishing and spearphishing are effective attack vectors… and when you are an agentic runtime like Arcade, the human factor is a risk worth addressing.

Why this matters for agentic AI

As enterprises are increasingly building agents that need to connect with business systems, they leverage technologies like Arcade and others to help broker the secure connection. This means the emergence of what the researchers call "connection-based OAuth" or "OAuth-as-a-Service" – centralized token management systems that create abstract "OAuth connections" as handles for managed tokens.

If not carefully and securely built, OAuth connection platforms can fall prey to a number of documented attacks against OAuth. And in the most severe scenario, an attacker doesn't even need an account in your organization. They can create an account on an app using a shared OAuth infrastructure, trigger an auth flow, and phish users across completely different organizations. Trust relationships already exist, many users have already consented to broad access, and absent-minded users often click links without inspecting them too closely.

Arcade's response: Upgrade the authorization flow

Due to Arcade’s position within enterprise accounts and the team’s security background, Luo et al privately approached us in April 2025 with their research findings. Our response was unequivocal: this needed to be fixed, and fixed properly. Our customers are some of the largest enterprises deploying production agents, so this wasn't negotiable. In discussing some different solutions, we also knew we needed to maintain two guiding principles for the product:

• Keep Arcade easy to use
• Remain secure by default whenever possible 

Ultimately, this meant we needed to redesign Arcade’s authorization flow by introducing mandatory user verification. Apps and agents built on Arcade now have two options, each appropriate for different stages in your project’s lifecycle:

• Arcade user verification: During authorization, users are prompted to sign in to their Arcade account (if they aren't already). This is ideal for getting started, internal projects, and proofs of concept—simple, secure by default, with no additional development required.
• Custom user verification: For production deployments, Arcade can delegate to a route in your application that performs session checks, so your end users never need to interact with Arcade directly. Your users remain entirely within your application's authentication context and UX.

Full details of these approaches can be found here: docs.arcade.dev/en/home/auth/secure-auth-production.

Both approaches accomplish the same goal: they securely bind the authorization flow to a verified user session while remaining invisible to the end user. When Bob receives that phishing link from Mallory, his browser is enlisted to help verify his identity before the flow can complete. The system will detect that the session belongs to Bob but the authorization was initiated by Mallory, and the flow will be correctly rejected to keep Bob safe.

Protected Scenarios

This approach eliminates both cross-tenant and cross-account attack variants:

Cross-tenant attacks: A malicious actor with an Arcade account tricks a victim who uses a completely different Arcade-based application. Previously possible in some cases where trust relationships and OAuth apps were shared. Now prevented in all cases, because user verification ensures the user completing the flow matches the user who initiated it, and OAuth URIs must be unique

Before

After

Cross-account attacks: A malicious actor with an account in your application tricks another user of your application. Previously possible because user identity wasn't verified during authorization. Now prevented through the same user verification mechanism.

Before

After

Other approaches we evaluated

When we first reviewed this vulnerability with the research team, we explored several mitigation strategies before landing on the user verification approach. Each had appeal, but ultimately failed to address the root cause: the lack of real binding between the user initiating authorization and the user completing it. Here are the approaches we explored that didn’t make the cut: 

• PKCE (Proof Key for Code Exchange) was our first instinct. It's an important part of the OAuth security story for untrusted (public) clients, and OAuth practitioners naturally reach for it. But PKCE doesn't help here since the attacker controls the initial request and PKCE only helps guarantee the integrity of the request itself. When the victim completes the flow, they're simply fulfilling the attacker's challenge.
• Cryptographic signing of the initial request was tempting but faces the same problem. The attacker is initiating the flow. They're the ones generating and signing the request. All this would do is validate the attacker's input, rather than prevent the attack.
• Validating user identity returned by third-party IDPs/AS. Some identity providers and OAuth authorization servers return information about the user who is authorizing, but not all do. And the ones that do return them in a variety of different formats: Github identifies you by a @username and Gmail identifies you by an email address.
• Aggressive timeouts also seemed tempting: Make the authorization window so short that it becomes harder to exploit. But that doesn’t make it impossible. For example, spearphishing via Discord, SMS, IRC Slack, or other chat systems could bypass this with a well-timed attack. A clever and motivated attacker could get a victim to click a link very quickly if they’re already at their keyboard. Furthermore, a time window short enough to truly prevent this attack would also make your application/agent unusable - it’s an impossible tradeoff. 
• Security through obscurity, such as hiding flows inside iFrames or browser popups. This again could make it harder to exploit but wouldn't stop an experienced attacker who can work around client-side obfuscation easily.
• Requiring dedicated OAuth apps and redirect URIs for every project solves part of the problem, and is already supported by many platforms including Arcade. This helps mitigate the cross-tenant scenario, but does not eliminate the cross-account attack vector where both the attacker and victim use the same application. 

The fundamental issue with all these faux-mitigations is that the user’s identity is never actually confirmed. Which meant the only real solution is the one we implemented: binding the authorization flow to a verified user session. Everything else is security theater.

Arcade’s call to action for the industry

COAT represents exactly the kind of security challenge that security teams have been concerned about as enterprises rush to deploy agents. While the hype cycle focuses on what agents can do, production security teams are asking: "Can we actually deploy this safely?" The answer must be yes; but only if the industry takes these vulnerabilities seriously.

The Arcade Runtime is trusted by some of the largest enterprises that are deploying real agents to production. This means security isn't an afterthought, it's foundational to our architecture. That's why we opted to address this change proactively and rolled out the fixes months ago. We're not waiting for an exploit in the wild. We're not treating this as a theoretical concern. We fixed it, before it becomes a problem for any of our customers.

Not all integration platforms have mitigated COAT, but we hope they follow suit. As enterprises build and deploy AI agents in production at scale, they can't afford to work with technologies that treat security as an afterthought. They need to trust that their technology partners will make the hard architectural decisions as needed – even if it means significant engineering investment.

Arcade is one of the pioneers leading this charge of security-forward agentic deployments, working with the world’s leading security researchers. We're committed to staying at the forefront because we believe the future of agentic AI depends on it. The enterprises actually deploying agents at scale – the ones moving beyond demos into production systems handling sensitive data and critical workflows – need partners who prioritize their security posture as much as their developer experience. That's the standard we hold ourselves to, and we're not backing down from it. Because the promise of agentic AI isn't just what agents can do—it's whether enterprises can trust them to do it safely.