{"slug": "cophish-and-the-agentic-consent-problem-oauth-phishing-for-the-agent-builder-era", "title": "CoPhish and the Agentic Consent Problem: OAuth Phishing for the Agent-Builder Era", "summary": "Datadog Security Labs disclosed in October 2025 that Microsoft Copilot Studio could be abused as an OAuth phishing vector, with agents hosted on the trusted copilotstudio.microsoft.com domain able to point sign-in at an arbitrary redirect target and silently forward the resulting OAuth token to an attacker-controlled server via an outbound HTTP call. Datadog reported that ordinary users could consent to Graph scopes including mail read/write, mail send, chat, calendar and notes under Microsoft's default consent policy, while Application Administrators and Cloud Application Administrators could consent to any Graph permission for any app. Microsoft acknowledged the report, said it is evaluating further hardening of its default consent and governance experience, and noted the technique relies on social engineering rather than a software vulnerability.", "body_md": "# CoPhish and the Agentic Consent Problem: OAuth Phishing for the Agent-Builder Era\n\nCoPhish showed that an agent-building platform can itself become an OAuth phishing vector. Here's what that means for anyone building MCP servers or agent platforms, how to configure against it, and what Entra Agent ID and WorkOS Agent Auth reveal about where the industry is headed.\n\nMost OAuth phishing coverage still describes a single, familiar shape: an attacker registers a look-alike app, sends a lure, and hopes the victim doesn't notice the consent screen belongs to an app they've never heard of. That shape is well understood, and well defended against: least-privilege scopes, redirect URI allowlists, consent-grant monitoring.\n\nCoPhish, [disclosed by Datadog Security Labs](https://securitylabs.datadoghq.com/articles/cophish-using-microsoft-copilot-studio-as-a-wrapper/) in October 2025, is a different shape. It doesn't need a look-alike app at all. It uses a real, trusted, first-party platform, Microsoft Copilot Studio, as the delivery mechanism for the exact same consent attack, and in doing so it points at a risk surface that's going to matter a lot more as more products let users build and host their own agents.\n\n## What CoPhish actually did\n\nCopilot Studio lets anyone build a chatbot (\"agent\") and optionally publish a demo of it on a URL under Microsoft's own domain, `copilotstudio.microsoft.com`. Datadog's researchers found that an agent's sign-in configuration (the button a user clicks to authenticate) can be pointed at an arbitrary redirect target, including a malicious OAuth consent request. Once the victim clicks through and approves the consent prompt, the agent's own workflow logic (its \"topic\") can be configured to silently forward the resulting token to an attacker-controlled server via an outbound HTTP call.\n\nThe result: a phishing page hosted on a genuinely trusted Microsoft domain, a real OAuth consent screen belonging to a real (if malicious) app registration, and token exfiltration that happens server-side from Microsoft's own infrastructure, so it never shows up in the victim's browser network traffic. Two populations turned out to be exposed even under Microsoft's default consent policy: ordinary users, who could still consent to a specific set of Graph scopes (mail read/write, mail send, chat, calendar, notes) under the default \"allow user consent for apps from verified publishers\" style policy; and Application Administrators or Cloud Application Administrators, who can consent to *any* Graph permission for any app, making them a much higher-value target for exactly the same technique. Microsoft has acknowledged the report and said it's evaluating further hardening of its default consent and governance experience, while noting the technique fundamentally relies on social engineering rather than a software vulnerability.\n\n## Why this isn't really a Microsoft-specific story\n\nStrip away the Copilot Studio branding and the underlying pattern is:\n\n1. A platform lets users build and host something (an agent, a bot, an integration) under the platform's own trusted domain.\n2. That something can initiate an OAuth consent flow with a configurable, attacker-controlled destination or app registration.\n3. That something can then take an automated action after consent (in this case, an HTTP call that exfiltrates the token) with no further user visibility into what happens post-approval.\n\nNone of those three properties are unique to Copilot Studio. They describe the shape of a lot of the agent tooling shipping right now: agent builders, GPT-store-style directories, MCP server marketplaces, low-code automation platforms, internal \"connect your tools\" flows. Any platform where a third party can configure (a) a login/consent step and (b) a post-consent automated action, hosted under a domain the user already trusts, has the structural ingredients for a CoPhish-shaped attack, regardless of which identity provider issues the token.\n\nThis is the part that doesn't show up in most of the current CoPhish coverage, which is written almost entirely for Microsoft 365 admins hardening their own tenant. If you're building an agent platform, an MCP server marketplace, or any product where users or partners configure agents that touch OAuth, the more useful question isn't \"how do I protect my org from CoPhish,\" it's \"does my own product have a CoPhish-shaped hole in it.\"\n\n## What to actually check if you're building agent or MCP infrastructure\n\n- **Audit what your \"connect\" or \"sign in\" step in the agent builder can be configured to do.** If a no-code or low-code agent builder lets a user or partner point a login button at an arbitrary URL, or lets a workflow step make an arbitrary outbound HTTP call, you've built a general-purpose consent-phishing kit into your own product: the same mechanism CoPhish used, just under your domain instead of Microsoft's. At minimum, redirect targets in a \"connect account\" or \"sign in\" builder step should be restricted to a known allowlist, not a free-text field.\n\n- **Treat post-consent actions as a privileged capability, not a default builder feature.** The part of CoPhish that made exfiltration silent wasn't the phishing page; it was the ability to attach an automated HTTP action to the sign-in step itself. If your platform lets a workflow step run immediately after an OAuth callback, that step should be reviewable, auditable, and ideally gated behind a permission tier above what a default user or unverified partner has.****\n- **Bind tokens to the resource they're actually for.** This is the same mitigation that matters for MCP server security generally: if a token is scoped and audience-bound to a specific resource (RFC 8707 Resource Indicators), a workflow step that tries to forward it somewhere else is forwarding something that won't validate at the destination. A CoPhish-style exfiltration step is a lot less useful if the token it steals only works against the one resource it was issued for.****\n- **Separate \"who can build an agent\" from \"who can grant that agent high-risk scopes.\"** Datadog's own recommendation for Microsoft 365 tenants (disable the default that lets any user register applications, and restrict elevated consent to admins who go through an explicit review) generalizes directly. If your platform has an equivalent of \"any user can spin up an integration,\" decide deliberately which scopes that path is allowed to request without a review step, the same way you'd think about default OAuth app consent policy.****\n- **Instrument agent-creation and consent-grant events together, not separately.** Datadog's detection guidance centers on correlating two signals that are usually monitored in isolation: application-consent events and agent/bot-creation or modification events in the builder itself. A spike in consent grants immediately following a burst of new agent creations from an unfamiliar account is a much stronger signal than either one alone. If you operate an agent platform, the equivalent pairing is \"new agent/connector created\" plus \"OAuth grant issued to that agent\" in a short window from an account that doesn't normally do either.\n\n- **Don't rely on domain trust as a phishing signal, in either direction.** The entire reason CoPhish works is that \"hosted on a domain we trust\" and \"safe to click\" got conflated. If your product hosts any user- or partner-generated content under your own domain (demo pages, published agents, embeddable widgets), that content inherits your domain's trust without inheriting your product's authorization review. Worth stating plainly to your own users, too: a login prompt appearing inside your product's domain is not, by itself, evidence that your product built it.\n\n## The fix is already shipping, just not fast enough to have stopped this\n\nTwo developments since CoPhish went public show the industry arriving, slowly, at the same conclusion this piece has been arguing: an agent needs to be a first-class, governable identity, not a service account with a login button bolted on.\n\nMicrosoft's own answer landed as **Entra Agent ID**. Since July 2026, every new Copilot Studio agent automatically gets a distinct Entra identity; there's no opting out at the environment level anymore. That doesn't retroactively patch CoPhish; the underlying technique is still social engineering, and Microsoft has said as much. But it does close a real part of the gap that made CoPhish hard to catch in the first place: before Agent Identity existed, an agent riding on a shared app registration was invisible in the audit trail as a distinct actor. Now an admin can list every agent in a tenant from a central inventory, distinguish \"modern\" agents covered by the identity platform from legacy service-principal agents predating it, and apply Conditional Access, sign-in risk detection, and compromise-confirmation workflows to an agent the same way they would to a user.\n\nWorkOS shipped the same category of fix for teams building their own agents. **Agent Auth**, in early access in AuthKit since September 2026, replaces the two bad options teams have been stuck with (hand the agent a long-lived API key, or let it borrow a user's session) with real identities defined by blueprints: what an agent is allowed to do, issued as short-lived, tightly scoped tokens on every run, delegated on behalf of a user or scoped autonomously within an org, and revocable instantly.\n\nNeither of these prevents someone from building a CoPhish-shaped consent trap inside a no-code builder; that's a product-design problem, not an identity-architecture one. But they both shrink what's at stake if it happens: an agent with its own auditable identity and a short-lived, narrowly scoped token is a much smaller blast radius than an agent quietly holding a long-lived Graph token nobody's tracking.\n\n## The broader pattern\n\nCoPhish is a preview of what OAuth phishing looks like once \"the app requesting consent\" and \"the thing a user configured themselves\" become the same object. That's exactly the direction agent platforms, MCP marketplaces, and no-code integration builders are all heading. The defenses aren't exotic: scope review, redirect allowlisting, audience-bound tokens, correlated monitoring, and now first-class agent identity. But they only work if you've recognized that your agent-builder surface *is* an OAuth trust boundary, not just a product feature sitting next to one.\n\nIf you're building or securing agent infrastructure, the direction Entra Agent ID and WorkOS's own Agent Auth both point at is the fix this piece has been arguing for throughout: treat the agent as its own accountable identity, not a bearer of someone else's token. If you're building or securing an MCP server specifically, resource-bound tokens and Protected Resource Metadata (RFC 8707 / RFC 9728) close a related gap at the protocol level. Worth checking which of these your own stack already has, and which it's still missing.", "url": "https://wpnews.pro/news/cophish-and-the-agentic-consent-problem-oauth-phishing-for-the-agent-builder-era", "canonical_source": "https://workos.com/blog/cophish-and-the-agentic-consent-problem-oauth-phishing-for-the-agent-builder-era", "published_at": "2026-09-29 00:00:00+00:00", "updated_at": "2026-09-29 15:50:08.236337+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "agent-protocols", "ai-policy"], "entities": ["Datadog Security Labs", "Microsoft", "Microsoft Copilot Studio", "Entra Agent ID", "WorkOS Agent Auth", "Microsoft Graph"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/cophish-and-the-agentic-consent-problem-oauth-phishing-for-the-agent-builder-era", "markdown": "https://wpnews.pro/news/cophish-and-the-agentic-consent-problem-oauth-phishing-for-the-agent-builder-era.md", "text": "https://wpnews.pro/news/cophish-and-the-agentic-consent-problem-oauth-phishing-for-the-agent-builder-era.txt", "jsonld": "https://wpnews.pro/news/cophish-and-the-agentic-consent-problem-oauth-phishing-for-the-agent-builder-era.jsonld"}}