Introduction

UnifyApps connects to Microsoft Copilot and returns the agents that tenant hosts, so they can be inventoried, monitored and brought under policy alongside every other platform you run.

Discovery reads Copilot's own APIs through a connection your tenant already holds. Each agent it returns becomes a record in the Agent Registry, and the traces those agents produce are collected from that point on — what they were asked, what they returned, and what it cost.

What UnifyApps discovers from Microsoft Copilot

Discovery calls Microsoft's own APIs through the connection you select and reads back the agents that tenant hosts. Each becomes a row in the Agent Registry with PLATFORM set to Microsoft Copilot.

Copilot connections return agents only. There is no model discovery on this connection, and Microsoft Copilot is not an option in + Add Model.

Capability support

Note: You do not instrument a discovered agent. Its traces arrive through the connection — there is no SDK step and nothing to install. A discovered agent shows Setup Pending until its first trace lands, which usually means it simply has not run yet, not that you owe it work. Give it real usage and it flips to Active on its own. While it is pending, the agent detail page still shows a Setup tab carrying SDK and OTLP instructions. On a discovered agent those do not apply — the tab appears for anything awaiting a first trace, however it was registered. See Agent Statuses.

Before you begin

1. Create the connection first — Discovery sweeps a connection that already exists in your tenant. It does not collect credentials. If no Copilot connection exists yet, create one before you start. See Create a Connection.

2. Know which Microsoft tenant you are scanning — One connection covers one tenant. Organisations with separate production and test tenants need one connection each.

3. Expect the count to be higher than you think — Plan who reviews the first inventory before you run it, not after.

Authentication

Authentication is handled by the underlying connection, using an identity in your Microsoft tenant with permission to list Copilot agents.

The identity needs to be able to enumerate Copilot agents across the scope you intend to govern. A narrowly scoped identity produces an inventory that looks complete and is not, so agree that scope with whoever administers the tenant before you create the connection.

Discovery only reads. It does not modify agents, change their configuration, or alter what they can access.

Refer: Discovery inherits the connection identity's visibility exactly. See How Agent Identification Works for why a narrowly scoped identity produces an inventory that looks complete but is not.

Add the connection

Step 1: Open the Add application panel

Go to AI Governance > Discovery and click + Add Application.

Step 2: Select Microsoft Copilot

Search or scroll the platform list and select it.

Step 3: Confirm the connection type

Observe · Advisory is preselected and is the only tier available for Copilot. Copilot exposes no inline control path to UnifyApps, so enforcement is not offered here.

Step 4: Choose the connection and connect

Pick the Copilot connection you want to sweep, then click Connect.

Verify: what you should see in Discovery

The new row shows PLATFORM as Microsoft Copilot, STATUS as Connected, and CONNECTION TYPE as Observe · Advisory. Once the first sweep completes, DISCOVERED shows a count of agents.

Those agents appear in the Agent Registry. Filter by PLATFORM to see only Copilot agents. Ones with no traffic yet show 0 traces and a dash under LAST TRACE; that is normal for an agent that exists but has not run since it came under governance.

Limitations

1. Observation only — UnifyApps cannot block a Copilot call — Controls set to Mask or Block cannot take effect on a Copilot agent, because UnifyApps is not in the request path. Controls set to Flag work as documented, and every violation is recorded as an incident.

2. What UnifyApps provides instead — One inventory across every platform you have connected, one policy model applied to all of them, an incident trail with the trace behind each violation, and evidence you can export against the framework you are audited on. Where you also need a call stopped in the moment, that has to happen in the runtime path — which for a Copilot agent is not a path UnifyApps sits in.

3. No model discovery — Copilot connections return agents only.

4. Coverage stops at the connection's permissions — Agents the connection identity cannot list will not appear, and will not be flagged as missing.

Troubleshooting

The sweep completed but DISCOVERED is empty. Likely cause: the connection identity cannot list agents in that tenant. Check: confirm on the Microsoft side that the identity can enumerate Copilot agents. Fix: widen the permission, then re-add the connection.

Fewer agents than the Copilot admin centre reports. Likely cause: scope. Check: whether the connection covers the whole tenant or a subset. Fix: use a connection whose identity spans the scope you intend to govern.

Agents appear but never accumulate traces. Likely cause: the agents genuinely have not run, or telemetry is not reaching UnifyApps. Check: LAST TRACE on the registry row against known usage. Fix: confirm the agents are in active use before treating this as a telemetry fault.

A Block control never blocks anything. Expected. Copilot connections are advisory. See Connection Types.