Copilot Studio Friction

Get notified when this record changes

One email when the status or the fix changes — double opt-in, no tracking, unsubscribe in every email.

A publicly reachable agent leaks data or acts on strangers' commands

Mitigatedsince 8 July 2026

Last verified

Details & related

Assessment

Confidence
CorroboratedMultiple independent sources describe the same behaviour.
Severity
Blocking
Typical time lost
Hours

Identification

Security defaultsGovernance & DLPWeb chatDirect Line

Verification & changes

  1. Change

    Pipeline: new evidence from datadog-security-labs — review required.

  2. Verified

    Doc check by human: Datadog CoPhish post fetched on 2026-07-08 and AgentFlayer / Black Hat 2025 coverage reviewed via search: both are demonstrated proof-of-concept research, not observed mass exploitation. Authentication and DLP remain the documented controls. Test-tenant repro is pending.

  3. Change

    Provisionally approved by the Product Owner; external LLM quality review pending.

  4. Change

    Initial record created from the seed dossier (migration wave 1).

Are you in the right place?

  • Your agent is reachable without sign-in, on the web or another open channel.
  • "Require users to sign in" is off, or you are unsure.
  • Strangers could open a chat and send it instructions.
  • The agent can read data or run actions on their behalf.
  • No DLP rule blocks the unauthenticated chat connector.

If instead other agents use your agent with no trace → see Other agents can use your agent. If instead admin changes vanish from your records → see the record on missing admin audit entries.

What's happening

An agent you publish can be reachable without a sign-in. If it is, anyone who finds it can chat with it. Security researchers have shown, in the lab, how that opens two risks. First, a public agent can be steered to reveal data or run actions it can access. Second, the platform's trusted login pages can be reused to phish sign-in tokens. These are demonstrated proofs of concept, not reports of mass attacks in the wild. Vendors, including Microsoft, patched issues after responsible disclosure. Still, an open agent removes your main safeguard. Think of a shop counter with the back-office door propped open. Most visitors behave, but nothing stops the one who does not. Requiring sign-in closes that door.

For technicians

Two research strands frame this, both demonstrated as of 2026-07-08. Zenity's AgentFlayer (Black Hat USA 2025) hijacked a public-facing agent to dump CRM data with no user click. Datadog's CoPhish (October 2025) reused the sign-in topic to exfiltrate OAuth tokens. Neither is documented mass exploitation in the wild. Declarative agents published this way have no network isolation layer. So authentication and DLP are the primary enforcement layer. Note that Zenity and Datadog sell agent-security tooling. The technical findings stand and were independently reported.

How to fix it

Solution 1

Official workaround

Require users to sign in before every publish

  1. In Copilot Studio, open the agent's settings.
  2. Open "Security".
  3. Open "Authentication".
  4. Set the option so users must sign in, for example "Authenticate with Microsoft".
  5. Save the setting.
  6. Publish the agent.

✅ You should now see: users prompted to sign in before the agent responds.

Solution 2

Official workaround

Block the unauthenticated chat connector with DLP

Use this as a second, tenant-wide layer.

  1. Ask your admin to open your DLP policy.
  2. Identify the unauthenticated chat connector.
  3. Move it to the blocked group in the policy.
  4. Confirm the policy applies to the agent's environment.

✅ You should now see: the unauthenticated connector blocked for that environment.

Check that it worked

Open your agent's public link in a private browser window, signed out. Expected: you are asked to sign in, and cannot chat as an anonymous user. If DLP is set, the unauthenticated connector is unavailable for that environment.

If it didn't work

  • The change has not propagated. Publish and settings changes take time. Retest after a short wait.
  • A tenant setting overrides yours. An admin policy can allow or block channels above your setting. Confirm with your admin.
  • You tested a cached session. Use a fresh private window, signed out, each time.
  • Another channel is still open. Check every published channel, not only the web chat.

Prevent it next time

  • Make "Require users to sign in = On" a hard check in your security publish gate.
  • Treat authentication and DLP as your primary enforcement layer, not an afterthought.
  • Re-check exposure after every platform update, because defaults and channels can change.

Evidence

  • Security researchsecuritylabs.datadoghq.com

    Datadog's CoPhish research demonstrates, as a lab proof of concept, how a Copilot Studio agent's sign-in topic can be reused to exfiltrate OAuth tokens, and recommends stronger consent policies and monitoring.

  • Security researchzenity.io

    Zenity's AgentFlayer research demonstrated 0-click chains that hijacked a public-facing Copilot Studio agent to exfiltrate CRM data; vendors, including Microsoft, patched issues after disclosure.

  • Official documentationlearn.microsoft.com

    Microsoft documents the authentication options that control whether users must sign in before reaching an agent.

  • MVP blogsecuritylabs.datadoghq.com

    Demonstrates a cross-tenant agent compromise via blueprint control, directly supporting the existing record of publicly reachable agents being exploited for unauthorized access and data leakage.