Datadog Release Notes

Teams supporting user-facing applications rely on session replays to understand user friction. But resolving an issue or improving the user experience takes more than watching a replay. Engineers, product managers, and designers first need to find the right sessions to investigate, then quickly learn what happened at the key moments. Once they’ve investigated a replay, they need to share what they found across product, design, support, and engineering so that the right teams can act. Too often, though, these conversations happen apart from the replay itself, making it hard to trace the discussion back to the specific moment that was flagged.

Datadog Session Replay, available in both Datadog Real User Monitoring (RUM) and Product Analytics, now brings the entire investigation into one place. You can find the right session from your RUM and Product Analytics data, analyze it with AI summaries that highlight the moments worth watching, and collaborate with teammates using timestamped comments pinned directly to the replay. Everyone works from the same source of truth, so investigations move faster, and findings reach the right people with full context attached.

In this post, we’ll show how Session Replay helps you:

• Find the session that matters, fast
• Understand what happened at a glance
• Add comments with context to close the loop between teams
• Run a complete investigation in one place

Find the session that matters, fast

Every investigation starts by locating the right session replay. That’s true whether you’re a frontend engineer investigating an issue with RUM, or a product manager or designer using Product Analytics to understand how users interact with the product.

For frontend engineers looking at a specific error, RUM sessions with an error automatically include an associated session replay. This makes the session you need to investigate easy to find so that you can watch exactly what happened. For product managers and designers looking at a funnel or user journey in Product Analytics, journeys that end with a conversion drop-off also connect directly to an associated replay. This allows you to see exactly what the user did before leaving.

And when you need to search more broadly, both RUM and Product Analytics let you filter sessions by user, device, browser, operating system, error type, and custom attributes. This narrows thousands of sessions down to the ones with a particular error or user of interest.

Understand what happened at a glance

Before you start a replay, AI-generated session summaries provide a concise overview of what happened during each captured session replay. Session summaries describe intent, key actions, friction signals, and outcomes before you start playback, with specific moments hyperlinked so that you can jump directly to them. This helps you understand the session quickly and focus on the most relevant behavior.

Smart chapters break the replay into labeled stages of the user’s journey, and frustration signals like rage clicks, dead clicks, and error clicks appear directly on the player timeline. Together, they let you skip straight to what matters. You can hover over the timeline or use the chapter dropdown to jump to a stage, and spot the moment of friction without having to watch the full recording.

Add comments with context to close the loop between teams

When you find a moment worth sharing, you can leave a timestamped comment at that exact point in the replay. You can also tag the teammate or team that needs to review it. The comment remains anchored to the moment it describes, keeping the finding connected to its supporting context. Mentioned users receive an email notification with a link to the replay and timestamped comment.

You can also copy a link to any comment and share it in Jira tickets, Slack messages, or Confluence pages. Since the link carries the timestamp, teammates never have to search for the moment you flagged.

Visual markers on the player timeline indicate where comments have been added. When playback is paused, or when you hover over the timeline, comment bubbles appear inline. This keeps the discussion visible while you review the replay.

Two default playlists on the Session Replay playlists page help you track this activity. The “All Mentions to Me” playlist collects comments that tag you. The “Commented Replays” playlist shows commented sessions across your organization. These two playlists help you find replays that need your attention and allow you to review sessions that teammates have flagged.

Run a complete investigation in one place

Together, these capabilities make Session Replay a shared workspace for troubleshooting issues and identifying areas of product friction. Consider a checkout drop-off investigation that is launched when a product manager notices a conversion dip in Product Analytics and opens a correlated replay. The session summary flags frustration clicks on a button before playback even starts, and the replay confirms it: A user is error-clicking “Apply” four times before abandoning a $120 cart. The product manager comments at 2:15: “@eng-payments, this user is getting an error applying the SPRING25 code.”

The payments engineer receives the notification and opens the link. The replay starts at 2:15, with the comment already visible. After reviewing the correlated RUM and APM data, the engineer identifies the bug and deploys a fix. They then reply with a staging link with the change to let the product manager know that the issue is being addressed.

The product manager also tags the design team, flagging the problem as a UX issue worth fixing. A designer opens the replay, sees the friction firsthand, and starts improving the error message. Product, design, and engineering can work from the same evidence while addressing different parts of the issue.

In this scenario, Session Replay serves as the record of the investigation, from the first discovery through the final fix. The collaboration, context, and conclusions all remain connected to the moment that started the investigation.

Start investigating faster in Session Replay

Session Replay brings discovery, analysis, and collaboration into one place. Engineering and product teams can find the relevant replays, understand key moments, and share findings without leaving the replay. Timestamped comments preserve the surrounding context, helping everyone work from the same evidence and coordinate the next step.

To learn more, check out the Session Replay documentation covering AI-powered summaries and smart chapters and comments. If you’re new to Datadog, sign up for a 14-day free trial.

Original source

In July’s episode of This Month in Datadog, Ruxanda Lueck joins Jeremy for a conversation about how you can confidently evaluate and release features that contain AI-generated code. She also discusses her career trajectory from containers to AI, how agentic workflows impact trust during feature development, and the challenges of testing nondeterministic agent behavior.

Later, Jonathan Parisot talks with Jeremy about how you can use natural language to ask, understand, and act in Datadog by using Bits Chat. He also discusses how Bits can remember key facts and data, and use skills built around best practices. Lastly, he talks about a future capability to access Bits in your existing workflows through the MCP Server.

New features

Ship code safely and at AI speed with Bits Release

Bits Release, available in Preview, automatically validates code changes from pull request to production. It generates a validation plan, runs checks in staging, and monitors the production rollout, helping you to deploy faster and with confidence.

Generate and maintain synthetic tests with Bits Testing

Bits Testing, available in Preview, autonomously explores your application, identifies critical user journeys, and generates runnable test suites for them, enabling you to speed up testing.

Ask, understand, and act across Datadog with Bits Chat

Bits Chat lets you use natural language to complete tasks in Datadog, such as searching and visualizing data, from the page where you’re already working, so you do not need to switch tools.

Turn operational knowledge into context with Bits Memories

Bits Memories, available in Preview, enables Bits to remember useful facts and data from your team’s work and then recall that information during investigations, reducing the time spent rediscovering or reentering details.

Additional updates

More new features and updates released this month:

• Capture code-level data at runtime with Bits Live Debugger
• Ship internal apps from AI agents with Datadog Apps
• Monitor C and C++ applications with Datadog RUM
• Configure RUM remotely with the Datadog MCP Server
• Detect phone numbers in logs with Sensitive Data Scanner

See you next month

This Month in Datadog is a monthly roundup of our latest features, product announcements, and more. Subscribe to our YouTube channel to get notified when future episodes are live.

In the meantime, check out our release notes for a full list of new features and updates. Or see them in action by logging in to the Datadog platform or signing up for a 14-day free trial.

Original source

Agent Prelude

Released on: 2026-08-05

• Please refer to the 7.82.0 tag on integrations-core for the list of changes on the Core Checks

Upgrade Notes

• Automatic multi-line log detection (logs_config.auto_multi_line_detection) is now enabled by default. Multi-line log messages such as stack traces and JSON blobs are aggregated into a single log entry out of the box, instead of being split into separate entries. To restore the previous behavior, set logs_config.auto_multi_line_detection to false (or the environment variable DD_LOGS_CONFIG_AUTO_MULTI_LINE_DETECTION=false).
• Change default EVP track for AI usage to eudm-intake and disable AI usage agent desktop monitoring by default (the monitor stays in idle mode). AI usage agent's ai_usage_native_host.yaml configuration file is now regenerated from the packaged template on every Agent install and upgrade to ensure the default changes take effect. This is a deliberate short-term measure: it forces already-installed machines onto the updated defaults. Once the defaults are settled (expected within a few Agent releases), the installer will go back to preserving an existing ai_usage_native_host.yaml and only creating it when missing. Note that any customization made to the config file is discarded on every Agent install and upgrade, and must be re-applied afterwards.
• APM: Bump the default version of the datadog-apm-library-js package installed by the Datadog installer from major version 5 to major version 6, following the release of dd-trace-js v6.
• APM: Updates the default JS (Node.js) library used for Kubernetes auto-instrumentation (Cluster Agent admission controller) from major version 5 to major version 6.
• The legacy viper based configuration backend has been removed. The DD_CONF_NODETREEMODEL environment variable and the conf_nodetreemodel configuration setting no longer have any effect and can be removed from your configuration. The Agent now always uses the improved configuration implementation.
• serverless-init no longer forces DD_TRACE_PROPAGATION_STYLE=datadog during tracer auto-instrumentation. The tracer's own default (which includes W3C tracecontext and baggage in addition to datadog) now applies, and a customer-provided DD_TRACE_PROPAGATION_STYLE is respected. Applications that relied on serverless-init restricting propagation to datadog only should set DD_TRACE_PROPAGATION_STYLE=datadog explicitly.

New Features

• Private Action Runner: add the com.datadoghq.remoteaction.rshell.runRemediationCommand action. It behaves like runCommand but runs the restricted shell in remediation mode, which additionally permits file-target output redirections (> , >> , 2> , &> , &>>) and write-oriented builtins such as truncate, all confined to the configured allowed paths. The action is not enabled by default and must be explicitly added to the runner's actions allowlist.
• agent flare now includes diagnostic artifacts from the Agent Data Plane (ADP) process when data_plane.enabled is set to true. If ADP is unreachable at flare time, an UNREACHABLE.txt file containing the connection error is written to ADP's subdirectory and the rest of the flare completes normally.
• When infrastructure_mode is set to cloud_cost_only, the Agent adds an infra_mode:cloud_cost_only tag to metrics from selected integrations. Use integration.cloud_cost_only.tagged to list which checks receive the tag; when the list is empty (the default), all checks are tagged.
• Add a new dogstatsd_no_aggregation_pipeline_workers_count configuration option to control the number of parallel workers processing messages in the no-aggregation pipeline. Defaults to 1 to preserve existing behavior.
• Adds Datadog CSI driver telemetry to COAT, including volume publish and unpublish attempts as well as library resolution, download count and duration, cleanup, cache size, cached library count, and library volume link metrics.
• The Datadog OTLP connector now scales APM stats (hits, errors, duration) by the probabilistic head-based sampling weight carried in the W3C tracestate (th threshold and p power-of-two encodings). When upstream head-based sampling has dropped a fraction of traces, the computed trace metrics are scaled up to reflect the true traffic volume instead of only the sampled subset.
• Envoy Gateway AppSec protection can now run in sidecar mode over a Unix domain socket. Datadog injects the serviceextensions ext_proc container into Envoy Gateway data-plane pods, and Envoy Gateway communicates with it through an Envoy Gateway Backend.

This behavior is selected by cluster_agent.appsec.injector.mode, which now defaults to sidecar. Envoy Gateway must have the Backend extension API enabled with extensionApis.enableBackend: true; if it is disabled, the cluster agent warns and does not change Envoy Gateway configuration.

This is a behavior change for AppSec-enabled Envoy Gateway deployments: they now default to sidecar injection instead of external Service mode. To keep the previous behavior, set cluster_agent.appsec.injector.mode to external.

• Added an experimental telemetry error log forwarder. Disabled by default, the Agent forwards records logged at ERROR level or higher to the COAT intake so Datadog Engineers can aggregate Agent errors across customer organizations. The forwarder shares the agent telemetry transport, inheriting endpoint and compression settings from the agent telemetry configuration.
• On Windows, datadog-installer now honors the DD_AGENT_MAJOR_VERSION and DD_AGENT_MINOR_VERSION environment variables, matching the Linux and macOS install scripts.
• GPU: add the gpu.device.needs_recovery metric, which reports whether a GPU requires a recovery action (such as a reset or node reboot) as exposed by NVML's GPU recovery action field. The value is 0 when no action is needed and 1 otherwise, and the metric is tagged with recovery_action (none, reset, reboot, drain, or drain_and_reset).
• The agent status command now includes a "Logs Agent Backpressure" section reporting per-component utilization of the logs pipeline and an overall HEALTHY / WARNING / SATURATED state, making it easier to see which pipeline stage is the bottleneck when logs are delayed.
• On macOS, the Agent can now be restarted directly from the web-based GUI (Agent Manager).
• New Agent Secret Backend: "windows.regkey"
• APM Single Step Instrumentation now supports setting tracer configuration options via the admission.datadoghq.com/apm-inject.tracer-configs pod annotation, the annotation-based equivalent of the apm_config.instrumentation.targets[].ddTraceConfigs option. The value is a JSON array of objects (for example [{"name":"DD_PROFILING_ENABLED","value":"true"}]) and each entry's name must start with the DD_ prefix.
• NetFlow: automatically detect and split Cisco FirePower/ASA bidirectional (NSEL) flow records into two unidirectional flow events. NSEL records carry initiator→responder and responder→initiator byte/packet counts in NFv9 fields 231/232/298/299; the agent now captures these fields via built-in mappings and emits a separate flow for each direction with correctly swapped src/dst addresses, ports, and interfaces. No user configuration is required.

Enhancement Notes

• Malformed ad.datadoghq.com/service.* and ad.datadoghq.com/endpoints.* annotations on Kubernetes services are now reported as Autodiscovery misconfiguration health events when the health platform is enabled. The issue is resolved automatically once the annotation is fixed.
• Adds Agent Data Plane packaging and launchd service support to macOS Agent packages.
• Adds Agent Data Plane packaging to Windows Agent MSI installs. ADP is supervised by dd-procmgr via processes.d/datadog-agent-data-plane.yaml, written by the fleet installer during postinst (same pattern as DDOT on Windows).
• Emit datadog.cluster_agent.kubernetes_actions.running when kuberenetes actions product is enabled and running.
• Podman receiver metrics collected via the Datadog Distribution of OpenTelemetry (DDOT) Collector are now correctly classified with origin opentelemetry_collector_podmanreceiver instead of falling back to opentelemetry_collector_unknown.
• Added the data_plane.stop_timeout configuration setting, which controls the graceful shutdown budget for the Agent Data Plane (ADP). When unset, it derives its value from aggregator_stop_timeout + forwarder_stop_timeout, so customizing either of those component timeouts now extends ADP's shutdown window in lockstep with the core Agent.
• On startup the Datadog Agent now validates the system-probe configuration against its schema and reports any violations through the Agent Health pipeline. Only the values the customer set in the configuration are validated. This can be disabled with health_platform.invalidsysprobeconfig_check.enabled.
• On Windows, the AI Usage Chrome Native Messaging host is now delivered as a fleet-managed Agent extension that is only installed when End User Device Monitoring is enabled (infrastructure_mode: end_user_device). It is no longer unconditionally installed by the MSI, and is skipped on Agent upgrades when End User Device Monitoring is disabled.
• APM: Added cardinality limits to client-side stats computation in the stats concentrator. These limits are no-op in the agent and are intended for use by the Go tracer.
• Agents are now built with Go 1.26.5.
• dd-procmgrd: Add write RPCs (Create, Start, Stop, ReloadConfig, GetConfig) for runtime control of managed processes.
• On Windows, the ddinjector system-probe telemetry now negotiates the counter contract version with the installed driver, reporting new crash and boot-r...

Original source

If you run a cloud security program, two questions follow almost every security finding: Who owns this? And how important is it? Many security tools answer those questions with static metadata such as owner tags, business criticality labels, and manually maintained inventories of critical assets, known as crown jewels. But cloud environments aren’t static. Teams reorganize, services change hands, and dependencies evolve. The result is stale tags, manual triage, and thousands of findings with little indication of which ones actually matter.

The Datadog Runtime Prioritization Engine (RPE), a component of Datadog Cloud Security, helps you prioritize findings by identifying who should address them and whether they affect your most critical resources. It continuously analyzes the live telemetry data that you send to Datadog, combining runtime context with security signals to reduce alert noise.

In this post, we’ll explore how AI-powered capabilities in RPE automatically infer ownership and discover crown jewels.

Automatically infer ownership

The Runtime Prioritization Engine uses the Ownership Agent to identify the most likely owner for security findings, even when ownership metadata is incomplete or missing. The agent considers explicit ownership signals such as owner tags and ownership preferences when they’re available, and it uses observability and security telemetry data to fill in the gaps when that information is missing.

To infer ownership, the agent evaluates the following signals and combines them in a ranked evidence model:

• Owner tags and ownership preferences
• Ownership metadata as defined in the Datadog Catalog
• Cloud audit logs that identify who created or modified a resource
• Container and host metadata
• Naming conventions and organizational patterns
• Source control integrations, including CODEOWNERS files
• The affected resource and security finding

By combining these signals, RPE identifies the most likely owner and enriches that information with on-call schedules, team hierarchies, dashboards, ticketing and team member information, team messaging channels, and team-owned repositories. This context enables security teams to route findings and coordinate remediation by using their existing collaboration tools and engineering workflows.

Ownership information appears directly in the Cloud Security side panel for vulnerabilities and misconfigurations. You can review, confirm, or override suggested owners, helping the Ownership Agent continuously learn. You can also define ownership preferences to map tags, exclude specific teams from being assigned ownership, and provide custom guidance directly to the agent.

Automatically identify critical resources

Knowing who owns a finding is only half the equation. Security teams also need to understand what is actually worth protecting. Organizations typically maintain some version of a crown jewels inventory—a list of the applications, databases, and cloud resources whose compromise would have the greatest business impact. These inventories are often manually maintained and quickly become outdated as cloud environments evolve.

With Datadog Crown Jewels, the Runtime Prioritization Engine uses observability data to build your inventory of critical resources automatically. Rather than relying on static classifications, RPE continuously analyzes runtime telemetry data to identify the services, databases, and cloud storage resources that matter most to your business. These assets typically handle sensitive data, process critical workloads, or occupy central positions in your production architecture.

RPE identifies crown jewels by using signals such as:

• Sensitive data detected in Datadog APM spans, application logs, cloud storage, and API traffic
• Database schemas that contain sensitive fields
• Service dependency fan-in and architectural centrality from APM

Because RPE analyzes live observability data, the inventory of crown jewels continuously evolves. As services are deployed, workloads change, or instrumentation expands, RPE automatically updates the inventory to reflect which resources are critical.

Security teams remain in control with the ability to validate and refine the generated inventory. They can remove resources from the list and manually add assets that RPE didn’t include automatically.

Start prioritizing findings with the Runtime Prioritization Engine

The Datadog Runtime Prioritization Engine, generally available, analyzes security findings to help you prioritize the issues that require remediation. By combining observability data with AI-powered ownership inference and Crown Jewels detection, RPE reduces alert noise and helps your teams focus on business-critical risks. To learn more, read the Runtime Prioritization Engine documentation.

If you’re new to Datadog, you can sign up for a 14-day free trial to get started.

Original source

Agent

Prelude

Released on: 2026-07-30

• Please refer to the 7.81.3 tag on integrations-core for the list of changes on the Core Checks

Bug Fixes

• Windows: Fixed an issue where the DDAGENTUSER_KEEP_RIGHTS opt-out was not preserved when the Agent was upgraded through Fleet Automation. Fleet-triggered upgrades uninstall and reinstall the Agent MSI as two separate steps, which cleared the stored opt-out before the reinstall could read it back, causing the SeDeny*LogonRight assignments on the Agent service account to be reapplied even when the customer had previously opted out with DDAGENTUSER_KEEP_RIGHTS=1. In-place MSI upgrades were not affected.
• Fixed an issue where Remote Configuration would sometimes attempt to process client requests that had already timed out.

Datadog Cluster Agent

Prelude

Released on: 2026-07-30 Pinned to datadog-agent v7.81.3: CHANGELOG.

Original source

Agent

Prelude

Released on: 2026-07-22

• Please refer to the 7.81.2 tag on integrations-core for the list of changes on the Core Checks

Upgrade Notes

• Metrics now use the Datadog v3 intake by default for Datadog destinations.
  Metric destinations configured with non-Datadog-looking URLs, such as custom additional_endpoints and reverse proxies, continue to use the v2 intake by default. To enable v3 for every destination, set use_v3_api.series.enabled: "true". To keep using v2 intake, set use_v3_api.series.enabled: "false" (global) or use_v3_api.series.endpoints: { "": "false" } (per-endpoint).

Bug Fixes

• On macOS, opening the Datadog Agent GUI via the fallback launch method no longer steals focus from the application the user is currently working in.

Datadog Cluster Agent

Prelude

Released on: 2026-07-22 Pinned to datadog-agent v7.81.2: CHANGELOG.

Original source

Send OTel data to Datadog in a vendor-neutral way

The recent announcement that OpenTelemetry (OTel) has achieved CNCF graduation further reinforces OTel’s credibility as the industry standard for vendor-neutral telemetry. As organizations increasingly adopt the OpenTelemetry Protocol (OTLP), the OTel Collector, and OTel SDKs, they need an observability platform that supports OTel-native data without sacrificing flexibility or portability.

To meet these important customer requirements, Datadog has been significantly expanding its support for OTel-native observability. Whether by enabling you to send OTLP telemetry through vendor-neutral ingestion paths, to investigate issues with OTel-native data, or to manage OpenTelemetry Collectors across a fleet, Datadog supports OTel at every step. Behind the scenes, Datadog is also continuing to make significant contributions to the OpenTelemetry project to further enrich the open source standard with additional powerful features.

Many teams adopt OTel because they want the flexibility to choose how telemetry is generated, collected, processed, and routed. Using OTel SDKs, the OTel Collector, and OTLP lets teams build pipelines that fit their architecture.

Previously, sending OTel data to Datadog via the OTel Collector required the Datadog Exporter. But now, in a Preview feature, Datadog supports telemetry data ingestion via the standard OTLP HTTP Exporter, a fully vendor-agnostic component included in the standard OTel Collector. With this OTel-native instrumentation, teams can send OTel data to Datadog without relying on any proprietary components like the Datadog Agent, Datadog Exporter, or Datadog Connector. This method allows you to use standards-based telemetry end to end, from instrumentation to ingestion and analysis in Datadog, while supporting your journey toward complete vendor neutrality.

Additionally, for teams that don’t want to run an OTel Collector at all, Datadog’s direct OTLP intake endpoint is now generally available. With this feature, applications can send OTLP metrics, logs, and traces directly to Datadog without any intermediate collection layer, like an OTel Collector or Datadog Agent. This is particularly useful for managed services or serverless environments where running a sidecar or agent adds unnecessary overhead.

Investigate Kubernetes and application issues with OTel-native data

Once data from OTel sources reaches Datadog, it powers the same experience for products like Infrastructure Monitoring and Application Performance Monitoring (APM) that teams already rely on. No transformations, mappings, or Datadog-specific instrumentation are required. Previously, some of these experiences required signals gathered from the Datadog Agent or Datadog SDKs. Now, OTel-native data powers them directly.

For example, the Kubernetes Explorer can now be populated directly with OTel data. Previously, this experience required signals from the Datadog Agent. Now, metrics collected from standard OTel receivers like kubeletstatsreceiver power the same cluster exploration and troubleshooting workflows, including table views of clusters, nodes, namespaces, and pods.

Datadog also handles semantic normalization automatically, so metrics collected from different receivers with varying units or types are represented across views in a consistent way. This means that, for teams running hybrid environments, the Kubernetes Explorer can join data from OTel pipelines and the Datadog Agent side by side. You can troubleshoot across clusters without worrying about how each signal was collected.

With the OTel-native instrumentation, Datadog APM also now works directly with services instrumented using OTel SDKs. Teams can view and query OTel-native traces in Datadog by using OTel span semantics and attributes, without requiring any translation or re-instrumentation.

Additionally, features like the Internal Developer Portal’s Catalog and each service page are powered by RED metrics generated from OTel trace data via the open source spanmetrics connector component. The connector is configured with dimensions that allow Datadog to compute host tags, peer services, and operation names directly from your traces. Out-of-the-box dashboards featuring runtime metrics from OTel SDKs are also automatically surfaced in Datadog, giving teams visibility into service health without requiring any Datadog-specific instrumentation.

Whether telemetry comes from the Datadog Agent and Datadog SDKs or the OTel Collector and OTel SDKs, teams can adopt OTel incrementally and at their own pace. As a result, they can query OTel-native data in Datadog by using the same span semantics and attributes they’re most familiar with.

Investing in OTel beyond Datadog

Datadog’s commitment to OTel goes beyond supporting its own products. Datadog engineers actively contribute to OTel repositories, participate in special interest groups (SIGs), and help advance standards across areas such as the Collector, semantic conventions, profiling, sampling, real user monitoring, and Open Agent Management Protocol (OpAMP).

In March 2026, Datadog engineers co-authored the alpha release of OTel Profiles alongside contributors from Google, Elastic, and others. The work involved standardizing a unified profiling data format compatible with existing formats like pprof and integrating profiles as a first-class signal in the OTel Collector alongside traces, metrics, and logs.

As OTel’s profiling signal matures, Datadog intends to support it natively in its own profiling products. For example, the Full Host Profiler, now in Preview, is built on the OTel eBPF profiler. It profiles all processes on a host without requiring any code changes or instrumentation, giving teams visibility into every process, runtime, and language.

By investing upstream, Datadog is helping OTel mature as an open standard while making Datadog a stronger destination for teams that choose OTel. Customers can expect continued involvement from Datadog across OTel projects like real user monitoring, OpAMP, and semantic conventions for serverless workloads as the work on these standards continues.

Get started with adopting OpenTelemetry

Whether you’re just beginning to instrument services with OTel or expanding an existing deployment, Datadog can support your team at each step. You can build vendor-neutral pipelines with upstream OTel components; send OTLP metrics, logs, and traces to Datadog; and use Datadog’s infrastructure and APM workflows with OTel-native data.

To get started, request access to the OpenTelemetry Native Instrumentation Preview. To learn more about Datadog’s OTel support, see our Getting Started with OpenTelemetry guide. And if you’re not yet a Datadog customer, sign up for a 14-day free trial.

Original source

Managing cloud, AI, and SaaS costs means answering a steady stream of questions from finance, leadership, and engineering teams.

What changed? Which team owns the spend? Was an increase expected? Are we still on track against the budget? When each answer requires moving between dashboards, filtering cost data by team or service, or manually correlating billing data with observability data, it can slow down investigations while costs continue to rise.

The Cloud Cost skill in Bits Chat brings Cloud Cost Management analysis into a conversational workflow. You can ask cost questions in plain language, investigate cost anomalies, and get answers grounded in both cost and observability data within minutes. In this post, we’ll show how you can:

• Ask Bits Chat anything about your costs
• Spot Anthropic cost spikes before they grow
• Find the root cause of a cost change

Ask Bits Chat anything about your costs

The Cloud Cost skill gives FinOps practitioners and engineers one place to ask cost questions without needing to know which dashboard to open or how to construct a query. You can get started with Bits Chat in the Datadog navigation bar, or you can start an investigation directly from a cost anomaly. From there, Bits Chat analyzes the relevant cost data and responds with a concise summary, then asks what you want to explore next.

Because the Cloud Cost skill works across many cost categories, including cloud, SaaS, AI, custom, and Datadog, teams can use the same workflow for any cost question. FinOps teams can use it to track budgets, identify cost owners, and investigate anomalies. Engineers can use it to understand the cost impact of their own services and workloads, and identify optimization opportunities. For example, you can ask Bits to investigate why Anthropic costs increased last week for team:web-store, identify which teams are driving the highest OpenAI spend this month, or show total AI cost by provider for the last 30 days.

Bits Chat can investigate cost monitor alerts, cost anomalies, and cost changes; identify teams, services, accounts, regions, or resources that are driving spend; and compare actual or forecasted spend against budgets. It can also correlate cost changes with observability metrics such as CPU, memory, request volume, and storage size. This gives teams the technical context they need to understand whether a cost change came from a usage increase, a configuration change, or another source.

Spot Anthropic cost spikes before they grow

AI usage can become expensive quickly, especially when costs are spread across providers, models, teams, users, and services. AI Costs in Cloud Cost Management gives FinOps and engineering teams a unified location for analyzing AI spend across providers such as OpenAI, Anthropic, Amazon Bedrock, Google Gemini, Vertex AI, GitHub Copilot, and Cursor. Datadog normalizes this spend so teams can understand which providers, models, users, and API keys are contributing to cost changes.

This level of granularity helps teams detect AI cost anomalies before they cause larger budget issues. For example, Datadog can surface an unexpected Anthropic cost spike that might otherwise go unnoticed until the next billing review. But identifying a spike is only half the problem—understanding what caused it is another. Without a connected cost investigation workflow, a team would need to pull billing exports, cross-reference logs, and search for the service or team that caused the change.

With the Cloud Cost skill, the team can start the investigation in one click. When the team clicks “Investigate” directly from the anomaly, Bits automatically pulls in the relevant context and kicks off a root cause analysis. This lets the team move from detection to investigation without leaving the AI Costs page or having to do any manual work.

Find the root cause of a cost change

Once an investigation starts, Bits Chat performs root cause analysis by using both cost data and observability data from across Datadog. For a cost anomaly investigation, the initial analysis typically includes a daily cost chart for the baseline and investigation periods so you can see exactly when a change started. It also summarizes the total dollar change, percentage change, and projected annual impact when applicable.

Bits Chat also provides rate-versus-usage context, which helps teams determine whether spend increased because of a pricing change or because a team consumed more of a resource. For AI spend, this distinction is especially important. An Anthropic spike might come from more requests, larger prompts, higher output token usage, a model change, or a combination of these factors. By correlating cost with observability metrics, Bits can help connect the billing change to the system behavior behind it.

In the preceding example screenshot, Bits identifies that the Anthropic cost spike is driven by two teams: Customer Support (57%) and AI Platform (37%). Together, these teams account for the full $2,895.49 increase—a 188.15% jump—with a projected annual impact of $62,167.87. Instead of knowing only that Anthropic costs went up, the engineer can see exactly which teams are driving it and by how much, which makes it immediately clear who to loop in.

From there, the team can keep drilling into the investigation. Bits can find the top services, accounts, regions, resources, or tags driving the change. It can also compare actual and forecasted spend against related budgets, identify optimization opportunities, and create a Datadog Notebook that captures the investigation for the owning team. This helps preserve the full context, so the team does not need to reconstruct the analysis later from Slack threads or separate reports.

Get started with the Cloud Cost skill in Bits Chat

The Cloud Cost skill in Bits Chat helps FinOps and engineering teams investigate cost changes, budget risks, and AI spend in the same place where they already monitor their systems. By grounding answers in both cost and observability data, Bits Chat can help teams move from a broad cost question to an actionable explanation in minutes.

To get started, make sure you’ve configured Cloud Cost Management for the cost sources you want to analyze. Users also need Bits Chat access and Cloud Cost Management permissions for the data they ask about. If you want Bits to create or update investigation records, you can also grant the relevant Notebooks permissions. Learn more in the Cloud Cost skill documentation, Bits Chat documentation, and AI Costs in Cloud Cost Management documentation.

If you don’t already have a Datadog account, you can sign up for a 14-day free trial to start investigating your cloud costs with Datadog.

Original source

Local data storage capacity gives Datadog customers greater flexibility in how they meet UK data residency, governance, compliance and security requirements

London, UK — 16 July 2026 — Datadog, Inc. (NASDAQ: DDOG), the leading AI-powered observability and security platform for cloud applications, announced it has launched its products and services on the Amazon Web Services (AWS) Europe (London) Region.

This gives Datadog’s customers and partners additional options to store observability and security data within the UK, with lower latency and streamlined incident response for greater operational resilience. It also supports customers as they navigate evolving data governance and compliance considerations, while maintaining unified visibility across cloud, hybrid, and AI environments.

The launch is particularly relevant for organisations in regulated sectors, including financial services, healthcare, government and higher education, where in-region data residency and operational continuity are key considerations. By keeping observability and security data closer to the workloads being monitored, Datadog helps organisations investigate incidents faster, improving system reliability, and strengthening security operations.

“UK enterprises scaling cloud and AI workloads increasingly want the option to keep observability and security data in-region to support their data governance and operational resilience,” said Yanbing Li, Chief Product Officer at Datadog. “AI is accelerating the complexity of modern systems, creating more data, dependencies, and potential points of failure. This milestone helps customers keep observability and security data close to their workloads while maintaining the resilience and governance needed to operate at scale. With end-to-end visibility across infrastructure, applications, security, and AI, Datadog gives customers the complete picture they need to maintain operational control.”

Steve Barrett, VP EMEA at Datadog added, “Cloud adoption is now the norm for UK organisations, and AI is adding a new layer of operational complexity. As systems become more distributed, observability becomes increasingly important to maintaining resilience, security and control. Launching on the AWS Europe (London) Region gives customers the option to keep their observability and security data in-region, helping them strengthen governance while continuing to scale with confidence.”

For more information, visit:

https://docs.datadoghq.com/getting_started/site/

About Datadog

Datadog is the leading observability and security platform for the AI era, providing businesses with unified visibility across the technology stack to manage complexity at scale. It brings applications, infrastructure, data, models, and security into one place, using AI to detect and resolve issues before they impact customers. Trusted globally by Fortune 500 companies and high-growth AI leaders, Datadog enables businesses to move faster with clarity and confidence.

Forward-Looking Statements

This press release may include certain “forward-looking statements” within the meaning of Section 27A of the Securities Act of 1933, as amended, or the Securities Act, and Section 21E of the Securities Exchange Act of 1934, as amended including statements on the benefits of new products and features. These forward-looking statements reflect our current views about our plans, intentions, expectations, strategies and prospects, which are based on the information currently available to us and on assumptions we have made. Actual results may differ materially from those

Original source

Agent

Prelude

Released on: 2026-07-08

• Please refer to the 7.81.0 tag on integrations-core for the list of changes on the Core Checks

Metrics are now forwarded to the new Datadog v3 API by default (/api/intake/metrics/v3/series). The v3 API payload format is more compact, reducing outbound bandwidth from Agents to Datadog.

If you configure additional_endpoints to forward to a non-Datadog endpoint, you will likely need to disable v3 for this endpoint. Otherwise you will see 404s. This can be done via:

use_v3_api:
  series:
    endpoints: "<additional_endpoint>": false

Example:

additional_endpoints:
  "https://non-datadog-endpoint": apikey2

will need:

use_v3_api:
  series:
    endpoints:
      "https://non-datadog-endpoint": false

Metrics sent to Observability Pipelines Worker continue to use the v2 API by default.

To keep using v2 endpoint, set use_v3_api.series.enabled: "false" (global) or use_v3_api.series.endpoints: { "": "false" } (per-endpoint; shown above).

Upgrade Notes

• The DDOT feature gate exporter.datadogexporter.metricremappingdisabled has been removed and replaced with exporter.datadogexporter.DisableAllMetricRemapping.
• Removed the agent status py subcommand (which wasn't officially supported)
• On Linux, the agent process manager systemd units were renamed from datadog-agent-procmgrd.service / datadog-agent-procmgrd-exp.service to datadog-agent-procmgr.service / datadog-agent-procmgr-exp.service. The dd-procmgrd binary and its paths are unchanged.

On upgrade, the installer stops and removes the legacy procmgrd-suffixed unit files so only one process manager daemon binds the socket. Update any custom automation that referenced the old unit names.

• Upgrade OpenTelemetry Collector dependencies from v0.152.0 to v0.153.0 (core v1.58.0 to v1.59.0).

See the full upstream changelogs: collector-contrib v0.153.0, collector core v0.153.0.

• Upgrade OpenTelemetry Collector dependencies from v0.153.0 to v0.154.0 (core v1.59.0 to v1.60.0).

See the full upstream changelogs: collector-contrib v0.154.0, collector core v0.154.0.

New Features

• In-place vertical scaling is enabled as the default strategy for workload autoscaling.
• New metrics for GPU memory have been added to the GPU Monitoring product:
  • gpu.memory.utilization: Ratio of used memory compared to total memory.
• Add passthrough entry for genresources EVP intake track.
• This change adds two new metric points for the GPU Monitoring product:
  • gpu.pci.link.speed.current: Current usable bandwidth for the PCI link in bytes per second
  • gpu.pci.link.speed.max: Max usable bandwidth for the PCI link in bytes per second
• Add a new ReportIssue method to the Python bridge to report issues to Agent Health Platform
• APM: The trace-agent can now receive span tag equivalence and peer tag mapping updates over Remote Configuration and apply them at runtime, without an agent restart. The feature is opt-in via the new remote_configuration.apm_semantics.enabled setting (default false). Stats aggregation picks up the updated peer-tag keys on the next span processed. If the backend removes or untargets a previously-applied payload, the trace-agent reverts to the mappings it ships with. Existing deployments see no behavior change with default settings.
• APM: remote_configuration.agent_config.enabled is now a settable configuration entry that controls the trace-agent's Remote Configuration subscription for agent-config updates (such as runtime log-level overrides) independently from remote_configuration.apm_sampling.enabled. When the user has explicitly set apm_sampling.enabled but not agent_config.enabled, the trace-agent mirrors the former into the latter so existing configurations continue to behave exactly as before.
• On Linux, when the DDOT extension is installed with the Datadog Agent, DDOT is now managed by dd-procmgrd through processes.d/datadog-agent-ddot.yaml instead of relying on the legacy datadog-agent-ddot systemd unit. Uninstalling the extension removes that config file. To roll back to the legacy behavior manually, remove processes.d/datadog-agent-ddot.yaml and restart datadog-agent.
• Add Go stack trace aggregation to the auto multi-line log pipeline. When auto multi-line aggregation is enabled (logs_config.auto_multi_line_detection), multi-line Go crash dumps (panic:, fatal error:, runtime: errors, signal crashes, and unexpected faults) are automatically detected and combined into a single log entry using a streaming state-machine parser.
• gpu: all gpu.nvlink.* metrics now have a nvlink_port tag and are emitted per-port. We provide GPU-level alternatives for certain metrics such as gpu.nvlink.throughput.data.rx/tx.total
• Enable instrumentation_crd_controller.enabled and a new autodiscovery provider will schedule checks derived from DatadogInstrumentation custom resources deployed in the Kubernetes cluster.
• Parses and collects kubernetes.pod.cpu.requests, kubernetes.pod.memory.requests, kubernetes.pod.cpu.limits, and kubernetes.pod.memory.limits.
• Process Autodiscovery is now enabled by default on Linux through the process autoconfig feature. It can be disabled with DD_AUTOCONFIG_EXCLUDE_FEATURES=process.
• Register process_manager.enabled in the Agent configuration schema (pkg/config/schema/core_schema.yaml), set its default in pkg/config/setup, and document it in config_template.yaml. On Windows, this option controls whether the core Agent starts dd-procmgr-service. On Linux, dd-procmgrd is started by systemd; this setting is ignored there.

Enhancement Notes

• Use compensated floating point summation to accurately calculate the sum and average aggregates of histograms for inputs where magnitudes significantly vary.
• Scale .sum, .avg, and .count aggregates by the exact 1/SampleRate to avoid undercount of these aggregates for sample rates whose reciprocal is not an integer (e.g. @0.21).
• The macOS battery check now adds a power_state:battery_critical tag to the system.battery.power_state metric when the operating system reports a degraded battery.
• Update the SNMP traps database with new MIB additions, including PANZURA-TRAP-MIB.
• Updated the ntp check to support the default location of systemd-timesyncd (/etc/systemd/timesyncd.conf). The check now parses NTP= and FallbackNTP= keys in addition to the existing chrony/ntp.conf server / pool / peer directives.
• On startup the Datadog Agent will now validate its configuration against the schema and report any violations through the Agent Health pipeline.
• APM stats now mask additional metric tag values that exceed the value length or per-bucket cardinality limits.
• APM : The enable_otlp_container_tags_v2 behavior is now enabled by default. Container tags on OTLP traces are now extracted using the infraattributes processor instead of calling the tagger directly, reducing redundant work and outgoing traffic. To opt out, set disable_otlp_container_tags_v2 in apm_config.features.
• Agents are now built with Go 1.26.4.
• CWS: Add support for monitoring the socket system call, enabling detection rules based on socket creation events (domain, type, protocol).
• The comp/dataobs/queryactions component now supports an optional schedule field on Data Observability monitor queries. The field accepts a standard 5-field cron expression (e.g. "20 * * * *" for 20 minutes past every hour) and enables wall-clock-aligned scheduling in place of the fixed interval_seconds cadence. When both schedule and interval_seconds are set on the same query, schedule takes precedence and interval_seconds is ignored. At least one of the two fields must be set; the agent rejects Remote Configuration payloads containing queries where neither field is provided or where the cron expression is syntactically invalid.
• Expanded the functionality of the experimental fentry-based network connection tracer. This tracer remains experimental and disabled by default.
• gpu: add new PCI link width metrics gpu.pci.link.width.{current,max} and add degraded PCI link metrics gpu.pci.link.{width,speed}.degraded.
• gpu: add gpu.nvlink.errors.fec.{none,light,heavy} metrics to easily group error thresholds
• The in-place vertical autoscaler throttles disruptive resizes to at most 15% of a workload's replicas per reconcile, configurable via autoscaling.workload.in_place_vertical_scaling.disruption_tolerance_percent.
• use the /healthz route to check and validate kubelet connection, instead of the deprecated /spec route.
• The agent automatically detects Kueue-related labels in pods and adds them as kueue_local_queue and kueue_cluster_queue tags.
• Network Config Management: Adds support for Cisco ASA firewalls by adding a new profile for these. Previously, Cisco ASA was not supported and would be unmonitored by the NCM integration.
• Extended the ntp check's systemd-timesyncd discovery to also read drop-in files under /etc/systemd/timesyncd.conf.d/, /run/systemd/timesyncd.conf.d/, /usr/local/lib/systemd/timesyncd.conf.d/, /usr/lib/systemd/timesyncd.conf.d/. This covers hosts where NTP= is set by cloud-init or another tool that writes a drop-in instead ...

Read more

Assets 2

Original source

Detect and troubleshoot crashes in .NET MAUI apps

As .NET Multi-platform App UI (MAUI) becomes the default cross-platform UI framework in the Microsoft ecosystem, many teams are standardizing on it to build mobile applications for iOS and Android. However, observability has not kept pace with the shift in adoption. Developers often rely on unsupported community bindings or maintain their own wrappers around native iOS and Android SDKs, which introduces instability and ongoing maintenance. The retirement of Microsoft Visual Studio App Center has also left many teams without a clear path for monitoring crashes, errors, and user activity in production.

Datadog Real User Monitoring (RUM) provides an official .NET MAUI SDK that enables teams to instrument applications by using a single supported NuGet package. The SDK supports many core RUM features, including built-in crash reporting, error tracking, and network monitoring, along with Session Replay. All telemetry data flows into existing Datadog views, so you can analyze .NET MAUI applications alongside other mobile apps built with native iOS and Android or other cross-platform frameworks such as React Native, Flutter, and Kotlin Multiplatform.

In this post, we’ll explore how you can use the SDK to:

• Detect and troubleshoot crashes in .NET MAUI apps
• Understand user sessions and performance across .NET MAUI apps

Mobile crashes in production often require significant effort to reproduce and diagnose, especially when stack traces are incomplete or difficult to interpret. Community-maintained bindings can compound the problem by introducing gaps in instrumentation or becoming incompatible with new SDK releases.

The Datadog .NET MAUI SDK automatically captures crashes and errors across managed and native layers of an application. Coverage includes .NET exceptions and platform-specific issues such as iOS App Hangs and Android Application Not Responding (ANR) events. Automatic instrumentation enables teams to begin collecting telemetry data without adding custom logic or maintaining separate integrations.

Datadog deobfuscates stack traces through its symbol upload process, which uses PDB files to restore readable method names and source context. Engineers can investigate issues with clear, actionable information instead of working with obfuscated output.

For example, consider a scenario where a team releases a new version of a .NET MAUI app and begins receiving crash reports shortly afterward. An engineer can navigate to Datadog Error Tracking, identify a spike in crashes tied to the new release, and review the associated stack traces. Correlating the crash with recent code changes helps the team isolate the faulty method and begin remediation.

Crash and error data from .NET MAUI apps appears alongside data from other supported mobile apps in the same Datadog views, including the RUM Explorer, Error Tracking, and session details pages. The shared interface enables teams to apply existing workflows without introducing additional tools.

Understand user sessions and performance across .NET MAUI apps

Understanding how users interact with an application and how services respond plays a key role in maintaining performance and reliability. Limited instrumentation often leaves teams without visibility into network latency, failed requests, and the sequence of user actions that led to issues.

The .NET MAUI SDK automatically tracks network requests made through common libraries, such as HttpClient. Automatic collection provides out-of-the-box visibility into request latency and error rates, in addition to automated correlation with downstream backend dependencies through distributed APM traces.

View and action tracking give developers control over how user activity is captured and organized in session data. Developers can use views to track the screens that users navigate to. With actions, developers can capture user interactions that align with specific workflows.

Session, network, and interaction data all appear in the RUM Explorer and session detail pages. Teams can use the unified dataset to analyze performance and identify patterns across iOS, Android, and other supported platforms.

Get started with .NET MAUI monitoring in Datadog

The Datadog .NET MAUI SDK provides a supported path to instrument cross-platform mobile apps without relying on community-maintained bindings or custom wrappers. Automatic crash reporting, network monitoring, and manual instrumentation capabilities give teams visibility into application health and user behavior. To learn more, read our .NET MAUI SDK documentation.

If you’re new to Datadog, you can sign up for a 14-day free trial to start monitoring your .NET MAUI apps.

Original source

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.

Datadog AI Guard now works with AWS Strands Agents through a Strands plugin that evaluates prompts, model responses, and tool interactions as the agent runs. By using the Strands native hook system, AI Guard can monitor or block unsafe behavior in the agent loop without requiring teams to scatter security checks throughout application code. In this post, we’ll show how to:

• Monitor the Strands agent loop
• Evaluate prompts, responses, and tool calls inline
• Configure enforcement without changing agent code
• Investigate AI Guard evaluations in Datadog

Monitor the Strands agent loop

Strands Agents takes a model-driven approach to orchestration. The model reasons through the task, chooses tools, builds context from previous steps, and decides when it has enough information to respond. This design helps teams build agents that can handle open-ended workflows, but it also means the application’s behavior can change with each user request and model decision.

Traditional application security controls are not always designed for this type of runtime behavior. An agent’s risk can depend on the sequence of prompts, intermediate tool results, and tool calls that led to a particular action. The attack surface is a dynamic sequence of model decisions that changes with every interaction. If teams add custom checks directly into each part of that workflow, those checks can make the agent harder to audit and maintain. Teams also need to redeploy the application whenever they change those checks.

The AI Guard plugin for Strands Agents gives teams a central place to evaluate agent behavior as the agent runs. The plugin assesses every interaction in the context of the full agent session to catch multistep attacks that become harmful only after several tool calls. It registers callbacks on Strands life cycle events, sends relevant content to AI Guard for evaluation, and applies the configured response before the agent loop continues. This makes AI Guard part of the agent’s execution path rather than a separate review layer after the fact.

Evaluate prompts, responses, and tool calls inline

AI Guard evaluates the parts of an agent session where risk most often appears: user input, assistant output, tool invocations, and tool results. This inline approach helps teams inspect agent behavior in context, including the relationship between a tool call and the preceding steps that produced it.

The AIGuardStrandsPlugin registers callbacks for four Strands hook events:

HOOK EVENT WHAT AI GUARD EVALUATES RESPONSE WHEN BLOCKED BeforeModelCallEvent User prompts, excluding tool results Raises AIGuardAbortError AfterModelCallEvent Assistant text content Raises AIGuardAbortError BeforeToolCallEvent Pending tool call and conversation context Cancels the tool with a descriptive message AfterToolCallEvent Tool result and conversation context Replaces the tool result content

These checks help protect against common risks in production agent workflows. Prompt protection evaluates user prompts and model responses for attacks such as prompt injection and jailbreaking. Tool protection analyzes tool calls, arguments, intent, and surrounding context to help determine whether an invocation should continue. Sensitive data protection detects personally identifiable information (PII), secrets, and other sensitive content in LLM inputs and outputs.

The AI Guard plugin also avoids duplicate evaluations. Tool results that AI Guard evaluates during AfterToolCallEvent are excluded from the next BeforeModelCallEvent scan, which prevents the same content from being evaluated twice. If the AI Guard API is unreachable because of a network error, the plugin logs the failure at the debug level and allows the agent to continue.

Configure enforcement without changing agent code

AI Guard supports a monitor mode that lets teams observe evaluations before they start blocking traffic. This is useful when you are first adding AI Guard to an agent, tuning policy behavior, or evaluating how detections map to real production traffic. After your team has reviewed the results, you can switch a service to blocking mode from the AI Guard settings.

You can also adjust detection sensitivity to make policies stricter or more lenient for a given service. For tool-specific controls, AI Guard supports a tool denylist that proactively blocks selected tools from being used by the agent. This gives security and platform teams a way to reduce risk for sensitive actions, such as file operations, administrative APIs, or payment-related tools.

Because these controls are managed in Datadog, teams can update policies without editing the agent or redeploying the application. This is especially helpful when multiple teams own different agents across environments. Security teams can start in monitor mode, review how agents behave in practice, and then tighten controls as policies mature.

Investigate AI Guard evaluations in Datadog

After you add AI Guard to a Strands agent, evaluations appear in Datadog as spans that show whether an interaction was safe or unsafe. For unsafe interactions, Datadog includes the attack category, such as prompt injection, data exfiltration, tool misuse, or jailbreaking. These spans link to Datadog APM and Agent Observability traces, so teams can move from a flagged evaluation to the broader agent session that produced it.

This trace context is important because agent attacks often unfold over several steps. A single prompt, tool call, or response might look harmless in isolation, but the full session can reveal how an instruction changed the agent’s behavior or how a tool result influenced the next model call. By reviewing the span side panel, teams can inspect previous prompts, tool calls, and related context as part of the same investigation. Every evaluation decision is a traceable event linked to the full LLM trace, giving teams the audit trail they need to demonstrate that their agent behaved within policy.

AI Guard also provides an aggregate view of evaluations in the Signals tab. Instead of requiring teams to review raw evaluation logs one by one, Datadog groups and ranks events that warrant investigation. This helps security and platform teams prioritize high-signal activity across agents and environments.

Protect agentic workflows in production

AI Guard for AWS Strands Agents helps teams evaluate agent behavior at the points where runtime risk appears: prompts, responses, tool calls, and tool results. By using the Strands hook system, the plugin brings AI Guard into the agent loop while keeping policy configuration separate from application logic. The result is a centralized way to observe, govern, and block unsafe agent behavior while preserving the trace context that teams need for investigation.

To get started, read the Datadog AI Guard documentation and the AWS AI Guard Strands plugin documentation. If you’re interested in trying AI Guard, sign up for the AI Guard Limited Availability Program.

If you’re new to Datadog, sign up for a 14-day free trial.

Original source

Automatically triage SAST findings with full repository context by using agentic evaluation

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.

As part of Datadog Static Code Analysis in Datadog Code Security, Bits AI already helps teams prioritize findings by assessing whether a finding is likely to be a true positive or a false positive and providing a short explanation. Many findings, however, can’t be evaluated from the flagged file alone. A function might appear vulnerable until you discover that every caller validates its inputs or that an authorization check runs elsewhere in the request path. Other findings depend on team-specific conventions that aren’t visible in the code at all.

To help teams distinguish real vulnerabilities from false positives when evidence exists outside the flagged file, Datadog Static Code Analysis includes agentic evaluation and Bits Memories. Agentic evaluation brings repository-wide analysis to findings, and Bits Memories incorporates your organization’s knowledge into false positive assessments. In this post, we’ll explore how these capabilities help you:

• Automatically triage findings with full repository context
• Capture your team’s security conventions
• Combine repository-wide evidence with organizational knowledge

For example, consider a server-side request forgery (SSRF) finding generated during a scan. The following code shows the function that triggered the finding:

func FetchURL(ctx context.Context, target string) (*http.Response, error) {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, target, nil)
    if err != nil {
        return nil, err
    }
    return http.DefaultClient.Do(req)
}

Viewed in isolation, the function appears risky because it accepts a user-supplied URL and passes it directly to an HTTP client. However, the flagged function doesn’t tell the whole story. To understand whether the finding represents a genuine vulnerability, you need to know how the function is used in the application. The following code shows one of the function’s callers:

func HandlePreview(w http.ResponseWriter, r *http.Request) {
    target := r.URL.Query().Get("url")
    if !allowlist.Valid(target) {
        http.Error(w, "blocked", http.StatusBadRequest)
        return
    }
    FetchURL(r.Context(), target)
}

The caller in this example validates the URL against an allowlist before invoking the function. Bits follows those relationships automatically with agentic evaluation, inspecting callers and related code paths before assessing the finding. If every reachable caller validates the input, the evidence points toward a false positive. If a caller passes user input directly to the function, the evidence indicates a genuine vulnerability.

Repository context also improves the explanations that accompany findings. Instead of providing only generic rationale, Bits references the specific validators, wrappers, or callers that informed its assessment. Security teams can review the reasoning and understand why a finding was classified as a likely true positive or false positive.

Agentic evaluation operates within controlled boundaries. Bits receives read-only access to repository contents and can inspect code, search files, and gather evidence. It cannot modify files, execute code, or access resources outside the repository. Bits treats what it reads as untrusted evidence, not instructions. All evaluations also pass through Datadog AI Guard, which provides defense against prompt injection attempts.

Capture your team’s security conventions with Bits Memories

Exploring a repository helps when the missing context lives in code, but some triage decisions depend on organizational knowledge that isn’t visible in the repository. One team might treat an outbound URL as safe after it passes through a central allowlist, while another team might require validation closer to the call site. General-purpose models don’t know those conventions, which makes it difficult to assess findings accurately.

Bits Memories brings organizational context for more accurate assessments. Memories are scoped per rule in your organization and apply across all of your repositories. A memory for one rule has no effect on how Bits evaluates other rules. Within that scope, Bits draws on two sources of information. The first source is your organization’s history of false positive reports for that specific rule. When you repeatedly identify a recurring pattern as a false positive, Bits uses that history as additional context during future evaluations.

The second source of information for Bits Memories is custom context that your team provides in free-text notes. You can document framework-specific behavior, internal validation libraries, authorization patterns, review guidance, and other information that isn’t visible in the repository. A custom note might explain that all requests pass through a shared authorization layer, or that a proprietary validation function implements a company-wide security standard.

The memories that you create through false positive reports and custom context serve as evidence, not a suppression list. A past report or custom note does not silence every future finding for that rule. Bits evaluates each finding and determines whether the prior context applies. If the pattern matches previous assessments, the memory contributes additional evidence. If the pattern differs from past examples, Bits relies on current evidence instead of the memory.

Scans also reflect the latest organizational knowledge. When teams submit false positive reports or update custom context, subsequent evaluations incorporate that new data rather than relying on outdated verdicts or information.

Combine repository-wide evidence with your team’s knowledge

Agentic evaluation and Bits Memories are designed to complement each other. When used in tandem, they give Bits a more complete picture of a finding to help it reach an accurate verdict.

For example, consider the SSRF finding that we highlighted previously. Agentic evaluation can determine that every caller validates the URL before invoking the flagged function. Bits Memories can add historical context showing that your security team has repeatedly classified findings as false positives when that same validation pattern is present. The combination of evidence provides a more conclusive assessment than either source alone.

Human reviewers don’t assess findings in a vacuum. They trace data paths, consult framework conventions, and draw on institutional memory. By combining repository-wide evidence with organizational knowledge, Bits can bring that same depth of reasoning to findings.

Get started with agentic evaluation and Bits Memories

Agentic evaluation and Bits Memories make SAST triage more accurate by extending Bits’s view beyond a single file to the full repository and your team’s accumulated knowledge. Together, these capabilities help reduce false positives, provide more trustworthy explanations, and direct developer attention toward findings that deserve investigation. To learn more, read the documentation about AI enhancements in Static Code Analysis and the blog post about our open source AI-native SAST.

If you’re new to Datadog, you can sign up for a 14-day free trial to get started with Datadog Code Security and Static Code Analysis.

Original source

Apple’s platform ecosystem is evolving as developers build production applications for watchOS and visionOS. Whether it’s a fitness app on Apple Watch or an immersive spatial computing experience on Apple Vision Pro, these platforms have moved beyond the experimental phase to support real users. Despite this growth in adoption, teams lack visibility into how their apps behave on these devices. Unlike iOS, where mature observability tooling exists, watchOS and visionOS have remained largely unobserved: Crashes go undiagnosed, errors surface without context, and sessions pass without insight into user experience.

Datadog Real User Monitoring (RUM) fills the visibility gap by supporting watchOS and visionOS in all regions, including GovCloud. Datadog has extended the existing dd-sdk-ios package to compile, run, and be fully tested on both platforms, so no separate SDK is required.

In this post, we’ll explore how RUM brings Apple Watch and Apple Vision Pro apps the same crash reporting, error tracking, and session-level observability that iOS teams rely on.

Monitor crashes and errors in watchOS and visionOS apps with deobfuscated stack traces

When issues occur on watchOS and visionOS apps, teams often have limited information to work with. Determining the source of a crash, understanding the impact of a runtime error, and reconstructing the user journey that led to a failure can require piecing together information from multiple sources. Datadog RUM brings those signals together in a single view through crash reporting and error tracking with fully deobfuscated stack traces, as well as session tracking:

• Crash reporting automatically captures crashes on both platforms. This capability is especially valuable on watchOS, where constrained hardware resources and a different application life cycle can make failures more difficult to reproduce and investigate. Rather than working from a string of memory addresses, you get a human-readable trace that points to the exact line of code that failed.
• Error tracking identifies runtime errors across WatchKit and SwiftUI watchOS apps, as well as immersive and windowed visionOS experiences. By correlating these errors with application context, you can triage and resolve issues more quickly.
• Session tracking shows how users interact with Apple Watch and Apple Vision Pro apps. Session-level data helps you understand real usage patterns, identify friction points, and measure the impact of releases.

Deobfuscation is powered by Datadog’s symbolication platform, which automatically collects watchOS and visionOS system symbols. The process to upload your application’s dSYM files is the same as for iOS, so crash reports and runtime errors include readable stack traces with no additional configuration beyond what iOS teams already do.

Start monitoring your watchOS and visionOS apps with Datadog RUM

Datadog RUM for watchOS and visionOS gives you the same level of visibility into your Apple Watch and Apple Vision Pro apps that you get for iOS apps. You can monitor crashes, track errors, and analyze user sessions by using the same workflows that you already have in place. Stack traces are fully deobfuscated, and you don’t need to adopt or maintain a separate SDK. For setup instructions, read the RUM documentation for Apple platform monitoring.

If you don’t already have a Datadog account, you can sign up for a 14-day free trial to get started monitoring your watchOS and visionOS apps.

Original source