Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Security engineers using Cloud SIEM spend their day-to-day investigating signals, tuning detection rules, managing suppressions, running historical jobs across interconnected workflows, and more. Agents are becoming a practical way to navigate that complexity, and we built a set of security tools for the Datadog MCP Server to support them. Cloud SIEM is only one part of a broader cloud security ecosystem, so the Security MCP toolset has to grow across many teams and products.

Apigee X is Google Cloud’s API management platform. Software and platform teams use it to secure, publish, and govern the APIs that internal services, partners, and external developers depend on. Apigee X sits in the request path for that traffic, so a latency spike or a rise in policy errors reaches API consumers before most other signals do. Watching proxy traffic, latency, and security posture usually means jumping between Apigee analytics and separate infrastructure tools.

AI agents can reason through tasks, call tools, and adapt their next steps based on intermediate results. That flexibility is useful for building agentic applications, but it also creates security risk at runtime: A prompt injection attempt can change the agent’s instructions, a malicious request can try to exfiltrate sensitive data, and an unsafe tool call can lead to an action that the application owner did not intend.

Static application security testing (SAST) tools are intentionally conservative. Traditional scanners identify code that appears exploitable and flag the snippet for review, even when protections elsewhere in the application prevent exploitation. Although that approach helps teams catch vulnerabilities, it also creates false positives that consume developer time, slow remediation efforts, and make future alerts easier to dismiss.

Memorandum M-26-14 from the Office of Management and Budget (OMB) marks a significant evolution in federal cybersecurity guidance, establishing a new risk-based framework for logging and network visibility across the United States federal government. The memo replaces the prescriptive requirements of Memorandum M-21-31 with an approach that emphasizes continuous monitoring, threat detection, investigation, and forensic readiness.

As state and local governments modernize critical technology systems, they must also meet growing demand for cybersecurity, reliability, operational efficiency, and fiscal accountability. From citizen services and public safety operations to transportation networks, education systems, and emerging AI initiatives, agencies are managing increasingly complex environments with limited resources.

To detect and investigate threats, security teams need to collect telemetry data from identity providers, cloud platforms, web application firewalls, and endpoints. But these diverse sources describe the same tactics, techniques, and procedures (TTPs) differently according to their own vendor-specific language. For example, a failed Windows logon appears as an event ID, while an Okta account lockout appears as an identity event.

Security teams are dealing with a fundamentally different operating environment than they were a few years ago. AI-assisted development is rapidly pushing more code and infrastructure into production, and according to Datadog’s 2026 State of DevSecOps report, 40% of running services have an exploitable vulnerability.

As Claude adoption expands across enterprises and workflows, security and compliance teams need to understand who is using Claude Enterprise, how it is accessed, and how it is administered and configured across the organization. The Claude Compliance API gives organizations access to valuable activity data that supports security monitoring, investigations, and governance initiatives.

Apache HTTP Server is one of the most popular web servers in use today for engineering teams, and its prevalence naturally makes it a frequent target for attackers. In May 2026, the Apache Software Foundation patched CVE-2026-23918, a high-severity double-free vulnerability in Apache 2.4.66’s mod_http2 module. For teams not using Apache’s MPM prefork, the vulnerability would enable an attacker to crash worker processes or achieve remote code execution (RCE) in some specific cases.