4 properties your Copilot Studio agent might be logging in clear text

You spent months deciding what your agents can read and who they authenticate as. None of that governs what they write out. The moment a maker flips one Application Insights setting, your agent starts copying prompt and response text — sensitive-labelled content and all — into an Azure resource your governance team may never have approved.

The face of an agent nobody governs

Most agent-governance work watches data coming in. What can this agent read? Whose identity does it act on? Where does its activity show up? All of it inbound, or observed after the fact.

Telemetry runs the other way. It's data the agent sends out — to a separate store, for a different purpose: monitoring and diagnostics. An agent that can't over-reach by design, that authenticates cleanly on its own identity, that looks healthy on every dashboard, can still be emitting sensitive content sideways. The reading is governed. The emitting usually isn't.

What actually flows — and the toggle that opens the tap

On the Microsoft stack that store is Azure Application Insights, and in Copilot Studio's unified authoring the integration is on by default. On its own that logs operational signals — latency, events, which topics ran. Useful, not sensitive.

The sensitive part is gated behind one per-agent setting. Turn on Log sensitive activity properties and the agent starts logging the values of four properties on incoming and outgoing messages: userid, name, text, and speak. text is the message content itself — the user's prompt and the agent's response. Whatever a user typed, whatever the agent surfaced from a labelled document, lands in App Insights as plain text.

The setting is off by default. But it sits in plain sight in the agent's settings, labelled like a routine diagnostics aid, and a maker debugging a misbehaving agent is exactly the person who'll switch it on and forget.

Why this is a documented gap, not a bug

This isn't a vulnerability — it's behaviour Microsoft informs about. Its own "Remove sensitive data" table marks writing sensitive data to Application Insights as not supported, with the blunt note that the data isn't redacted, and a warning not to send sensitive values unless compliance has approved and compensating controls are in place.

Think of what that does to your boundary. Everything upstream — the label, the usage rights, the Purview policies — governs content inside Microsoft 365. App Insights is an Azure resource, usually owned by a platform or ops team, under its own access model and its own retention. The label travelled with the file; it does not travel into the telemetry. You've moved governed content into a store where your information-protection controls don't reach, and pointed at it with a connection string.

The control you're reaching for doesn't exist

Here's the part that catches governance teams out: there's no environment-level switch to exclude sensitive data from telemetry. You can't set it once for the tenant or the environment and move on. The only lever is that per-agent toggle — so the posture is maker-by-maker, agent-by-agent, by hand.

It's tempting to reach for sensitive-variable masking instead, and Copilot Studio does have it — values you flag as sensitive stay out of transcripts and logs. But per the current docs that setting applies to voice-enabled agents. For a standard text agent reading documents in your tenant, don't count on it. The general control you actually have is narrower than it looks: keep the logging toggle off, and treat the connection string as the real gate.

Checking and closing the gap

Concretely, in your own tenant:

Open an agent → Settings → Advanced → Application Insights. Read two things.

1. Is a connection string set? If not, nothing leaves to App Insights, and adding one to a sensitive-handling agent should be a reviewed decision.
2. Is Log sensitive activity properties on? (Some pages label it "Log sensitive properties" — same setting.) For any agent touching regulated content, it should be off unless compliance has signed off.

To confirm what's really landing, query the App Insights resource: a customEvents lookup shows whether text and name values are sitting there in clear. If they are, the toggle is on.

And the in-platform alternative: conversation logs in Dataverse do redact variables you've flagged as sensitive, where App Insights doesn't — so Dataverse is the better default for sensitive telemetry. Not a free pass, though. Writing sensitive data to Dataverse explicitly is also marked not supported, and the test panel deliberately shows unredacted values so makers can verify their rules.

Where "emits" sits

Read access decides what an agent can pull in. Identity decides what it is and what it may do. Observability shows what it touched. Telemetry is the fourth face — what it sends out — and it answers the same question every framework keeps circling: what data can this system touch, and on what basis? Outbound counts too.