> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths.md). # 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* {% hint style="info" %} During an incident, the first question is where the evidence lives. Build the surface map before you need it. {% endhint %} ## 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 * [Claude Code authentication](https://code.claude.com/docs/en/team) * [Claude Code security](https://code.claude.com/docs/en/security) * [Claude Code monitoring](https://code.claude.com/docs/en/monitoring-usage) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [Claude in Chrome permissions guide](https://support.claude.com/en/articles/12902446-claude-in-chrome-permissions-guide) * [Manage custom roles on Enterprise plans](https://support.claude.com/en/articles/13930452-manage-custom-roles-on-enterprise-plans) * [Claude Cowork architecture overview](https://support.claude.com/en/articles/14479288-claude-cowork-architecture-overview) * [Monitor Claude Cowork activity with OpenTelemetry](https://support.claude.com/en/articles/14477985-monitor-claude-cowork-activity-with-opentelemetry) * [Work across Microsoft 365 apps with Claude](https://support.claude.com/en/articles/13892150-work-across-microsoft-365-apps) * [Configure OpenTelemetry for Claude's Office agents](https://support.claude.com/en/articles/14447276-configure-a-custom-opentelemetry-collector-for-office-agents) * [Access the Compliance API](https://support.claude.com/en/articles/13015708-access-the-compliance-api) * [Access audit logs](https://support.claude.com/en/articles/9970975-access-audit-logs) * [Review what Claude Tag has done](https://claude.com/docs/claude-tag/admins/audit) * [How Claude Tag agent identity works](https://claude.com/docs/claude-tag/concepts/agent-identity) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## 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 * [Compliance APIs for Enterprise Customers](https://help.openai.com/en/articles/9261474-compliance-apis-for-enterprise-customers) * [Codex governance](https://developers.openai.com/codex/enterprise/governance) * [Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) * [ChatGPT release notes](https://help.openai.com/en/articles/6825453-chatgpt-release-notes) * [Introducing ChatGPT agent](https://openai.com/index/introducing-chatgpt-agent/) * [Production best practices](https://developers.openai.com/api/docs/guides/production-best-practices) ### Applicable Harmonic guides for OpenAI * [Securing ChatGPT Enterprise Guide](https://www.harmonic.security/resources/securing-chatgpt-enterprise-guide) * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## 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. | Surface | Primary evidence | Secondary evidence | Known gap | | ---------------------------------------------- | ------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | | 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 | Governance page | Relationship to this article | | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | 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 * [6. Observability, Audit & Evidence](/handbook/6.-observability-audit-and-evidence.md) * [6.1 The audit gap: what you can and can't see](/handbook/6.-observability-audit-and-evidence/6.1-the-audit-gap-what-you-can-and-cant-see.md) * [6.5 Routing AI telemetry to your SIEM](/handbook/6.-observability-audit-and-evidence/6.5-routing-ai-telemetry-to-your-siem.md) * [5.6 Incident response for AI system](/handbook/5.-threats-and-adversarial/5.6-incident-response-for-ai-system.md) * [4.6 Cross-app data flow and live artifacts](/handbook/4.-data-protection-and-residency/4.6-cross-app-data-flow-and-live-artifacts.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://handbook.harmonic.security/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.