Your organization has approved AI platforms for development, data science, and productivity. Procurement signed off. Legal reviewed the terms. Employees are using them. The tools are sanctioned.
What isn’t sanctioned is invisibility. The administrative layer of every AI platform in your environment — OpenAI, Amazon Bedrock, Google Gemini, Cursor, Databricks, Glean and others — generates security-relevant events that your SIEM has never seen. This post covers what those AI audit logs contain, why they don’t reach your SIEM by default, and how VirtualMetric DataStream closes that gap.
What AI platform audit logs contain
AI platform audit logs record administrative activity: credential events, identity and access changes, configuration modifications, and session context. Every major enterprise AI platform maintains this log, and the event types follow a consistent pattern across the category:
- Credential events
API key creation and deletion, service account provisioning, scope assignments. A new API key with broad write access, created outside business hours, by an account that doesn’t typically perform administrative actions, warrants investigation regardless of which platform it came from.
- Identity and access events
User additions and removals, invitations sent and accepted, role assignments, login successes and failures. Login failure sequences against an AI platform organization account follow the same detection logic as any other brute-force indicator.
- Configuration changes
Organization settings, project lifecycle (created, archived, deleted), rate limit modifications. Rate limit changes in particular are often overlooked — they can indicate an attacker probing capacity or preparing for high-volume data extraction.
- Usage and session context
Source IP addresses, session identifiers, actor types (human session vs. API key vs. service account), timestamps. This context is what turns a bare event into an actionable signal.
Underneath the AI-specific context, these are standard identity and access signals: credential creation, permission changes, login failures. Security teams already have detection rules for them — the only missing component is data. As AI platforms become part of critical development and data pipelines, the stakes of leaving that data uncollected grow with them.
Why AI audit logs don’t reach your SIEM
AI audit logs don’t reach your SIEM by default because each platform exposes them in its own format, through its own API, with no native SIEM integration. OpenAI uses event types like api_key.created and user.added. Amazon’s services route through CloudTrail. Google Gemini and Vertex AI route through Google Cloud Audit Logs. Anthropic uses workspace and workspace member event structures.
Getting one platform’s logs into your SIEM and mapping them to a usable schema is an engineering project. Doing it for a dozen platforms — and maintaining those mappings as vendor APIs evolve — is ongoing work most security teams don’t have capacity for.
Even piping raw logs from multiple AI platforms into your SIEM isn’t enough on its own. They land in custom tables with incompatible field names, invisible to the analytics rules built against your normalized schema. You’ve added data volume without adding detection coverage.
How DataStream brings AI audit logs into your SIEM
VirtualMetric DataStream includes purpose-built content packs for enterprise AI platforms, each handling collection and parsing for a specific platform’s audit log. The current set covers three categories of the enterprise AI stack:
Model providers
- OpenAI platform – admin and audit log API covering the full administrative event surface
- Anthropic Claude – platform compliance and activity events covering API key lifecycle and workspace and workspace member changes
- Anthropic Claude Code – OpenTelemetry logs covering session activity, tool use, and per-request usage telemetry (model, tokens, cost, latency)
- Google Gemini – API audit events from both Vertex AI and AI Studio, delivered through Google Cloud Audit Logs.
Cloud AI services
- Amazon Bedrock – model invocation and admin audit logs,
- Amazon SageMaker – audit events via CloudTrail,
- Azure OpenAI – service diagnostic logs including request/response metadata (model, lengths, duration) and audit event types.
Developer and data platform tools
- Cursor – AI IDE audit logs covering authentication and user management,
- Databricks – multi-schema audit logs for authentication and administrative events,
- Glean – Work AI usage and insights streams,
- Arize AI – ML/LLM observability platform audit events,
- Koi – endpoint audit logs for extensions, MCP servers, plugins, and agents.
Each pack parses the platform’s audit events and normalizes them to a standard schema — ASIM or CommonSecurityLog by default. From there, the output is schema-flexible: attach a postprocessor pack and the same normalized events convert to OCSF, UDM, ECS, or another target schema. That means the packs aren’t tied to a single SIEM. The same OpenAI or Bedrock pack feeds Microsoft Sentinel through ASIM, Google SecOps through UDM, Elastic Security through ECS, or an OCSF-based platform like Amazon Security Lake through the OCSF postprocessor — without rebuilding the collection and parsing logic for each destination.
Every pack also ships with an optional optimization pipeline that can filter high-volume read-only events and compact placeholder values, keeping ingestion costs in check. For more on why normalization matters for detection and AI-assisted security operations, see Why Data Normalization Is the Foundation of AI Security.
What detection looks like with the data in place
With AI platform audit logs normalized and flowing into your SIEM, detection scenarios that were previously invisible become routine.
A service account is added to an AWS Bedrock environment at 11pm. An API key is created with broad model invocation permissions. The source IP resolves to an ASN not previously associated with your AWS account. These three events arrive in your SIEM as normalized records — Create events, off-hours, unusual source, privileged scope. An existing analytics rule fires. An incident is created.
The analyst working the queue sees a credential creation incident. The normalized fields tell the story without requiring knowledge of Bedrock’s specific event schema. Standard triage process applies — the same way it would for a credential event from any other source already feeding the SIEM.
Deployment
The content packs are available inside DataStream’s Content Hub. Each pack is applied as a preprocessing template on the collection path — events are parsed and normalized before they reach your SIEM, keeping the processing load off the SIEM and storage tier. To target a specific schema, attach the matching postprocessor pack; the collection and parsing configuration stays the same regardless of where the data lands.
Deployment follows the same pattern for every pack: connect the platform’s audit API, select the pack, attach a postprocessor if you need a schema other than the default, and configure routing to your SIEM. The DataStream documentation covers the setup for each platform in detail. For most platforms, ingestion is running within 30 minutes of configuration.
DataStream is available as a SaaS deployment and listed in the Microsoft Security Store. VirtualMetric is a member of the Microsoft Intelligent Security Association (MISA).
Getting started
If your SIEM is missing AI platform visibility, the gap is closeable without custom development. The audit logs already exist, the platforms are generating them. DataStream handles the collection, normalization, and routing into your SIEM, without custom development, whether you run Sentinel, Splunk, Elastic, Google SecOps, or an OCSF-based platform.
Contact the VirtualMetric team to discuss your environment and which platforms are the priority, or try DataStream for free.
See VirtualMetric DataStream in action
Start your free trial to experience safer, smarter data routing with full visibility and control.