PERMISSION/PROTOCOL
Back to incident tracker

2025-12-29

CriticalVendor post

Copilot Studio Connected Agents Feature Enables Silent AI Backdoors With Zero Audit Trace — Enabled by Default on All New Agents

Zenity Labs: Copilot Studio's Connected Agents feature lets a malicious agent silently invoke any trusted enterprise agent's tools with zero audit trail — enabled by default.

Microsoft Copilot StudioGovernance bypassAgent-to-agent privilege escalation / silent tool invocation / audit bypassMicrosoft Copilot Studio environments / enterprise email / SharePoint / any tool exposed by a targeted Copilot agent

What happened

Attacker creates a malicious Copilot Studio agent within the target's Microsoft 365 environment, connects it to a trusted agent with email-sending capabilities, then uses the connection to send phishing emails impersonating the organization — with zero messages appearing in the targeted agent's activity tab.

Why it matters

Any tool exposed by any Copilot Studio agent in the organization is silently accessible to any other agent in the same environment. Demonstrated impacts include organization-wide phishing via trusted email identity, data exfiltration from SharePoint and CRM, and privilege escalation through chained agent connections. Feature enabled by default on all new agents created after Microsoft Build 2025.

Missing authorization check

Agent-to-agent invocations should require a signed authorization receipt naming the invoking agent, the target agent, and the specific tool being invoked — presented to an external authority chain before the tool call executes. The invoking agent's identity must be cryptographically verified, not self-asserted.

Would PP block it?

PP's Tool-Call Gate sits between the tool call and the tool's execution — not at the audit-log level. A Connected Agents invocation that bypasses Copilot Studio's own activity tab cannot bypass an external PP gate at the execution boundary. The receipt requirement also surfaces the invoking agent's identity, making it impossible for a malicious agent to impersonate a trusted agent's actions at the external authority chain. This is a case where PP's coverage is Yes rather than Partial: the enforcement point (tool call boundary) is exactly where the attack occurs.

Incident analysis

Timeline and technical read

Timeline

  1. 2025-05-01

    Microsoft unveils Connected Agents feature at Microsoft Build 2025 — enabled by default on all new Copilot Studio agents.

  2. 2025-12-29

    Zenity Labs publishes 'Connected Agents: The Hidden Agentic Puppeteer' — documenting the zero-audit-trace backdoor mechanism and demonstrating an organization-wide phishing scenario via a malicious connected agent.

  3. 2025-12-29

    Zenity discloses: organizations cannot determine within Copilot Studio which agents have connected to their agents — only third-party inventory tools provide this visibility.

  4. 2026-06-01

    Active exploitation reports surface in June 2026 security roundups. No Microsoft patch issued. Zenity releases inline prevention tooling as a workaround.

Technical breakdown

  • Connected Agents invocations generate zero messages in the target agent's activity tab — the only audit trail appears in the invoking agent's logs, which the attacker controls.
  • The feature is enabled by default on all new Copilot Studio agents, meaning the attack surface exists organization-wide unless each agent explicitly disables it after creation.
  • An attacker needs only to create an agent within the same Microsoft 365 environment — no special permissions beyond agent creation are required to connect to any agent that has Connected Agents enabled.
  • Chained connections are possible: malicious agent → trusted agent A → trusted agent B, allowing privilege escalation through multiple levels of agent trust without any single gate catching the chain.
  • Microsoft's own Copilot Studio platform provides no native inventory of which agents are connected to which — the attack is invisible to standard enterprise monitoring without third-party tooling.

Authorization boundary

Where the authorization boundary should have been

This incident is categorized as Governance bypass. The relevant Permission Protocol gate is Tool-Call Gate. The read is conditional: the block only applies where the real action boundary is routed through a gate.

If enforced at
Tool call execution boundary, agent identity verification, external authorization receipt
Still needs
PP would not prevent a malicious agent from being created or connected within Copilot Studio — it gates the tool calls that malicious agent attempts to invoke, not the agent provisioning step.
Receipt required for
Agent-to-agent tool invocations, email sends, SharePoint reads/writes, any tool call executed via a Connected Agents channel

PP's Tool-Call Gate is exactly the missing enforcement layer — it intercepts tool calls at the execution boundary and requires a signed external receipt before any tool call executes, making the silent backdoor visible and blockable regardless of what Copilot Studio's internal audit log captures.

Start small

Put the relevant gate at this action boundary.

This incident maps to Tool-Call Gate. Start with the boundary that controls the actual action, then require a signed receipt before execution.

Replay this incident with a signer in the loop