The ask from security teams is usually straightforward: get logs from the AI tools employees use, send them to Splunk or Elastic, and alert on anything that looks like a policy violation. When you actually dig into what enterprise AI tiers provide, the answer is almost uniformly "sort of." Every major tool now ships some form of audit logging. The problem is not availability. The problem is that these logs were designed for admin visibility and billing accountability, not for security operations workflows. The schema, the fields, and the retention windows all reflect that origin.
What Security Teams Actually Need
Before evaluating what vendors give you, it helps to be precise about what a security workflow requires. A SIEM ingestion pipeline for AI tool events needs several things to be useful.
First, a stable, parseable timestamp in UTC ISO 8601 format, not a relative "3 minutes ago" string. Second, a user identity field that resolves against your IdP, typically email or UPN, not a tool-internal UUID that has no mapping in your directory. Third, a session or conversation identifier to group related prompt-response turns. Fourth, some representation of the prompt content itself, or at minimum a content classification tag. Fifth, the destination tool, model, and endpoint. Sixth, a response status indicating whether the call succeeded, whether it was flagged by the vendor's own filters, and what action was taken.
Alert logic on top of this requires per-user volume baselines, category tagging on the content side, and some mechanism to correlate across multiple tools, since most companies in the 50-500 employee range have three to six AI tools in active use simultaneously. None of those cross-tool requirements are met by any single vendor's native logs.
What Enterprise Tiers Actually Deliver
ChatGPT Enterprise exports CSV or JSON via an admin dashboard. The fields include user email, conversation ID, model used, message count, and timestamps. The prompt body itself is not included by default, because OpenAI treats conversation content as user data under their privacy architecture. Retention is configurable within enterprise plan terms. If you want to alert on what was actually typed into the prompt, you cannot do it from these logs alone.
Microsoft 365 Copilot logs flow through the Unified Audit Log in Microsoft Purview. The schema includes user UPN, which maps well to your IdP, the application context (Word, Teams, Excel), and a timestamp. Copilot does include some content field data, but it is often truncated and the field name and structure have changed across audit log schema versions since the product launched. Parsing this reliably requires ongoing maintenance as Microsoft iterates the schema.
Claude for Work's admin console logs user activity at the conversation level. As of late 2025, export options are limited to the admin web interface and a nascent API. Prompt body content is not included in the standard export.
Gemini Workspace audit logs flow through Google Workspace Admin SDK or into Chronicle if you are a Google SecOps customer. The field consistency is relatively good and maps to standard SIEM schemas better than most competitors, but prompt content has the same privacy-default omission.
The pattern is consistent across all of them: session-level metadata yes, content-level detail no.
The Schema Problem No One Talks About
Even accepting the metadata-only limitation, the schemas are not interoperable. Each tool has its own field names, its own identifier schemes, and its own timestamp formats. Writing a detection rule that joins ChatGPT events and Copilot events by user requires a normalization layer that maps one tool's user_email to another's upn, one tool's session_id to another's conversation_id.
For a two or three person security team at a 150-person company, this normalization is not a quick afternoon project. It is several weeks of parser maintenance that needs to stay current as vendors update their schemas. Schema changes happen silently. There is no changelog entry visible from the admin panel. Detection rules break without warning.
A realistic SIEM pipeline covering five AI tools requires five separate log source connectors, a normalization ruleset mapping each tool's fields to a common schema, and some form of test coverage that catches schema drift before it silences your alerts. That is an infrastructure investment most mid-size security teams cannot sustain alongside their other priorities.
What No AI Vendor Exports Today
Three categories of information that security teams consistently need but cannot currently get from native AI tool logs:
Content classification. Security teams do not want to read every prompt. They want a tag: "this prompt contained a pattern matching API key format" or "this session included text classified as customer PII under your organization's policy." None of the major AI vendors apply your organization's data classification policy to prompt content and surface that in the audit trail. They flag their own content policy violations, but that is a different policy from yours.
Cross-tool session correlation. If an employee starts in ChatGPT, continues in Claude, and finishes in Copilot, you get three separate audit trails with no shared identifier. You cannot reconstruct the sequence of what information moved across tools in a single work session, even if you have full access to all three logs.
Behavioral baseline deviation. AI tool logs do not tell you "this user's prompt volume today is three standard deviations above their 30-day average" or "this user has never pasted this category of content before." Behavioral context requires a separate layer that maintains per-user baselines. No AI vendor builds this for you.
We are not saying native AI tool logs are useless. Session-level metadata is better than nothing, and it can anchor a volume-based detection approach. But it is a starting point for monitoring, not a complete security visibility solution.
SIEM Integration in Practice
Consider a security engineer at a 200-person fintech company trying to build AI tool monitoring into their existing Elastic SIEM. They have three AI tools in active employee use: ChatGPT Enterprise, GitHub Copilot, and Claude for Work. The process looks something like this.
ChatGPT admin logs get exported via the API on a polling schedule. A Logstash pipeline normalizes the fields to a common schema. Copilot audit events arrive via Microsoft 365 Management Activity API, which requires OAuth2 authentication and periodic token refresh. A separate pipeline handles these. Claude admin exports are manual CSV pulls until the API stabilizes. Each pipeline needs its own error handling for rate limits, schema changes, and authentication failures.
After a month, the security engineer has reasonable session-level visibility. They can see which employees are using which tools and roughly how much. They cannot see what is being asked, and they have no content classification. A data exfiltration incident that passes through these tools leaves metadata in the SIEM but no content signal.
The Supplemental Event Layer
The gap that native logs leave is the reason Unbound generates its own event stream. When Unbound intercepts a prompt inline before it reaches the AI tool, it creates an event record that includes: user identity from your IdP, the destination AI tool and endpoint, content category classifications (secrets, PII categories, source code fragments, internal document language), the action taken (allow, block, or redact), and a UTC timestamp consistent with your SIEM's reference clock.
That event stream forwards to Splunk or Elastic via webhook, or exports as CSV for teams that prefer batch ingestion. The goal is not to replace what the AI vendor logs; it is to generate the fields that AI vendor logs structurally cannot include, because the vendor has no visibility into your organization's classification policy and, by design, does not store prompt content in your audit stream.
When a violation fires, the Unbound event record says: user X, at time T, attempted to send a prompt containing what Unbound's classifier identifies as credential-format strings, to ChatGPT, and the action taken was block. The ChatGPT admin log for that same moment says: user X had a conversation at time T. Both records are accurate. Only one is directly actionable in a SOC workflow.
The practical approach for teams that want real AI tool visibility: pull native admin logs for session-level volume and user activity baselines, and supplement with a prompt-inspection layer for content-level alerting. The two log sources are complementary. Treating the native logs as sufficient leaves a significant blind spot in your monitoring coverage, and that blind spot is exactly where the more serious exfiltration scenarios will land.