In this post I explore what detections you can already use in your SIEM by ingesting Claude Compliance API logs. Then we go even further, introducing a prefilter and LLM judge pipeline which lets you write detections for real AI threats that live inside message content. Last time I introduced claude-compliance-sdk and showed how to stream the Claude Enterprise activity feed, chats with full message content, project files and membership snapshots into your SIEM as newline-delimited JSON. The data is in. This post is about what to do with it. First, I would advise you read part 1 if you haven't already: Auditing Claude Enterprise: Shipping the Compliance API into Your SIEM In this post I show how to use Anthropic’s Compliance API to stream Claude Enterprise audit events into your SIEM, and introduce claude-compliance-sdk, a Python SDK I built to make interacting with the API easier. Why bother? You don’t need me to tell you that AI PaperMtn PaperMtn Why bother? By now you've hopefully got data ingested into your SIEM, and have it mapped to a data model, so rules fire on Claude just as they do on every other SaaS in the estate. That's good baseline coverage. This post is about what it misses, and how we have to reframe our detection workflows to capture the unique threats that AI platforms bring. The detections worth writing are the ones your existing data model cannot express, because they live in the content. They are specific to what Claude is, and they behave unlike anything else you are ingesting. A normal SaaS treats content as inert. It is the asset you are protecting, and your detections watch the perimeter around it: who logged in, who exported, who changed a role. An AI platform inverts three things, and none of them are in your existing data model. The content is the attack surface, not just the asset. A document jon.snow uploads can be an attack on the model, not just data sitting in a project. No other SaaS in your estate has a file that rewrites the system's behaviour the moment it is read. The adversary is often the sanctioned user. Most of the risk here is not a compromised account; it is a legitimate employee pasting a customer database into a prompt, or talking Claude into something policy forbids. It is a playground for insider threats, whether the intent is malicious or just careless. What you are looking for changes. The old detections match a pattern; detections for an AI platform have to weigh what is actually being said. Regex finds an API key. It does not find "the user is socially engineering Claude into summarising a colleague's private project". None of this is new as a threat taxonomy. The OWASP Top 10 for LLM Applications covers prompt injection, sensitive information disclosure and system prompt leakage, and MITRE ATLAS catalogues the adversary techniques. What has been missing is the link between those known risks and the feed you are now ingesting. The detections below are that link. What data model mapping catches for free Before we dig into the juicy stuff, let's make sure we've got the basics covered. The obvious detections are the ones you already run. A key gets created, an admin gets added, someone signs in from a country they have never signed in from before. Map the Claude activity feed to your SIEM's data model and those rules fire on Claude exactly as they fire on every other SaaS in the estate, because they are the same rules. The activity feed contains the identity and lifecycle events: sso_login_failed , admin_api_key_created , SSO connections activated or deactivated, users added to privileged groups, the Compliance API being accessed itself. These are worth alerting on. They are also exactly the shape your SIEM was built for: an actor, an action, a timestamp, an IP. Mapping them to your normalised auth and admin data model is an afternoon's work, and once mapped, your existing rules cover Claude with no new thinking required. If, for whatever reason, you can't map to a data model, the following events can easily be turned into standalone alerts for quick wins: A new Compliance Access Key, or a new scope added to an existing one. This is the key that can read every chat, file and user in the organisation, so its creation should never be routine. admin_api_key_created . Admin keys reach the activity feed themselves and carry broad privilege; they are created rarely enough that alerting on every one costs you almost nothing. sso_connection_deactivated and sso_connection_deleted . Turning off SSO is a classic bypass and persistence move. There are legitimate reasons to do it, but it should happen so infrequently that a knock on the application owner's door is justified. Domain capture or verification events. These change the tenant boundary itself, they are infrequent, and the blast radius is the whole organisation. A user granted an Owner or Primary Owner role. The most privileged grant Claude has, and one you want to hear about the moment it lands. There is one I w...