# Datadog Cloud SIEM MCP for AI Agents MCP

> Datadog Cloud SIEM connects your security module to any AI agent, giving you full control over threat hunting and cloud auditing. Your agent can search critical security signals matching MITRE ATT&CK vectors, update alert statuses, and build new detection rules using raw log data—all through natural conversation.

## Overview
- **Category:** fort-knox
- **Price:** Free
- **Tags:** cloud-siem, threat-detection, security-signals, vulnerability-scanning, incident-response, mitre-att-ck

## Description

Managing cloud threats used to mean jumping between dashboards, running complex queries in a terminal, and manually tracking down logs from AWS or Kubernetes. This MCP changes that. You connect Datadog Cloud SIEM via Vinkius, giving your AI agent the deep access needed for true security operations. Instead of writing dense query language, you just talk to it. Your agent can hunt through raw log data over specific timeframes, find critical indicators—like an unauthorized S3 bucket access attempt—and even manage the detection rules themselves. You tell it, 'Find me all instances where a user attempts root escalation,' and it executes that logic instantly, providing structured results so you know exactly what's wrong. It’s like having a highly specialized security analyst always ready to take your verbal instructions.

## Tools

### create_detection_rule
Builds and activates a new Cloud SIEM Log Detection Rule by specifying fields, queries, and severity.

### security_system_ping
Tests the API connection to confirm that your agent can communicate with the Datadog Security Module.

### delete_detection_rule
Permanently removes user-created custom detection rules from the system (use with caution).

### get_raw_log_context
Extracts a deep set of raw log entries immediately after verifying an attacker's operational footprint.

### get_detection_rule
Retrieves the precise query logic for any specific detection rule currently running in your SIEM.

### list_security_filters
Lists all global exclusion policies, showing which low-value log vectors are intentionally blocked from evaluation.

### list_detection_rules
Retrieves a list of every configured proactive detection rule monitoring your cloud environment.

### search_raw_logs
Directly queries raw log data over defined time periods for deep threat hunting, useful for finding context during an active breach.

### search_signals
Searches high-level security signals (alerts) using query language to filter by severity or user ID matching MITRE ATT&CK vectors.

### triage_signal
Changes the status of a signal from open to archived, requiring you to provide an official reason for the change.

## Prompt Examples

**Prompt:** 
```
Can you list all my current detection rules and tell me what they monitor?
```

**Response:** 
```
**Cloud SIEM Detection Rules Overview**

| Rule Name | Status | Target Event | Monitors For |
| :--- | :--- | :--- | :--- |
| AWS_Trail_Deviations | Active | CloudTrail | Unauthorized read/write actions outside defined scope. |
| K8s_Root_Escalate | Active | Kubernetes | Attempts to escalate user permissions above service account level. |
| S3_Access_Filter | Disabled | S3 API | Blocked access attempts on non-public buckets (currently disabled). |

I found 3 rules configured. Which one do you want the full logic for?
```

**Prompt:** 
```
I think someone logged into the console from a weird IP. Can you check the raw logs around that time?
```

**Response:** 
```
**🔎 Raw Log Context (Past 15 Minutes)**

**Source IP:** `203.0.113.42`
**Timestamp:** `2026-06-12T10:15:22Z`

```json
{ "event": "auth_attempt", "user": "admin_svc", "status": "failure", "details": "Invalid credential set.", "source_ip": "203.0.113.42" }
{ "event": "api_call", "user": "unknown", "status": "success", "endpoint": "/v1/profile", "source_ip": "192.168.1.5" } 
```
<p>The logs show 4 failed attempts from that IP, followed by a successful call from an internal source.</p>
```

**Prompt:** 
```
That critical alert 'Brute Force Attempt' looks like it was cleared up last week. Can you mark it as false positive?
```

**Response:** 
```
**✅ Signal Triage Confirmation**

Signal `sig_12345` has been successfully updated.

* **Old State:** Open (Critical)
* **New State:** Archived
* **Reason Applied:** False Positive: Maintenance testing on network segment 7B. 

This change is logged in your compliance audit trail.
```

## Capabilities

### Triage Active Security Alerts
Change the status of an alert signal, marking it as archived or re-opening it, and adding official documentation for why you made the change.

### Audit Cloud Detection Rules
View the exact logic used by existing security rules, or retrieve raw information about global log exclusion policies to verify what data isn't being seen by your SIEM.

### Perform Deep Threat Hunts
Query massive amounts of raw Datadog logs directly, allowing you to look back at specific IP addresses or application traces related to a potential breach.

### Create Custom Detection Rules
Write and activate new Cloud SIEM detection rules by specifying the necessary log fields, query bindings, and desired severity levels.

## Use Cases

### A user suspects an administrator account was compromised.
The agent runs a query via `search_raw_logs` targeting the administrator's source IPs. It finds 15 suspicious events in the last hour, showing multiple failed login attempts and unusual access to administrative endpoints. The analyst then uses this raw context to build a new detection rule using `create_detection_rule` to catch similar patterns immediately.

### The team needs to confirm if an alert is a false positive.
A signal pops up in the queue, but it's known maintenance activity. The agent runs `triage_signal`, marking the signal as 'archived' and logging the reason: 'scheduled system testing,' ensuring the record is clean for compliance.

### Compliance requires auditing log exclusion policies.
The Compliance Officer asks the agent to run `list_security_filters`. The MCP returns a list of all global filters, allowing the officer to verify that low-value logging vectors aren't accidentally being blocked from critical review.

### A new AWS service was deployed and needs monitoring.
The Security Engineer asks the agent to run `list_detection_rules`. Seeing no coverage, they use the MCP to retrieve the specific logic for a similar existing rule using `get_detection_rule`, then modify it via `create_detection_rule` to cover the new service’s unique event types.

## Benefits

- **Instant Alert Status Updates:** You don't need to manually change alert statuses. Use `triage_signal` to move alerts from 'open' to 'archived' with a simple conversation, logging the reason automatically.
- **Deep Threat Context:** Stop guessing what happened. The `get_raw_log_context` tool lets you pull 100 raw log messages right after verifying an attacker footprint, providing immediate context for your report.
- **Proactive Rule Management:** Instead of digging through consoles, use the MCP to list all rules (`list_detection_rules`) or get a specific rule's logic via `get_detection_rule`, letting you know exactly what coverage you have.
- **Targeted Threat Hunting:** You can run focused queries using `search_raw_logs` over the last 15 minutes to find contextual VPC Flow Logs related to an active breach, far faster than a manual search.
- **Rule Deployment via Chat:** Need to monitor for a specific type of IAM usage? Use `create_detection_rule` to build and activate new Cloud SIEM rules using raw name/message fields right from your chat interface.

## How It Works

The bottom line is you use natural language conversation to interact with complex, structured security data and operational tools.

1. Subscribe to this MCP on Vinkius and provide your required Datadog API Key and APP Key.
2. Authorize your agent's access using your preferred AI client (like Cursor or Claude).
3. Start by asking your agent a security question, such as 'List all detection rules that monitor Kubernetes root escalations,' to begin managing cloud security.

## Frequently Asked Questions

**How can I use Datadog Cloud SIEM MCP to find suspicious activity in my cloud logs?**
You can ask your agent to search raw logs directly, specifying a timeframe or an IP address. The system pulls the contextual log data and presents it conversationally, allowing you to immediately spot indicators of compromise without running complex queries.

**What if I want to change an alert status from open to closed?**
You can use the MCP to manage your signals. You simply tell your agent which signal needs updating and provide a reason (like 'false_positive'). This action archives the signal while creating a permanent, auditable record of the decision.

**Can I write new security rules using this Datadog Cloud SIEM MCP?**
Yes. You can define and deploy completely new detection rules by giving your agent raw field names, query bindings, and severity levels. This lets you adapt your threat monitoring to brand new services or attack vectors.

**Does the Datadog Cloud SIEM MCP only search alerts, or can it look at logs too?**
It does both. It runs high-level searches on existing security signals (alerts) and also allows you to perform deep threat hunting by querying raw log data over specific time ranges for full context.

**What if I need to check which logs are being blocked from my SIEM?**
You can ask the MCP to list security filters. This tool retrieves global exclusion policies, allowing you to confirm exactly what data vectors are intentionally excluded and why they aren't reaching your evaluation engine.