Why your SIEM needs AI audit logs

Most security teams can tell you a lot about a file that left the network. They can tell you very little about a paragraph of customer data that a staff member pasted into an AI chat window.

Look at what a well-configured web proxy captures. The ISM’s baseline for web proxy logging (ISM-0261) is the web address, date and time, user, amount of data uploaded and downloaded, and internal and external IP addresses. That’s enough to show someone used an AI service and sent a few kilobytes. It isn’t enough to say whether those kilobytes were a shopping list or a client’s medical history.

That is the AI visibility gap, and closing it means getting events from the AI platform itself.

Why the usual controls miss it

Network DLP can’t read TLS traffic without inspection, and many organisations exempt popular SaaS domains from inspection for performance or privacy reasons. Even with inspection, pattern-matching a chat payload is unreliable: prompts are free text, often streamed, sometimes inside JSON or WebSocket frames.

CASB coverage depends on the vendor having an API connector for the specific AI service. Consumer AI accounts usually have none.

Endpoint tools see a browser process and a destination. They don’t see what was typed.

None of these are bad controls. They were built for channels where the content sits in a file or a message body. A chat prompt is neither.

What an AI platform should emit

The useful place to log is the point where the prompt is processed. A platform worth deploying should produce structured events along these lines:

Session and identity

• sign-in, sign-out and MFA events, with user, role and source IP
• admin actions: role changes, policy changes, user suspension, data exports

Prompts and responses

• prompt submitted: time, user, model, classification, size, and either the content or a hash
• policy outcome: allowed, warned, redacted or blocked, and which rule fired
• response returned: model, tokens and latency

For agents and tools

• every tool call, external request and output, which the ISM now requires to be centrally logged for agentic AI (ISM-2159)

Each event should carry the fields ISM-0585 sets as the minimum: date and time, user or process, event description and the equipment involved. Ask for JSON with a documented schema, timestamps in UTC, and a stable event ID so you can de-duplicate after a replay.

One design decision is worth making deliberately: whether full prompt text goes to the SIEM. Full text makes investigations faster. It also copies sensitive information into a system that more people can search. A common compromise is metadata and a hash in the SIEM, with full text kept in the AI platform under tighter access and retrieved when an investigation needs it.

Getting events into the SIEM

Most SIEMs will take AI audit events through a path you already run:

• Splunk: post JSON to the HTTP Event Collector and give the events their own sourcetype.
• Elastic or OpenSearch: ship through Logstash or an HTTP input, with an index template for the AI event schema.
• Microsoft Sentinel: send to a custom table through the Azure Monitor Logs Ingestion API.
• Anything else: syslog over TLS or OpenTelemetry (OTLP) are the most portable options.

Check two things before you sign. Can the platform retry and replay events if your collector is down? And can you see delivery failures, so a silent gap in AI logging isn’t mistaken for a quiet week?

Detections worth building first

With the events flowing, you can write detections that weren’t possible before. A few that tend to pay off early:

1. Sensitive identifiers in prompts. Alert when a prompt is flagged for TFNs, Medicare numbers, card numbers or credentials, or when a user is redacted or blocked repeatedly in a short window.
2. Policy evasion. A blocked prompt followed within minutes by a near-identical prompt from the same user usually means someone is trying to get around the rule.
3. Volume against baseline. A sharp rise in a user’s prompt volume or token use against their own 30-day pattern can point to a compromised account or scripted extraction. ISM-2114 now asks for baselines of expected AI behaviour to be monitored for deviations.
4. New account, heavy use. A recently created account that immediately starts high-volume querying deserves a look.
5. Classification outside hours. Sensitive-classified prompts at 2am from a user who never works then. Correlate with leave and access records before raising it.

Tune for the first few weeks. Early alerts will mostly reflect normal use you haven’t characterised yet, and ISM-1228 expects the resulting events to be analysed in a timely manner, so don’t build more alerts than the team can triage.

Start with visibility

A sensible first phase is small: choose an AI platform that emits structured events, route them into the SIEM you already have, build a dashboard of active users, prompt volume, classification and blocked prompts, and turn on two or three detections. Everything else in AI governance, from usage policy to classification rules, is easier to argue for once you can see what’s happening.

K9 AI logs every prompt with user, time, IP, model and classification, and forwards events over syslog (RFC 5425, TLS), OpenTelemetry (OTLP/HTTP) or vendor HTTPS, with retry, replay and delivery monitoring.

Frequently asked questions

Should AI audit logs contain the full prompt text?

It depends on your risk appetite. Full text makes investigations far easier but creates a new store of sensitive data; many teams log metadata and a hash in the SIEM and keep full text in the AI platform under tighter access.

How long should AI audit logs be kept?

For government systems, ISM-1988 asks for event logs to be kept searchable for at least 12 months, and ISM-1989 points to the National Archives' AFDA Express for longer minimums. Outside government, use your existing security log retention standard.