Introduction

At Microsoft Build 2025, Microsoft unveiled a new Copilot Studio capability called “Connected Agents”. Think of Connected Agents as Microsoft’s take on A2A - Agent‑to‑Agent integration.

This feature enables new functionality and introduces many interesting risks, which we review in this blog.

Why would I want to use this?

Every developer learns early on that duplicating code is a recipe for pain: when the same logic is copied across files, any bug has to be fixed in multiple places and code readability plummets when a reader sees a wall of repeated code. The solution is to wrap that logic in a single function that you call from everywhere else. 

The exact same principle applies to AI agents.

Say you built an agent with a tool that sends official emails. You meticulously defined its parameters and prompts. If you later build another agent that also needs to send emails, why repeat all that effort? Connected Agents lets you reuse the email‑sending logic you have already perfected.

How is it done?

Here’s a quick look at how it works: in Copilot Studio you’ll now find a new toggle under Settings → Generative AI. Turning it on exposes selected parts of your agent - its knowledge, tools, or topics - to ALL other agents in the same environment.

When this option is enabled, ALL other agents in the environment can invoke your agent directly or tap into the parts you choose to share. 

In the agent whose logic you want to share, switch on the Connected Agents toggle as shown above. Then open the Agents tab of another agent and click Add an agent.

Select your first agent.

You can customize the description of the connected agent, which is then used by the AI orchestrator to decide whether the connected agent should be invoked.

From this moment on, the second agent can call the capabilities of the first one.

About visibility, or the lack of it

While working in Copilot Studio and creating an agent, the “Connected agents” setting is automatically turned on and if you share it with someone else with “Editor” permissions they have the ability to connect their own agent to your agent - by design.
So how can you tell if there’s any agent that has connected to your agent? You can't. At least not from within the Copilot Studio platform. A 3rd-party product, such as Zenity’s Inventory, can give you visibility into your agents.
If you create a business critical agent with access to business knowledge or some sensitive actions like MCP connections you can now see whether it is being used by other agents and by which ones.

But wait, there’s more!

When triggering a connected agent there are zero messages that appear in the activity tab of the agent that was invoked. The same tab that was introduced to give enhanced visibility for the conversations/ actions that the agent performed is not compatible with this new feature.

This action will show zero logs in the Sales Assistant activity while the “public faced agent” activity logs will show the invocation of the connected agent, “Important Sales Assistant”

You can view the AI runtime activity in the Zenity UI, where Connected Agents activity is presented with visibility into both agents. The activity appears as two nested threads that reflect the actual sequence of events, with the same actor shown for both.

Here, you can see the message that "Public Faced Agent” sent to “Important Sales Assistant”:

Now let’s talk security

Sharing functionality also means sharing bugs and, potentially, security risks - especially if you let other users use your privileged agent.

Let’s explore a concrete risk:

Scenario: A malicious agent is using your email‑sending agent.

Let’s explore the following risky scenario: A malicious actor is using your business critical, highly privileged agent and connects their own agent as a backdoor to your agent’s action.

In this scenario, let’s say you created a customer‑facing agent that can send emails from [email protected]. The Connected Agents setting is automatically turned on so other internal agents can reuse that tool. Unbeknownst to you personally, a guest user gains access to your tenant. Suddenly they can send email from your official address.

The possibilities are ugly: phishing, misinformation, simply destroying your brand’s reputation or even spamming emails on your behalf could get your domain blocked in many different places. If you were to expose the email tool to a publicly accessible agent, any anonymous visitor could impersonate you with one click.

Let’s see this scenario play out:

Here is your perfect customer support agent, you’ve equipped it with the relevant knowledge, given it the ability to send emails on your behalf and you’ve trusted its AI orchestration to decide on its own when to use these. Of course the email must be using your email box and not the user's since this is supposed to come from the customer support email:

You proudly publish the support agent, making sure it can be reused by others.

An attacker with access to your environment (one scenario is an employee leaving soon and looking to cause trouble) adds your support agent as a dependency, connects it to their own malicious logic, and starts firing off emails that appear to have come from you.

They simply link their agent to yours and invoke the email‑sending tool:

And then the damage begins as can be seen in this simple POC:

Sure enough, emails start leaving your domain under false pretenses:

Publishing this agent and opening it to unauthenticated chat or even triggering it with a Power Automate flow could amplify the risk by enabling everyone in the internet to use the sensitive action of sending an email on behalf of the company.

All of this stems from a single agent that was built to be shared - an easy escalation path from basic access to full impersonation using your credentials.

This example highlights the major risks of Connected Agents. Fortunately, there are straightforward precautions:

How to Protect Your Organization

• Tool Authentication: Always ensure sensitive tools do not run with the owner’s credentials, ask yourself the following questions, if any of the answers are a no - you should activate authentication:
  1. Should this tool be available to all current and future users in the environment?
  2. Looking at the channels this agent is published to, should all the users of the agent be given access to activate this tool?
  3. Are you confident that no damage could be made if a malicious actor gains access to invoking the tool in its current configuration?
  To ensure tool authentication you can check the Additional details section in tool settings.

  

• Business or Sensitive Knowledge: Go over all the knowledge sources of your agent and if any of those are sensitive or contain business critical information you should disable the connected agents feature.

• Default Setting: The connected agent feature is automatically turned on on all new agents created in Copilot Studio, as a rule of thumb you should disable this setting before publishing your agent.

• Connected Agents: Before enabling the connected agents feature in your agent make sure the agent doesn’t contain any unauthenticated tools, business knowledge sources or topics that have access to business data.
  Always assume that any agent that enables the connected agents feature will be accessible to the entire internet anonymously.