CoPhish Attack: The New OAuth Phishing Threat in the Age of AI Agents

When Agent Platforms Become Phishing Tools

As AI agent development platforms proliferate, security boundaries are being redefined. A new attack technique called CoPhish has exposed an unsettling reality: a platform designed for building AI agents can itself become a vector for OAuth consent phishing.

For any developer building MCP (Model Context Protocol) servers or agent platforms, this is not an edge case to be dismissed. When a platform is granted the ability to act on behalf of users, every step in the authorization flow becomes a potential entry point for attackers.

The Core of CoPhish: Abusing the Agentic Authorization Flow

The logic behind CoPhish is straightforward, yet highly deceptive. Traditional OAuth phishing relies on fake login pages to trick users into granting access. On agent-building platforms, however, attackers can leverage the platform's own trusted shell to initiate authorization requests.

What the user sees is an authorization screen from a trusted platform — making it nearly impossible to tell whether the underlying app is a legitimate agent or a maliciously crafted application. Once the user clicks "Allow," the attacker obtains a token granting access to sensitive resources on the user's behalf — all within what appears to be a perfectly normal authorization flow.

"Authorization Fatigue" Amplifies the Risk

One defining characteristic of the agentic era is the dramatically increased frequency of authorization requests. To get agents working properly, users routinely grant permissions across email, calendar, file storage, and more. When authorization becomes a high-frequency, habitual action, users naturally become less careful about each individual request — and that's precisely the psychological foundation that makes attacks like CoPhish so effective.

OAuth (Open Authorization) is the dominant protocol for third-party authorization. It allows users to grant an application limited access to their resources on another platform without sharing their credentials. The standard OAuth flow includes several grant types — Authorization Code, Implicit, Client Credentials, and others — with the Authorization Code flow being the most common for user-facing scenarios: the user is redirected to the resource server's authorization page, confirms the requested scopes, and the server issues an Access Token to the third-party app. Traditional OAuth phishing hinges on forging that authorization page to trick users into thinking they're interacting with the real one. CoPhish's innovation is that it bypasses this step entirely — attackers don't need to fake any page. Instead, they register a malicious application directly on the real platform and use that platform's own trusted domain and UI to launch the authorization request. For ordinary users, this attack is virtually indistinguishable from a legitimate consent prompt, because both use the exact same authorization interface.

Defending at the Configuration Level

Against CoPhish, platform builders and enterprise administrators are not helpless. A well-considered configuration strategy can significantly reduce exposure.

Key defensive directions include: restricting which applications end users can consent to on their own, routing high-privilege app approvals through admin review; verifying the publishers of third-party apps and allowing only verified publishers into the consent flow; and enforcing minimal token scopes to prevent over-privileged access.

Special Considerations for MCP Servers

For developers building MCP servers, particular attention must be paid to the visibility and transparency of the authorization flow. When users grant consent, they should clearly understand which specific application they are authorizing and exactly what resources that application can access. Vague consent prompts are a breeding ground for phishing attacks, while clear, structured authorization interfaces are the most fundamental line of defense.

MCP (Model Context Protocol) is an open protocol led by Anthropic, designed to standardize how AI models interact with external tools and data sources. Developers can wrap external services — databases, APIs, file systems — as MCP servers, which AI models can then call through a unified interface. This dramatically expands what AI agents can do, but also introduces new authorization complexity: MCP servers typically need to access sensitive resources on behalf of users, which means every MCP server is essentially a potential OAuth client. If an MCP server developer designs the authorization flow poorly, or if a platform lacks proper review mechanisms for MCP applications, attackers can disguise malicious MCP servers as legitimate tools — and silently capture broad sensitive permissions the moment a user connects them to an agentic workflow. This makes security governance of the MCP ecosystem an issue that urgently demands attention.

Industry Direction: Entra Agent ID and WorkOS Agent Auth

At its core, the problem CoPhish exposes is that "agent identity" has not yet been properly solved. The industry is beginning to offer answers.

Microsoft's Entra Agent ID attempts to establish an independent identity layer for agents, giving each agent a manageable and auditable identity rather than simply borrowing the user's identity to perform actions. This means enterprises can govern agent accounts the same way they manage employee accounts — controlling permissions and lifecycle in a unified way.

On the other side, WorkOS Agent Auth approaches the problem from a developer tooling perspective, providing standardized authentication and authorization capabilities for agents and helping developers more securely handle authorization when agents act on behalf of users.

The emergence of both products points to a common trend: agents are evolving from "extensions of a user" into "entities that require independent identity governance." Authorization models must evolve accordingly to address emerging threats like CoPhish.

The core tension in the "agent identity" problem is this: existing Identity and Access Management (IAM) systems were designed around human users, while AI agents behave in fundamentally different ways — they can run continuously without human supervision, operate across multiple systems, and their permission lifecycles are completely unlike those of human employees. Traditionally, agents have obtained access through "service accounts" or by "borrowing user tokens" — both of which carry significant audit blind spots and privilege sprawl risks. Establishing independent identity entities for agents means defining discrete permission boundaries and access policies for each agent individually, and clearly distinguishing in audit logs whether "an agent performed this action" or "a user performed this action." This is critical for post-incident security forensics and compliance review, and represents the natural extension of Zero Trust security architecture into the agentic era.

Practical Recommendations for Agent Developers

Taken together, when building agent platforms or MCP servers, security should be built into the authorization design from the start — not bolted on as an afterthought.

Developers should apply the principle of least privilege, requesting only the permission scopes the application genuinely requires; maintain transparency in the authorization interface so users clearly understand what they are authorizing and what will be accessed; and proactively adopt emerging agent identity solutions so agents have independent, auditable identities.

For enterprise administrators, tightening end-user self-consent permissions, enabling publisher verification, and regularly auditing the list of already-authorized applications are all practical and actionable protections. CoPhish is a wake-up call for the entire industry: the more capable agents become, the more rigorously every link in the authorization chain must be scrutinized.