6.6 Evidence by surface and investigation paths
Which log answers which question, per AI surface — the reference table you reach for during an AI security incident.
Last reviewed: August 18, 2026
What security teams need to know about evidence by surface and investigation paths
Each AI surface leaves a different evidence trail. Chat may have workspace audit events. API usage may have organization logs. Coding agents may have local files, terminal history, and provider traces. Browser and desktop actions may require endpoint or browser evidence.
An investigation path should say which logs answer which question and which gaps require user interview, endpoint capture, or vendor support.
Common evidence by surface and investigation paths security failures
Investigators start with the wrong log source.
A surface is approved before its evidence path is tested.
Local agent files are overwritten before preservation.
Connector logs and AI logs are not correlated.
API-key activity lacks user attribution.
Evidence by surface and investigation paths security controls checklist
Create a table of surface, source, owner, retention, key fields, and gaps.
Test each evidence path during pilot.
Preserve local files, transcripts, approvals, and tool logs where relevant.
Correlate AI events with SaaS, endpoint, proxy, and identity logs.
Record evidence gaps as rollout blockers for regulated workflows.
Test the evidence path
For each surface, script a small set of actions: sign in, read approved data, attempt a denied read, grant a connector, call a tool, approve and deny an action, create an output, cancel work, revoke access, and delete the resulting data where supported.
Record the expected provider, identity, endpoint, runtime, network, repository, and target-system events. Compare expected and actual records, timestamps, identities, correlation IDs, content visibility, and retention. Treat missing or unattributable evidence as a documented gap with a compensating control, not as “not applicable.”
Repeat the reconciliation after major releases, schema changes, collector changes, licensing changes, new authentication paths, and incidents. Preserve the test cases so audit coverage can be revalidated rather than rediscovered.
Anthropic
Overview
Anthropic investigation paths start with the surface. For supported Claude chat activity in an Enterprise workspace, start with the Compliance API. Do not use that path for Cowork. Anthropic says Cowork is outside audit logs, the Compliance API, and data exports. Team and Enterprise investigators should start with Cowork OpenTelemetry, then correlate remote session records or local desktop evidence with target-system logs. Endpoint tools cannot inspect the remote Cowork sandbox. Claude's Microsoft 365 add-ins also need their separate Office-agent OpenTelemetry feed plus Microsoft 365 audit logs.
For Claude Code, split by execution mode: cloud execution has audit logging in isolated VMs, while local runs depend on OpenTelemetry, local transcripts, and endpoint evidence. For Managed Agents, pull the session event history and webhook-delivered events. Claude in Chrome actions are recorded mainly in the target systems the extension touched, so correlate SaaS audit trails with the admin site controls, role grants, browser evidence, and endpoint logs.
For Claude Tag channel work, start with the Slack thread and Claude Tag Audit view, then pivot to the service account in each connected system. Add the optional Agent Proxy network export if enabled, but account for its Git and MCP exclusions. For direct messages, follow the user's Claude account and personal connectors rather than the channel's agent identity.
Anthropic documentation
Applicable Harmonic guides for Anthropic
OpenAI
Overview
OpenAI investigation paths split by surface, execution location, and authentication. The Enterprise Compliance API covers user messages and responses across Chat, Work, and Codex, but it does not record Work files, actions, or tool calls. Work on web and mobile runs in the cloud. Work and Codex in ChatGPT Desktop (Work / Codex) can act on local files and applications, so preserve Codex telemetry, local thread and filesystem evidence, endpoint records, plugin and app logs, and target-system audit events.
Codex evidence also depends on authentication. ChatGPT-authenticated activity appears in the Codex Compliance API and governance exports. API-key-authenticated runs are excluded and follow API organization settings, so their trail starts with API usage records and endpoint evidence. ChatGPT agent mode runs on a hosted virtual computer, making conversation and confirmation records useful but insufficient without connected-app and downstream SaaS logs. ChatGPT Atlas has no Compliance API feed and is scheduled to retire on August 9, 2026; preserve required endpoint and browser evidence during migration.
OpenAI documentation
Applicable Harmonic guides for OpenAI
Reference table: evidence by surface
Primary evidence is where an investigation should start; secondary evidence corroborates or fills detail; the known gap is what neither will show. Verify rows against current vendor documentation before relying on them.
ChatGPT Chat (Enterprise)
Enterprise Compliance API (messages and responses; broader conversation, GPT, user, and memory records)
Workspace settings, IdP logs, connected-app logs
Canvas events not yet supported
ChatGPT Work, web or mobile
Enterprise Compliance API messages and responses
Connected-app and target-system logs
Files, actions, and tool calls are not tracked by Compliance API or Compliance Logs Platform
ChatGPT Work or Codex, desktop
Compliance records plus Codex governance or OpenTelemetry where available
Local thread and filesystem evidence, endpoint, plugin, app, and target-system logs
Local actions span several evidence systems; cloud Work threads do not appear in desktop Work at launch
Codex, ChatGPT-authenticated
Codex Compliance API and governance exports
Local logs, repo and worktree history, endpoint evidence
Covers ChatGPT-authenticated activity only
Codex, API-key-authenticated
API organization usage records
Endpoint evidence: terminal history, local Codex logs, repo history
Not in Compliance API exports; attribution stops at the key without an owner registry
ChatGPT Atlas, until August 9, 2026
Endpoint and browser evidence
Downstream SaaS logs, proxy logs
No Compliance API feed; surface is retiring
ChatGPT agent mode
Conversation record and confirmation prompts
Downstream SaaS and connector logs
Hosted virtual computer leaves little local evidence
Claude chat, web, desktop, mobile (Enterprise)
Enterprise workspace evidence, including Compliance API
Connector and downstream SaaS logs
Verify event coverage for the workflow
Claude Cowork, remote
Cowork OpenTelemetry and session context
Target-system, identity, and network logs
Not in audit logs, Compliance API, or data exports; endpoint tools cannot inspect the remote sandbox
Claude Cowork, local desktop
Cowork OpenTelemetry
Local files, endpoint, browser, connector, and target-system logs
Desktop must be online for local access; evidence is distributed
Claude Office agents
Office-agent OpenTelemetry
Microsoft 365 audit logs and file history
Not in Anthropic audit logs, Compliance API, or data exports
Claude Code, local
OpenTelemetry monitoring, local transcripts
Repo history, endpoint logs
Telemetry must be configured before the incident
Claude Code, cloud execution
Cloud execution audit logs
Scoped credential logs, repo history
Different evidence path from local runs; map both
Claude Managed Agents
Session event streams, webhooks, event history
Downstream SaaS logs
Beta; sessions persist server-side and are not ZDR-eligible
Claude in Chrome
Target-system (SaaS) audit logs
Admin allowlist/blocklist configuration, role grants, browser evidence
Actions recorded mainly where they land, not in a central export
Worked example: API-key Codex CLI
An employee pastes a customer record into a Codex CLI session authenticated with an API key. Nothing appears in the Codex Compliance API, because it covers ChatGPT-authenticated use only. The pivot: identify which API organization and project owns the key, pull usage records from the API Platform usage page to time-box the activity, then collect endpoint evidence from the device — terminal history, local Codex logs, and worktree state. The prerequisite this exposes is attribution: if keys are not mapped to human owners before the incident, step one fails.
Frequently asked questions about evidence by surface and investigation paths
Where is AI investigation evidence stored?
It depends on the surface. Evidence can sit in compliance APIs, OpenTelemetry, cloud execution logs, session histories, endpoint files, connector and SaaS logs, browser evidence, and Microsoft 365 audit records. Cowork and Claude's Office agents are clear examples where telemetry must replace the expected compliance export.
What is a surface-to-evidence map?
It is a table that maps each AI surface to the records an investigation would pull, in order. A row typically reads like: Codex with an API key — primary evidence is API organization usage records, secondary is terminal history and local logs on the endpoint, and the known gap is that nothing appears in Compliance API exports. Build one row per approved surface and test each during pilot.
Why is API-key activity hard to investigate?
A key identifies a project or service account, not a person, so the trail stops unless key ownership was registered in advance. It also skips the strongest logging path: API-key-authenticated Codex use is excluded from Compliance API exports. Owner registration and usage tracking are the compensating controls.
What evidence should be preserved first?
Preserve the volatile and overwritable material first: local transcripts, worktrees, terminal history, and approval records on the endpoint, since agents routinely overwrite their own state. Then capture prompts, outputs, tool calls, connector logs, and credential events from platform sources, which are subject to retention windows rather than immediate loss.
How should gaps be handled?
Document each gap, decide whether the workflow can proceed, and add compensating controls where needed. Endpoint logging and SaaS audit trails cover some missing vendor detail, but they cannot inspect Anthropic's remote Cowork sandbox or reconstruct an unlogged OpenAI Work tool call. For regulated data, treat a missing required evidence path as a rollout blocker.
Applicable regulations and frameworks
G.1 Map your controls to NIST AI RMF and CSF 2.0
This article supplies implementation evidence for the NIST AI RMF and matching NIST CSF 2.0 outcomes.
G.2 EU AI Act obligations for deployers
Conditional: for an in-scope high-risk system, this supports investigation evidence and proof of deployer controls.
G.3 DORA and AI resilience in financial services
Conditional: for a DORA-regulated workflow, this supports monitoring, investigation, audit evidence, and incident reporting.
G.4 Colorado AI Act and the US state patchwork
Conditional: for covered Colorado ADMT, this supports version, decision, complaint, and retention evidence.
G.5 SANS Critical AI Security Guidelines mapping
This article implements relevant SANS Monitoring and GRC guidance.
G.6 Write an AI Acceptable Use Policy that holds up
This article supplies a technical or process control used to enforce the acceptable-use policy.
G.7 Ownership and RACI for AI security
This control depends on the ownership and evidence responsibilities defined in the RACI.
G.8 ISO/IEC 42001 AI management system
This article supports ISO/IEC 42001 AIMS preparation through audit-ready evidence paths and traceability.
G.9 HIPAA controls for AI systems handling PHI
Conditional: for a workflow handling ePHI, this supports HIPAA audit controls, activity review, and investigation evidence.
G.2, G.3, G.4, and G.9 are conditional mappings. They apply only when the deployment is within the legal or regulatory scope described on the linked governance page.
Related handbook guidance
Was this helpful?