Enterprise Claude governance with your SIEM and BlinkOps

The adoption curve is ahead of the governance curve

Claude (Anthropic’s AI assistant) is showing up everywhere in the enterprise. Developers are using Claude Code (Anthropic’s agentic coding tool) to write, refactor, and deploy software from their terminals. Analysts are using claude.ai to summarize reports, draft communications, and process documents. Engineering teams are calling the Claude API to power internal tools and customer-facing features. Security teams are building detection content with it. Legal is reviewing contracts. Product is writing specs.

This is not a single-use-case tool anymore. It is an organizational platform. And like every organizational platform before it, from email to SaaS to cloud infrastructure, it needs governance. Who is using it. What are they doing with it. What data is going in. What is coming out. What happens when something goes wrong.

Anthropic recognized this. The Claude Enterprise plan includes centralized audit logging, a Compliance API for programmatic access to activity data, managed settings for fleet-wide policy enforcement, and OpenTelemetry exports for Claude Code telemetry. The building blocks for governance are there.

But building blocks are not a governance program. Audit logs sitting in a dashboard are not detection. Detection without enrichment is not triage. Triage without response is not resolution. You need the full chain.

This post lays out a reference architecture for enterprise Anthropic governance using your SIEM (Security Information and Event Management) as the detection layer and BlinkOps as the enrichment, correlation, triage, and response engine. It covers all Claude surfaces, not just Claude Code.

One note before we start. This architecture assumes a working telemetry pipeline already feeds your SIEM. Getting Claude Code and Cowork (Anthropic’s agentic knowledge-work desktop app) OTel events collected, parsed, reduced, and conditioned before storage is a real engineering task on its own. The Abstract Security team published a detailed walkthrough of that pipeline layer, including data reduction and inline DLP/PII handling: "Claude Code and Cowork in the SOC: Visibility, Detection, and the Wild West of AI Agent Logging." This post picks up where that one ends. Their post gets the data right. This post acts on it.

‍What Claude Enterprise gives you

The Enterprise plan provides three centralized telemetry capabilities. Understanding what each one captures, and what it does not, is essential for designing detection and response.

Audit logs

Enterprise audit logs capture roughly 30 event types across the entire Claude organization. These include:

• SSO login and logout events
• User invitations and deletions
• Project creation, deletion, and visibility changes
• Conversation creation and deletion
• File uploads and downloads
• Settings and permission modifications

Audit logs cover activity across all Claude surfaces: claude.ai web, Claude Code, and API usage. Organization Owners and Primary Owners can export up to 180 days of logs as CSV. The export includes timestamps, IP addresses, user agents, device IDs, and event types.

Important: audit log exports include unique identifiers for chats and projects, not their titles or content. Chat inputs and outputs are exportable separately by Primary Owners through data exports.
‍

The Compliance API

The Compliance API gives programmatic, real-time access to the same activity data. Instead of manual CSV exports, your systems can pull events on a schedule or near-real-time.

The API tracks two categories:

Admin and system activities. Actions that modify access or configuration: adding or removing workspace members, creating or revoking API keys, updating account settings, modifying permissions. These are the events that tell you who has access and how that access is changing.

Resource activities. User-driven actions on data: file creation, downloads, deletions, skill modifications. These are the events that tell you what data is moving through Claude.

The Compliance API also supports selective deletion, enabling enforcement of data retention policies (for example, deleting prompt data older than 30 days for GDPR compliance).

Organizations running both Claude Platform and Claude API can pull logs from a single consolidated feed, which simplifies compliance reporting across different deployment models.

The gap to know about: the Compliance API does not log inference activities by default. It tells you that a conversation was created at 2:15 PM by a specific user, but not what they asked the model or what it responded. For conversation content monitoring, Primary Owners use the separate data export capability. For Claude Code tool-level execution detail, that is where OpenTelemetry comes in.

OpenTelemetry for Claude Code and Cowork

Claude Code and Cowork support OpenTelemetry (OTel) exports that ship usage metrics, cost data, and tool execution events to your telemetry backend. This is the telemetry path that gives you tool-level visibility into what Claude Code agents are actually doing.

A useful detail confirmed by Abstract's testing: Cowork uses Claude Code's OTel event schema under the hood via the Claude Code SDK. The two services emit the same event types, which means one parsing and detection pipeline covers both. Cowork is not a separate logging problem. It is the same schema with different defaults.

OTel captures tool execution events including tool name, parameters (bash commands, file paths), execution duration, and cost.

OTel is deployed centrally via managed-settings.json pushed through your MDM or endpoint management tool:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.your-company.com:4317",
    "OTEL_EXPORTER_OTLP_HEADERS": "Authorization=Bearer your-token",
    "OTEL_LOG_TOOL_DETAILS": "1"
  }
}

Users cannot override managed settings. One configuration, pushed once, covers the entire fleet.

Three configuration points matter, and getting them wrong breaks detections downstream.

OTEL_LOG_TOOL_DETAILS=1 is the setting that unlocks file paths, full shell commands, and MCP server and tool details in tool execution events. This is not optional for the architecture in this post. Every Claude Code detection rule below (sudo attempts, writes to secrets files, outbound network calls, MCP connections) depends on tool parameter content being present. With tool details off, those events still fire but the parameter fields are empty, and the rules have nothing to match. Turn it on in managed settings, as shown above.

OTEL_LOG_USER_PROMPTS=1 controls whether prompt content is collected. Off by default, only prompt length is recorded. Prompt content is useful for abuse detection and DLP, but it carries PII and privacy exposure. If you enable it, redact sensitive fields in the pipeline before they reach storage. Abstract's post covers pattern-based redaction for exactly this case.

Tool execution events include bash commands and file paths that may contain secrets and credentials inline. Configure your telemetry backend to redact sensitive fields before they land in your SIEM.

One gap to plan around. As of Claude Code version 2.1.126, OTel events do not carry a hostname or IP address. The closest thing to a host identifier is the installation-level user.id, which is not a host. This matters because the architecture below correlates Claude Code events with EDR telemetry, and EDR events key on host. Without a host field, that join does not work out of the box. The fix is to enrich Claude Code events with host data at collection time using the OTEL_RESOURCE_ATTRIBUTES environment variable, populated with a dynamically resolved hostname per endpoint. Abstract's post documents tested mechanisms for macOS and proposed approaches for Linux and Windows. Treat host enrichment as part of pipeline setup, not an afterthought.

What you get from the three streams combined

Together, these three streams give your security team visibility into who is using Claude, how they are using it, what administrative changes are happening, and (for Claude Code and Cowork) what tools and commands are executing. All centralized. No per-machine log collection scripts.

A note on event correlation within OTel. To reconstruct a user's activity, the reliable fields are session.id and event_sequence. A session groups every prompt, API call, and tool use from the start of an interaction until exit. Combining session.id with the event_sequence of each event reconstructs the full session for an investigation. The prompt.id field is documented to chain individual tool calls back to the originating prompt, but in practice this is less reliable. Abstract's testing on version 2.1.126 found that prompt.id does not consistently appear in user_prompt events themselves. Build session reconstruction on session.id and event_sequence, and treat prompt.id as a helpful but not guaranteed link.

Local enforcement for Claude Code: hooks

Centralized telemetry tells you what happened. It does not stop anything. For Claude Code specifically, the hooks framework provides real-time local enforcement.

PreToolUse hooks fire before Claude Code executes a tool. They inspect the command and block it if it violates policy. Exit code 2 kills the action before it runs. This is sub-second, deterministic, and cannot be bypassed by the model, even with --dangerously-skip-permissions.

This is specifically relevant for Claude Code because it is the agentic surface that executes shell commands, writes files, and makes network calls on developer machines. The other Claude surfaces (web chat, API) do not execute tools on the user's machine.

Hooks deploy through the same managed-settings.json that configures OTel. One push via MDM covers enforcement and telemetry together.

Example PreToolUse enforcement policy:

#!/usr/bin/env python3
import json, sys, re

BLOCKED_PATTERNS = [
    (r"\bsudo\b", "sudo commands are blocked by policy"),
    (r"\bcurl\b", "outbound curl requires approval"),
    (r"\bwget\b", "outbound wget requires approval"),
    (r"\bchmod\s+777\b", "chmod 777 is blocked by policy"),
    (r"\brm\s+-rf\s+/", "recursive delete from root is blocked"),
]

input_data = json.load(sys.stdin)
command = input_data.get("tool_input", {}).get("command", "")

for pattern, message in BLOCKED_PATTERNS:
    if re.search(pattern, command, re.IGNORECASE):
        print(message, file=sys.stderr)
        sys.exit(2)

sys.exit(0)

Hooks are one enforcement mechanism within the governance architecture. They handle the Claude Code agentic execution risk. The broader detection, triage, and response for all Claude surfaces runs through the SIEM and BlinkOps.

SIEM: the detection layer

Your SIEM ingests the centralized telemetry streams: Compliance API events, OTel data from Claude Code and Cowork, and (optionally) data exports for conversation content auditing. Its role is focused: store, index, and fire detection rules.

A reminder on what feeds this layer. The SIEM is downstream of a pipeline that has already collected, parsed, reduced, and host-enriched the OTel events. Dropping low-value event types like tool_decision, at_mention, and internal_error before storage cuts volume and also cuts the number of events your detection rules have to evaluate. Abstract's post covers which event types are safe to drop and which to aggregate instead. The detection rules below assume that conditioning has already happened.

Detection rules across all Claude surfaces

The detection rules split into three categories based on the telemetry source.

Admin and access detections (from Compliance API):

These rules are intentionally simple. They fire on specific field values. A curl command is medium severity because the SIEM does not know if the target domain is malicious. An unusual login is medium because the SIEM does not know if the user is traveling or compromised. The SIEM surfaces candidates for investigation. It does not make final severity calls.

A note on the MCP startup rule, because it maps to a real attack. TrustFall is a coding-agent flaw reported by Adversa AI in which an agent CLI executes a project-defined MCP server the moment a user accepts the folder trust prompt. The payload can sit inline in a .mcp.json server definition. There is no separate user action, no command the user typed. Accepting the trust prompt on a cloned repository is enough to get unsandboxed code execution, which can lead to credential theft, data exfiltration, or persistence. In OTel logs, the inline-payload variant of this often surfaces as a failed mcp_server_connection event with a project-level scope and a very low event_sequence, because the server initialization runs among the first events at launch. That is the signal behind the "failed project-scope MCP connection at startup" rule above.

This rule on its own is prone to false positives, since project-level MCP connection issues happen legitimately during troubleshooting. Treat it as a low-severity building block, not a final alert. The high-fidelity version of this detection comes from correlation, which is the SOAR's job, covered below.

When a rule fires, it triggers a Blink workflow.

What the SIEM gives you beyond detection

Long-term retention and retroactive hunt. An incident investigation starts three weeks after a compromise. You need to know what every user was doing with Claude during the attack window. Conversations created, files uploaded, API keys generated, commands executed. With the SIEM, those events are indexed and searchable going back months.

The SIEM also serves as a queryable data store for Blink enrichment workflows. When Blink needs to check "has this user triggered similar alerts in the last 30 days?" or "what was this user's normal Claude usage pattern?", it queries the SIEM. The historical data is already there.

BlinkOps: the enrichment, correlation, triage, and response engine

When a SIEM detection rule fires, it triggers a Blink workflow. This is where the architecture shifts from detection to decision.

The SIEM alert arrives with the event data: user identity, event type, relevant metadata, and the detection rule that fired. Blink turns it into a fully contextualized security event by actively querying across multiple systems, building the correlation, and making a severity determination that no single system could make alone.

Enrichment workflows (deterministic, multi-system)

This is core Agentic SOC functionality. A Blink workflow takes the alert and fans out to every system with relevant context. Each step is a standard Blink integration action. No AI needed for data gathering.

Identity and access context. Blink queries Okta or Entra ID: what is this user's role, team, and access level? Are they an admin or a regular user? When were they last provisioned? Have there been recent access changes? A bulk file download from a senior data analyst is different than the same pattern from a newly onboarded intern.

Device posture. For Claude Code events, Blink queries the EDR (CrowdStrike, SentinelOne, Defender): is the device managed? What is the risk score? Are there active detections? A Claude Code sudo attempt on a machine with an existing EDR alert is a fundamentally different situation.

This is where the host correlation gap matters in practice. EDR events key on hostname. Claude Code OTel events do not carry one by default. If you have not enriched OTel events with host data at collection time, Blink has no reliable key to join a Claude Code event to the right EDR record. Solve this in the pipeline before it reaches Blink. The enrichment workflow assumes the host field is present.

Threat intelligence. For events involving outbound network calls (from Claude Code OTel), Blink queries threat intel feeds: is the target domain known malicious? Recently registered? Associated with threat actors?

Network correlation. Blink queries the NDR or proxy logs: did outbound traffic to a flagged domain actually occur? What was the response? How much data was transferred?

Authentication anomaly check. Blink queries the identity provider for suspicious authentication events: failed MFA in the past 24 hours? Login from an unusual location? Session anomalies?

Historical baseline. Blink queries the SIEM for historical Claude events for this user: how many alerts have they triggered in the last 30 days? Is this pattern new or recurring? What is their normal usage volume?

DLP context. For file upload events, Blink can query your DLP platform: was the uploaded file classified as sensitive or restricted? Does it contain PII, source code, or regulated data?

Each query returns structured data. Blink assembles the results into a single enriched event object. This is active correlation across identity, EDR, NDR, threat intel, DLP, and historical telemetry, orchestrated by the SOAR, not dependent on pre-written SIEM correlation rules.

This is the key architectural distinction. SIEM correlation is static. Someone writes a rule that matches events from different log sources for known patterns. Blink's enrichment workflows are dynamic. They query every relevant system for every alert, every time. Novel combinations that no one wrote a SIEM rule for still get investigated because the enrichment workflow goes and gets the context regardless.

The TrustFall detection is the clearest example. The low-severity SIEM building block fires on a failed project-scope MCP connection. On its own, that is noisy. Blink correlates it: it pulls EDR process events from the same host in a tight time window and checks for a shell or script interpreter spawned by Claude Code, encoded command execution, or credential store access. The failed MCP connection plus suspicious child process activity on the same host inside one minute is a high-fidelity signal. One log source could not produce that. Correlation across two could. This is also why the host enrichment step is not optional.

Triage agent (scoped, bounded reasoning)

The micro-agent receives the fully enriched event. It does not go hunting for context. Everything it needs is already in the JSON object the enrichment workflow assembled.

The agent uses the Blink Anthropic integration ("Ask Anthropic" or "Generate Model Response" action) with a tight prompt. The enriched event is the input. The output is a severity classification and a recommended response tier.

For a Compliance API event (unusual login):

{
  "event_type": "login",
  "user": "analyst@company.com",
  "role": "data_analyst",
  "team": "finance",
  "ip": "203.0.113.47",
  "ip_geo": "Singapore",
  "device_id": "new_device",
  "user_home_location": "New York",
  "idp_recent_mfa_failures": 2,
  "historical_login_locations": ["New York", "Boston"],
  "active_edr_alerts": 0,
  "siem_detection_rule": "unusual_login_pattern"
}

‍

For a Claude Code OTel event (outbound curl):

{
  "event_type": "tool_execution",
  "user": "developer@company.com",
  "role": "senior_engineer",
  "team": "platform",
  "tool_name": "Bash",
  "command": "curl -X POST https://api-staging.external-vendor.com/webhook",
  "host_name": "dev-laptop-0142",
  "device_risk_score": "low",
  "edr_active_alerts": 0,
  "domain_threat_intel": "clean, registered 2019",
  "ndr_outbound_flag": false,
  "idp_anomaly": false,
  "historical_alert_count_30d": 1,
  "siem_detection_rule": "outbound_network_call_claude_code"
}

The agent classifies based on complete data. No assumptions. No gaps. The enrichment workflow did the legwork. The agent does the thinking.

Response workflows (deterministic, tiered)

Based on the triage agent's classification, Blink executes the appropriate response:

Low severity (informational). Slack notification to the security channel. Includes the user, event type, classification reasoning, and a link to the SIEM alert. No action taken.

Medium severity (policy violation or suspicious activity). For Claude Code: revoke the developer's session or enforce a policy settings push. For web/API: disable the user's Claude seat or revoke API keys via the Anthropic admin controls. Notify the user and their manager. Create a case in Blink Case Management.

High severity (active threat indicator). For Claude Code: trigger EDR containment to isolate the endpoint. For all surfaces: disable the user's organizational access via Okta/Entra ID, revoke all API keys, and escalate to incident response. Create a priority case with the full enrichment chain.

Critical (compromised account). Full account lockdown via identity provider. Revoke all Claude access, API keys, and active sessions. Trigger the incident response playbook. Preserve all audit logs and data exports for forensics.

All severities. Every event that reaches Blink creates a case with the complete context chain: original telemetry event, SIEM detection rule, cross-system correlation results, triage classification, and response actions taken. Full audit trail from detection to resolution.

Response actions by Claude surface

The posture enforcement loop

Detection and response handles events after they happen. Posture enforcement makes sure the governance infrastructure is intact before anything happens.

A scheduled Blink agent runs daily or triggers on onboarding events from your identity provider. It verifies:

• Is the Compliance API enabled and pulling events into the SIEM?
• Is the OTel collector receiving telemetry from all Claude Code and Cowork users?
• Is OTEL_LOG_TOOL_DETAILS=1 set, so tool-level detections have parameter data to match on?
• Is host enrichment in place, so Claude Code events can be correlated with EDR?
• Is managed-settings.json deployed to all developer machines with current enforcement hooks and OTel configuration?
• Are there Claude users who were provisioned but are not covered by SSO, managed settings, or audit logging?
• Are data retention policies set and enforced per organizational requirements?
• Are any API keys older than the rotation policy threshold?

If drift is detected, the agent alerts the security team, triggers remediation (push updated settings, rotate keys, disable non-compliant users), or escalates for manual review.

A note on what you are actually defending against

Most of the detections in this post are framed around user misuse: an employee uploading sensitive data, generating API keys off-hours, downloading files in bulk. That framing is correct for the majority of cases, and it is where governance programs usually start.

But TrustFall is a different shape of problem. It is not the user misusing the agent. It is an attacker using the agent against the user. The developer who cloned the repository did nothing wrong beyond accepting a trust prompt, which infosec has learned people will always accept. The agent itself became the execution vector.

As agentic surfaces spread, expect more of this: prompt injection delivered through files the agent reads, malicious MCP servers, poisoned skills and plugins. Detection content built only around user misuse will miss it. Worth keeping both threat models in view when you design rules.

Why this architecture works

Each component handles what it is built for.

Claude Enterprise provides centralized telemetry across all surfaces. Audit logs, Compliance API, data exports, and OpenTelemetry. Identity-tagged, filterable, exportable. Configured at the organization level, not per machine.

Hooks provide local enforcement for the one Claude surface that executes tools on developer machines: Claude Code. Real-time, deterministic, tamper-resistant. Deployed via the same managed settings as OTel.

The pipeline collects, parses, reduces, and host-enriches the telemetry before it lands. This is the layer Abstract's post covers in depth, and it is what makes the SIEM layer affordable and the correlation layer possible.

The SIEM ingests, stores, and detects. Pattern matching on telemetry fields. Long-term retention for hunt and compliance. Queryable data store for Blink enrichment. It surfaces candidates.

Blink enriches, correlates, triages, and responds. Deterministic workflows query every relevant system to build complete context. A scoped micro-agent classifies. Deterministic workflows execute response. The correlation is dynamic and built on demand, not pre-defined in static rules.

The SIEM is the data lake. The SOAR is the brain. That separation is the whole point.

What you need to build

• Claude Enterprise setup with Compliance API enabled, SSO configured, data retention policies set, and managed settings deployed via MDM
• OpenTelemetry configuration in managed settings pointing to your OTel collector, with OTEL_LOG_TOOL_DETAILS=1 set so tool-level detections have parameter data to match on
• Host enrichment for Claude Code OTel events via OTEL_RESOURCE_ATTRIBUTES, so events can be correlated with EDR by hostname
• A telemetry pipeline that parses, reduces, and conditions OTel events before storage, including DLP flagging and PII redaction if prompt logging is enabled
• PreToolUse enforcement hooks in managed settings with your organization's Claude Code deny list
• SIEM ingestion pipelines for Compliance API events (polled via API on schedule), OTel data (received via collector), and optionally data exports
• SIEM detection rules across three categories: admin/access events, Claude Code and Cowork tool execution, and usage anomalies
• Blink enrichment workflows triggered by SIEM alerts, with fan-out queries to identity provider, EDR, NDR, threat intelligence, DLP, and SIEM historical data
• Blink correlation workflows that turn low-severity building-block rules (like the failed MCP startup rule) into high-fidelity alerts by joining across log sources on host and time
• Blink triage micro-agent with a scoped prompt that classifies fully enriched events into severity tiers
• Blink response workflows per severity tier and per Claude surface (seat management, key revocation, EDR containment, account lockdown, case creation)
• Blink posture enforcement agent on daily schedule to verify Compliance API health, OTel coverage, tool-detail logging, host enrichment, managed settings deployment, key rotation, and user provisioning alignment

The bigger picture

Anthropic built the enterprise governance foundation: centralized audit logging, programmatic API access, managed policy settings, and OpenTelemetry. These cover visibility and, for Claude Code, local enforcement.

What they do not cover is what happens between collecting an event and resolving it. Two layers sit in that gap. The first is the pipeline: collecting, parsing, reducing, and conditioning the telemetry so it is affordable to store and clean enough to detect on. Abstract Security covers that layer in detail in their Claude Code and Cowork monitoring post, and it is the right place to start if your pipeline is not built yet.

The second layer is what this post covered: enrichment, cross-system correlation, AI-powered triage, and automated response. That is where the Agentic SOC lives.

Your SIEM gives you the data pipeline, storage, and detection layer. BlinkOps gives you the active enrichment that reaches into EDR, NDR, identity, threat intel, and DLP. It gives you the dynamic correlation that static SIEM rules cannot match. It gives you classification on complete, enriched data. And it gives you response workflows that execute in seconds across every Claude surface.

The SIEM is the data lake. The SOAR is the brain. And governing enterprise AI adoption at scale is exactly the kind of problem the Agentic SOC was built to solve.

Further reading: Abstract Security's ASTRO team, "Claude Code and Cowork in the SOC: Visibility, Detection, and the Wild West of AI Agent Logging."