[M365] Add Microsoft 365 Copilot activity log support

[jamiehynds]

Description

Microsoft 365 Copilot is the highest-penetration enterprise AI tool by seat count. Copilot interactions — prompts, responses, and the documents used for grounding — are auditable via the Office 365 Management Activity API and already flow through the Audit.General content type that the existing o365 integration collects.

The current ingest pipeline has no handling for Copilot RecordTypes. The RecordType lookup map doesn't recognise the Copilot-specific values, so Copilot events pass through with only generic field mappings applied — and the Copilot-specific payload fields that matter for security use cases are left unmapped. This is an enhancement to the existing o365 audit datastream, not a new datastream.

What this data does (and doesn't) give you

Unlike most AI-usage telemetry, Copilot audit events are unusually rich — the value is in mapping fields that are already present in the payload:

What CopilotInteraction events expose:

• The actual resources Copilot grounded on (AccessedResources) — document IDs, SiteUrl, resource Name/Type, and the SensitivityLabelId (Purview label) on each. This is the standout signal: you can see which sensitive documents an AI response was built from.
• Where the interaction happened — AppHost (Word, Teams, Outlook, BizChat, Excel, SharePoint, …) and AppIdentity (workloadName.appGroup.appName).
• Built-in safety signals — XPIADetected (cross-prompt-injection attempt flag on a resource) and JailbreakDetected (on a prompt message). These are genuine threat signals, not just governance metadata.
• Model transparency — ModelProviderName (and model name/version for non-M365 scenarios).
• Prompt/response message references (Messages: ID, isPrompt).

What it does not expose at the base tier:

• Full prompt/response content — only available with Purview Audit Premium (E5 or add-on). At the Standard tier you get the metadata above (including sensitivity labels) but not the text of prompts/responses.
• Human-readable sensitivity label names — SensitivityLabelId is a GUID; resolving it to a label name requires the tenant's Purview label taxonomy (a potential enrichment, not in the event).

The practical consequence: even at the Standard tier this is a strong visibility and correlation signal — Elastic can surface which sensitive documents Copilot touched, where, and whether injection/jailbreak was flagged. Content-level inspection is available too, gated only by license tier (same API, same pipeline).

Scope & data boundaries

• Enhancement, not a new datastream: this is RecordType handling + field mapping in the existing o365 audit pipeline. Copilot events already arrive via Audit.General.
• Prompt/response content is in-scope but gated by Purview Audit Premium — no separate collection path; the same events carry it when the tier is enabled.
• Correlation with other M365 signals (anomalous sign-in, bulk SharePoint access, privileged-account activity) works today against the existing o365 datastreams — no additional collection required.
• Sensitivity-label resolution (GUID → label name) is a possible downstream enrichment that needs to be explored during development.

Why this matters

• Sensitive-data visibility & correlation: AccessedResources[].SensitivityLabelId shows when Copilot grounded a response in highly sensitive material. Correlating that with the user, app surface, and surrounding M365 activity is the primary security signal in these events.
• Threat detection & correlation: Copilot activity joined with other M365 signals already in Elastic produces materially higher-fidelity detections than either source alone — plus the native XPIADetected / JailbreakDetected flags.
• AI governance & visibility: Track which users, departments, and app surfaces are using Copilot, and surface anomalous usage patterns.
• Compliance & audit: A durable, queryable record of AI tool usage to support GDPR, HIPAA, and internal acceptable-use requirements, with Premium retention up to 10 years.
• Admin oversight: Copilot admin operations (e.g. UpdateTenantSettings, CreatePlugin, DeletePlugin, EnablePromptBook) are configuration changes that should be monitored like any other.

What needs to be supported

RecordTypes / operations to handle: Recognise and route Copilot events correctly. Verify current values against the Office 365 Management Activity API schema — Microsoft has updated these in the past. Confirmed in the current Purview Copilot schema:

• CopilotInteraction — user interactions with Microsoft-developed Copilot apps (primary target)
• ConnectedAIAppInteraction — custom/registered Copilot Studio or 3rd-party apps deployed in the tenant
• AIAppInteraction — 3rd-party AI apps not deployed in the tenant (pay-as-you-go billing)
• TeamCopilotInteraction — Teams Facilitator (AI Notes / Live Notes / meeting moderation)
• Admin activity is logged via Operation names (UpdateTenantSettings, CreatePlugin, DeletePlugin, EnablePromptBook, …), not a dedicated RecordType. (Note: the values AICopilot and MicrosoftCopilotAdmin from earlier drafts don't appear in the current schema — confirm before relying on them.)

Key fields to map for CopilotInteraction events:

• AccessedResources[] — ID, Name, SiteUrl, Type, SensitivityLabelId, Action, and the security flags XPIADetected / PolicyDetails / Status (the most important DLP/visibility signal in these events)
• AppHost and AppIdentity — which Copilot surface/app generated the event
• Messages[] — ID, isPrompt, and JailbreakDetected
• ModelTransparencyDetails[] — ModelProviderName (and model name/version where present)
• AISystemPlugin — e.g. BingWebSearch indicates the response used the public web
• Admin configuration-change operations classified appropriately

Dashboards: Copilot usage by user and app, sensitivity-label exposure in grounding contexts, admin configuration-change timeline, usage volume over time.

Sample event

⚠️ Illustrative sample. Field names follow the current Purview Copilot audit schema; values are representative. A real captured event should be added during development from an M365 E5 tenant with Copilot enabled, and the numeric RecordType confirmed against the Management API schema.

{
  "CreationTime": "2026-06-01T14:23:11",
  "Id": "aaaa1111-bbbb-2222-cccc-3333dddd4444",
  "Operation": "CopilotInteraction",
  "OrganizationId": "11112222-3333-4444-5555-666677778888",
  "RecordType": 261,
  "UserKey": "i:0h.f|membership|analyst@contoso.com",
  "UserId": "analyst@contoso.com",
  "UserType": 0,
  "Version": 1,
  "Workload": "Copilot",
  "AppIdentity": "Copilot.MicrosoftCopilot.BizChat",
  "AppHost": "Word",
  "Contexts": [
    { "ID": "https://contoso.sharepoint.com/sites/Finance/Shared Documents/Q3-Forecast.docx", "Type": "docx" }
  ],
  "AccessedResources": [
    {
      "Action": "Read",
      "ID": "AAAAAEYE2GAACp1FlnN_CHXStUkH...AABwvq8gAAA2",
      "Name": "Q3-Forecast.docx",
      "Type": "docx",
      "SiteUrl": "https://contoso.sharepoint.com/sites/Finance/Shared Documents/Q3-Forecast.docx",
      "SensitivityLabelId": "f41ab342-8706-4188-bd11-ebb85995028c",
      "XPIADetected": false
    }
  ],
  "Messages": [
    { "ID": "1715186983849", "isPrompt": true, "JailbreakDetected": false },
    { "ID": "1715186984291", "isPrompt": false }
  ],
  "ModelTransparencyDetails": [
    { "ModelProviderName": "Microsoft" }
  ],
  "AISystemPlugin": [
    { "Name": "BingWebSearch", "ID": "BingWebSearch" }
  ]
}

Key fields

Field	Description
UserId	The user who interacted with Copilot
Operation / RecordType	CopilotInteraction — the AI interaction event
AppHost	Copilot surface (Word, Teams, Outlook, BizChat, Excel, SharePoint, …)
AppIdentity	Specific Copilot/AI app (workloadName.appGroup.appName)
AccessedResources[].SiteUrl / .Name / .Type	The grounding document(s) Copilot read
AccessedResources[].SensitivityLabelId	Purview sensitivity label (GUID) on the grounding doc — primary DLP signal
AccessedResources[].XPIADetected	Cross-prompt-injection attack flagged on a resource
Messages[].isPrompt / .JailbreakDetected	Prompt vs. response; jailbreak-attempt flag
ModelTransparencyDetails[].ModelProviderName	Model publisher
AISystemPlugin.ID	BingWebSearch indicates the response used the public web

Availability note: CopilotInteraction events are captured under Audit (Standard). Full prompt/response content and extended retention (up to 10 years) require Audit (Premium) — relevant to what fields are populated during testing.

Access requirements

• Purview Audit Standard (M365 E3): captures CopilotInteraction events with metadata including sensitivity labels on referenced documents, but not prompt/response content
• Purview Audit Premium (M365 E5 or add-on): adds full prompt and response content, extended retention up to 10 years

Development requires an M365 E5 tenant with Copilot enabled.

References

• Audit logs for Copilot and AI applications — Microsoft Purview
• Microsoft Purview data security for Copilot
• Office 365 Management Activity API — RecordType values
• Existing o365 ingest pipeline

[infra-vault-gh-plugin-prod]

Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)

[github-actions]

tl;dr: The fastest path is to add Copilot activity support to the existing o365.audit data stream (same Management Activity API flow), with one early decision gate to confirm Microsoft exposes Copilot activity in that API/content-type path.

Recommendation
Extend packages/o365 rather than creating a brand-new integration path first. The current O365 audit collector is already content-type driven and pipeline logic is generic for new workloads/record types. If Microsoft confirms Copilot activity is not available via Management Activity API, then pivot to a new Graph/Purview-backed data stream as a second path.

Findings

• Current O365 audit supported workloads are explicitly limited to:
  • Audit.AzureActiveDirectory, Audit.Exchange, Audit.SharePoint, Audit.General, DLP.All
  • Evidence: packages/o365/docs/README.md:14-19, packages/o365/data_stream/audit/manifest.yml:83-84,290-294
• Collector logic is generic by configured contentType:
  • Subscribes/fetches via .../activity/feed/subscriptions/start and .../activity/feed/subscriptions/content
  • Evidence: packages/o365/data_stream/audit/agent/stream/cel.yml.hbs:227-233 and surrounding logic.
• Ingest mapping is built to absorb new record types/workloads:
  • o365audit.Workload -> event.provider, o365audit.Operation -> event.action
  • large RecordType -> event.code map already exists.
  • Evidence: packages/o365/data_stream/audit/elasticsearch/ingest_pipeline/default.yml:222-229,273-380.
• There is already Copilot precedent in this repo (metrics package):
  • CopilotChat appears in O365 metrics service health sample and docs.
  • Evidence: packages/o365_metrics/data_stream/service_health/sample_event.json:68-70, packages/o365_metrics/changelog.yml:24-26 (PR #16992).
• I could not read issue #19409 body text in this workflow context, so this recommendation is based on the issue title and repository evidence.

Verification

I ran repository checks to verify current coverage:

$ grep -RIn "Copilot\|copilot" packages/o365
(no output)

$ grep -RIn "CopilotChat\|Microsoft 365 Copilot Chat" packages/o365_metrics | head
packages/o365_metrics/.../sample_event.json:68: "id": "CopilotChat"
packages/o365_metrics/.../sample_event.json:69: "name": "Microsoft 365 Copilot Chat"
...

$ grep -n "content_types\|Audit.AzureActiveDirectory\|Audit.Exchange\|Audit.SharePoint\|Audit.General\|DLP.All" packages/o365/data_stream/audit/manifest.yml
77:      - name: content_types
83:        default: "Audit.AzureActiveDirectory, Audit.Exchange, Audit.SharePoint, Audit.General, DLP.All"
290-294: explicit list of same content types

Detailed Action Plan

1. Decision gate (required first): confirm exact Microsoft source for “Copilot activity logs” (Management Activity API contentType/RecordType vs separate Graph/Purview endpoint).
2. If source is Management Activity API, update packages/o365/data_stream/audit/manifest.yml:
   • add Copilot content type to defaults/help text (content_types section around 77-84, legacy list at 285-294).
3. Update packages/o365/docs/README.md workload list (14-19) and setup docs to include new required permission/scope if applicable.
4. Extend ingest mapping in packages/o365/data_stream/audit/elasticsearch/ingest_pipeline/default.yml:
   • add new RecordType name mapping in the existing map (273-380),
   • add workload-specific ECS categorization rules if Copilot events need tailored event.category/type.
5. Add/extend fields in packages/o365/data_stream/audit/fields/fields.yml only for new stable structures that are not already covered by existing generic mappings.
6. Add pipeline test fixtures under packages/o365/data_stream/audit/_dev/test/pipeline/ with expected outputs, and update sample event.
7. Update packages/o365/changelog.yml with enhancement entry.
8. If step 1 determines Copilot logs are not in Management Activity API, implement a separate data stream (likely CEL against the confirmed API) and keep o365.audit unchanged.

Related Items

Type	Link / Path	Relevance
PR	#16992	Adds CopilotChat in o365_metrics service health; internal precedent for Copilot presence
File	packages/o365/data_stream/audit/manifest.yml:77-84,290-294	Current O365 audit content-type constraints
File	packages/o365/data_stream/audit/agent/stream/cel.yml.hbs:227-233	Generic subscription/fetch flow by contentType
File	packages/o365/data_stream/audit/elasticsearch/ingest_pipeline/default.yml:222-229,273-380	Existing generic workload/operation/record-type mapping
File	packages/o365/docs/README.md:14-19	User-facing supported workload list
File	packages/o365_metrics/data_stream/service_health/sample_event.json:68-70	Existing CopilotChat example in repository

Note

🔒 Integrity filter blocked 48 items

The following items were blocked because they don't meet the GitHub integrity level.

• #19409 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #365 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #18881 search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #18958 search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #11101 search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #19409 issue_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #18799 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #18509 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #19087 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #17996 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #19288 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #17992 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #17905 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #17929 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #18134 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #16992 search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• ... and 32 more items

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

---

What is this? | From workflow: Issue Triage

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.