Audit Trails for Copilot Studio Agents: How to Meet Enterprise Security Requirements

Enterprise audit programs commonly require evidence of who did what, when, and under what authorization or approval controls. A Copilot Studio agent that cannot produce evidence appropriate to the organization’s control scope is likely to face objections in security or audit review before production. This article boils the job down to four checks: turn on the right Microsoft logs, tie them to ERP/CRM records with one correlation ID, enforce approval for high-risk actions, and keep evidence longer than the default retention window.

I’d sum it up like this: Microsoft Entra Agent IDs add agent-level identity and governance visibility, but they do not by themselves create a complete audit trail. Depending on the agent’s channels, data sources, and actions, use Purview Audit, a Dataverse transcript-retention strategy, Power Platform data policies, and relevant connected-system logs. That matters because Copilot Studio conversation transcripts are retained in Dataverse for 30 days by default, although admins can extend that retention period, while Purview Audit normally retains Audit (Standard) records for 180 days. In Audit (Premium), the default one-year policy applies to eligible Exchange, SharePoint, OneDrive, and Microsoft Entra records; other records remain at 180 days unless a custom policy applies.

Here’s the short version of what you need in place:

• Log the right events
  • CopilotInteraction
  • BotCreate
  • BotDelete
  • BotUpdateOperation-BotPublish
  • BotUpdateOperation-BotShare
  • BotUpdateOperation-BotAuthUpdate
  • AIPluginOperationCreate, AIPluginOperationUpdate, and AIPluginOperationDelete
  • Agent 365 tool telemetry such as AIExecuteTool, where Agent 365 is deployed and licensed
• Prove the full action chain
  • user identity in Entra ID
  • agent activity in Purview Audit
  • conversation detail in Dataverse
  • flow or integration activity in Power Automate and TeamCentral Central AI Hub
  • final record change in ERP/CRM
• Lock down access before execution
  • block anonymous Copilot Studio chat
  • use DLP connector groups
  • restrict environments and channels
  • require approval for actions like refunds, payment-term changes, or PO release
• Keep evidence long enough
  • export transcripts before default deletion
  • use Purview Data Lifecycle Management
  • place data on eDiscovery hold when legal review is needed
  • store exported logs with hashes in retention-locked storage

One of the primary takeaways here is that audit evidence can live across multiple systems, not in Copilot Studio alone. When each system receives and records the same correlation ID, I can connect a user interaction to an SAP update, Salesforce record change, or Dynamics 365 transaction.

The rest of the article walks through how to set that up in a way your security, IT, and compliance teams can review without guesswork.

Auditing for Copilot in Microsoft Copilot Studio using Microsoft Purview

sbb-itb-8c52a73

Define audit requirements and map them to log sources

Each audit requirement needs a direct link to the log field that proves it. If you can’t point to a field, you don’t have proof. That’s an audit gap. Once the field is clear, map the requirement to the system that holds that evidence.

Build an audit control matrix across Copilot, Microsoft 365, TeamCentral, and ERP or CRM logs

A control matrix gives you one place to connect each requirement to its log source and fields. In practice, it becomes the checklist your team uses to test audit readiness.

Microsoft Purview Audit retains logs 180 days on Standard. E5 raises the default to one year, but that one-year default applies to core workloads (Exchange, SharePoint, OneDrive, Entra ID). Copilot and Power Platform events still default to 180 days even on E5 unless you create a custom audit retention policy for them. Don’t rely on E5 alone to cover agent events long-term. If your retention requirement exceeds the configured Dataverse retention period, extend that period or export raw transcripts to Azure Data Lake Storage Gen2 before scheduled deletion. Microsoft Purview Data Lifecycle Management can apply retention to Copilot Studio prompts and responses through the Microsoft Copilot experiences location. That mechanism should be designed alongside, not as a substitute for, Dataverse transcript retention. eDiscovery preservation applies to content in scope of the hold and can prevent its permanent deletion.

Decide which agent events are in scope for security and IT review

Not every agent event deserves the same level of attention. Security and IT teams should focus on the events that change what the agent can do, who can use it, or which data it can reach.

Lifecycle events such as BotCreate, BotDelete, and BotUpdateOperation-BotPublish show when an agent was created, deleted, or published. Those events matter because they mark the points where risk can enter the system. If an agent appears in production without a clear change trail, that’s a problem.

BotUpdateOperation-BotAuthUpdate records changes to authentication settings and should be reviewed because those changes can affect how users authenticate. AIPluginOperationCreate records creation of an AI plugin operation; review it alongside connector configuration and authorization records to understand any change in downstream reach.

On the usage side, CopilotInteraction is the main Purview record of recorded user activity. It contains audit metadata, including CreationTime, UserKey when present, and a transcript thread ID; the full chat is stored separately and can be surfaced through DSPM for AI or retained in Dataverse where configured. That linkage is what turns a simple activity log into something your team can inspect during a review or incident.

For downstream transactions, the correlation ID passed through Power Automate into the ERP or CRM system is what makes incident reconstruction possible. Without it, you may know an agent ran a flow, but you can’t connect that flow execution to a specific record change.

Blocked actions and DLP matches should also stay in scope. They show that enforcement is working, or they expose policy violations that need follow-up. Those events form the baseline for monitoring and investigation.

Configure Microsoft and Copilot Studio logging for audit readiness

Enable Purview audit, verify event capture, and export logs

Microsoft Purview Audit is on by default for most Microsoft 365 organizations, but SMB licenses and unmanaged enterprise-trial tenants are exceptions. Verify the auditing status in your tenant before relying on it. In the Microsoft Purview portal, open Audit; if auditing is disabled, select the Start recording user and admin activity banner.

After audit is active, focus on two event types:

• Authoring events, such as agent creation, publishing, and sharing
• User interaction events, including individual CopilotInteraction records

Microsoft requires users to have assigned Microsoft 365 licenses for Copilot Studio to record audit events and save transcripts of their Microsoft 365 Copilot conversations. Confirm licensing and logging behavior for the channels your agent uses, because channel coverage and identity context vary.

Validate each required event in your own tenant before production. Copilot Studio notes that one action can generate multiple audit events and that some channels are excluded from logging, so define test cases and an evidence-collection window appropriate to your SIEM and review process. Treat any event you can’t reproduce as an audit gap to escalate, not a capability to assume.

For SIEM ingestion, pull Purview audit data through the Office 365 Management Activity API or a supported SIEM connector. Use a data collection rule only when your Azure Monitor ingestion design requires one. If reviewers need to see the actual prompt and response content, and not just metadata, they must also have the Content Explorer Content Viewer or Data Security AI Content Viewer role in Purview. Global Admin access by itself does not reveal that content.

These logs matter only if you can connect them to approvals and to changes made in downstream systems.

Apply DLP and environment controls

In PPAC, block the unauthenticated chat connector: "Chat without Microsoft Entra ID authentication in Copilot Studio". This prevents no-authentication deployments; also verify that each approved authentication method supplies an identity you can record and correlate.

DLP policies in PPAC sort connectors into Business, Non-business, or Blocked groups. Connectors in different groups cannot share data. Copilot Studio supports real-time data-policy enforcement. Review the data policies, connector classifications, and enforcement behavior configured in your own tenant rather than relying on a general rollout statement. Confirm your tenant’s current DLP enforcement state in the Power Platform admin center rather than assuming a specific rollout date, since Microsoft’s defaults have shifted over successive releases.

For environment governance, use Environment Routing in PPAC to direct makers into managed developer environments instead of the default environment. Pair it with security-group and privileged-access controls for shared and production environments; routed makers are administrators of their own developer environments.

You should also control where agents can be deployed. In practice, that means blocking channel connectors your organization has not approved, such as Microsoft Teams + Microsoft 365 Channel, Direct Line, Facebook, WhatsApp, or SharePoint.

Those settings put guardrails around agent use. The audit trail should then show whether people stayed inside those guardrails.

Key event reference table for reviewers

Use this shortlist during review and SIEM tuning.

Non-Microsoft channels such as custom websites or Direct Line require Copilot Studio capacity, supplied through prepaid Copilot Credits or PAYG billing.

Next, correlate these events with approvals, flows, and ERP or CRM transactions.

Build end-to-end traceability across agents, approvals, and connected systems

To trace an agent-driven action from start to finish, log each step with the same core fields: user or session ID, agent name and version, redacted prompt context, connector or API call, target record, policy decision, approval status, timestamps, and a single correlation ID.

Track user activity and agent actions across Microsoft and non-Microsoft systems

The goal is simple: connect the user interaction to the final business record.

Use one correlation ID from the bot through every connector and into each downstream system. Without that ID, investigators can’t tie a record change back to the interaction that started it. Generate the ID in the bot, then pass it through connectors as a header or parameter.

As of March 18, 2026, Copilot Studio automatically creates Microsoft Entra agent identities for new agents when the preview integration is enabled for the environment. Existing agents created before that date, or before the environment was enabled, continue to use app registrations. At present, moving an existing agent to Agent ID requires recreating the agent; there is no in-place migration.

To see the full chain, join the main log sources by correlation ID and user identity:

Before you depend on Dataverse as your audit source, confirm transcript retention settings.

Enforce role-based access and log approvals for high-risk actions

Once the events are linked, enforce access before the agent takes action.

Do not rely on prompts for authorization. Check access in Power Automate or a policy engine before the agent runs a business action.

For higher-risk actions like releasing a purchase order, posting to the general ledger, changing customer payment terms, or issuing a refund, set up a policy engine that returns ALLOW, DENY, or REQUIRE_APPROVAL at runtime. If REQUIRE_APPROVAL is returned, a Power Automate approval flow or other approval process should complete before execution continues. Log the requester ID, approver ID, execution timestamp, and the policy check ID that triggered the approval step.

Use TeamCentral Central AI Hub for integration-level audit logs

ERP, CRM, and eCommerce logs often live in separate places. Microsoft’s native tooling audits the Copilot Studio and Microsoft 365 layers well, but it doesn’t natively stitch those records to non-Microsoft ERP/CRM transactions, that correlation is left to you. You can solve it with a custom correlation-ID pipeline, an iPaaS layer, or a dedicated integration hub. TeamCentral describes Central AI Hub as an integration layer that can apply role-based controls and record integration telemetry. Validate in your implementation which policy decisions, identifiers, connectors, and request fields are retained. The requirement is end-to-end correlation; the hub is one way to meet it.

Here’s how one high-risk business action can produce a traceable record across four log layers:

Where TeamCentral is deployed, its integration logs can reduce manual correlation work. Reviewers should still be able to reach the underlying Copilot Studio, integration, and source-system records for the action.

Use the same correlation ID across monitoring, retention, and incident review.

These linked logs become the input for monitoring and incident response.

Set up monitoring, retention, and incident response after deployment

Once agents go live, the audit work moves from setup to day-to-day oversight. The linked logs from the previous section become the evidence base for alerts, reviews, and investigations.

Set alerts, review access regularly, and investigate with correlation IDs

Start by centralizing log sources. Use the Office 365 Management Activity API or a supported SIEM connector to retrieve Purview audit and Microsoft 365 activity, and use the relevant connectors, APIs, or exports for TeamCentral Hub and ERP/CRM records before centralizing them in a SIEM such as Microsoft Sentinel, Splunk, QRadar, or Elastic.

Set alerts for:

• unusual spikes in interaction volume
• sensitive-data exposure flagged by DSPM for AI
• repeated access failures
• XPIADetected values in AccessedResources indicate that Microsoft detected a cross-prompt injection attack in a resource Copilot accessed. Confirm that this property is present and populated in the audit data you ingest before building alerting around it, since AI-threat fields are still evolving.

Also monitor BotUpdateOperation-BotAuthUpdate and BotComponentUpdate authoring events in Purview. These events can point to configuration drift between what security reviewed and what is now running.

When a high-risk alert fires, preserve the correlation-ID evidence bundle, assign an owner, and open the incident record before remediation starts. That step matters. If teams jump straight into fixing the issue, they can lose the exact trail needed to explain what happened and who was affected.

Alerts should move straight into incident triage, with the correlation ID carrying the evidence set through the full investigation. Pre-build KQL queries for the sources your organization actually ingests into Sentinel or Log Analytics. Use those queries with links or exports from Dataverse, the integration platform, and downstream ERP/CRM systems where the evidence is stored elsewhere.

Schedule regular reviews of agent permissions, connector policies, DLP rules, and integration-level access in TeamCentral Hub. Review Entra Agent ID scope changes after each republish so scope assignments stay in the review cycle.

Monitoring falls apart if evidence disappears too soon. Assess retention against the specific legal, contractual, and internal requirements that apply to your organization. HIPAA, SOX, and insurance requirements do not create one universal retention period for every agent log or transcript. Export Dataverse transcripts to Azure Data Lake Storage Gen2 through Azure Synapse Link for long-term storage, and configure Data Lifecycle Management policies in Purview using the "Microsoft Copilot Experiences" location.

For covered Copilot prompts and responses stored in hidden Exchange Online mailbox folders, a Purview eDiscovery hold can preserve content that would otherwise become eligible for deletion. Plan separately for Dataverse transcript retention and exported integration evidence.

To protect chain of custody, compute cryptographic hashes for each exported log batch and store them in write-once, retention-locked storage. Think of that as sealing the box before it goes into the archive. If someone later questions the record, you have a way to show it was not altered.

Conclusion: The controls that make Copilot Studio agents deployable in enterprise environments

Deploying Copilot Studio agents in an enterprise is a governance commitment. Use these four controls as the post-deployment security gate before production approval.

Define audit scope first, validate that Microsoft logging captures the required events, enforce RBAC and approvals before actions execute, add integration-level traceability where non-Microsoft systems are involved, and configure monitoring and retention to support documented legal, contractual, and internal requirements. Each layer closes a gap the others cannot cover on its own.

FAQs

Do Entra Agent IDs alone satisfy audit requirements?

No. Microsoft Entra Agent IDs provide identity-level attribution and visibility, which means they tell you which agent is acting.

What they do not do is decide whether that agent should carry out a given action under business rules, compliance limits, or approval thresholds. That decision needs a separate control point.

To meet enterprise audit requirements, add an authorization layer before tool execution that enforces RBAC (role-based access control) and ABAC (attribute-based access control). This ensures the system checks both who the agent is and whether the requested action is allowed in that specific context.

How do I trace one Copilot action across Microsoft and ERP/CRM systems?

Use a correlation ID to tie the events together. Generate the ID in your agent, then pass it through headers or parameters in custom connectors when calling ERP or CRM APIs.

Capture that same ID in external system logs and line it up with Microsoft audit metadata or custom telemetry to reconstruct the full interaction. Also enable Dataverse auditing for the affected tables so you can track record-level changes.

What should I retain beyond default Copilot transcript retention?

Keep more than transcripts. If you ingest the relevant telemetry into Log Analytics, export or retain it on a defined schedule so you preserve agent actions, user invocations, and accessed-data evidence where available. That gives you a fuller audit trail when you need to trace what happened across a workflow, not just what was said.

Protect log integrity by computing cryptographic hashes for each batch and storing both the logs and hash manifests in immutable, write-once storage. This setup helps you show that records were not changed after export.

You should also apply policy-aligned retention rules and enable legal holds where needed. In practice, that means keeping records for the right length of time based on internal policy, regulatory needs, or active matters that require preservation.

Track correlation IDs across agents, connectors, and downstream systems so teams can follow a single activity path from start to finish. And any export or purge request should be logged and formally approved, with a clear record of who requested it, who approved it, and when it happened.