
Florentin Labelle

Christophe Papazian
Python AWS Lambda functions are ephemeral and highly distributed, which creates security visibility gaps that traditional perimeter defenses and proxy-based controls struggle to fill. Techniques such as credential stuffing, SQL injection, and server-side request forgery (SSRF) can look like legitimate application traffic, making them difficult to identify without visibility inside the application itself.
To help solve this challenge, Datadog App and API Protection (AAP) now extends full in-process application security monitoring to Python Lambda functions. By integrating directly with your application runtime through Datadog tracing libraries, AAP provides deeper insight into how requests interact with your code. This in-process visibility enables you to detect exploit attempts, correlate them with vulnerable code paths, and respond with higher confidence.
In this post, we’ll explore how AAP helps you:
- Increase visibility in Lambda environments
- Detect successful injection attacks with Exploit Prevention
- Identify and respond to account takeover attempts
Increase visibility in Lambda environments
Traditional approaches to securing serverless applications rely on proxies or external web application firewalls (WAFs) to inspect incoming traffic. Although these approaches can identify known attack patterns, they lack visibility into how requests are processed when they reach your application. Without runtime visibility, teams struggle to determine whether an attack succeeded or which part of their code was affected.
Previously, AAP for Lambda used a language-agnostic approach by running a WAF within the Datadog Lambda Extension. As shown in the following diagram, this proxy-based model inspects requests before they reach the function but can’t observe execution within the runtime itself.

AAP now integrates directly into the Python runtime by using the Datadog tracing library. This enhancement shifts security monitoring into the application process, where AAP can observe function calls, the request context, and execution paths in real time.

This architectural change aligns how AAP operates in serverless environments with its implementation in other environments by embedding the same security engine in the application runtime. As a result, teams can adopt new detection capabilities more quickly and gain consistent visibility across their services. The change also enables AAP to capture application-level context, such as user actions and function calls, that external tools cannot access.
Detect successful injection attacks with Exploit Prevention
Detecting attack attempts is useful, but understanding whether they succeeded is critical. Many injection attacks become meaningful only when untrusted input reaches vulnerable code during execution. Network-layer monitoring can’t determine whether that condition has occurred.
Exploit Prevention, a feature of AAP, brings runtime application self-protection (RASP) capabilities to Python Lambda functions. Exploit Prevention uses instrumentation from the Datadog tracing library to analyze how untrusted data flows through your application and determine whether an exploit has occurred.
This approach enables detection of common injection attacks, including SSRF, shell injection, SQL injection, and local file inclusion. Instead of relying solely on request signatures, Exploit Prevention correlates incoming request data with function arguments and execution behavior. As a result, it can distinguish between benign input and true exploitation attempts.
Because Exploit Prevention ties detections to execution context, security signals include detailed stack traces that show exactly where and how the exploit occurred. These traces make it easier to investigate incidents, prioritize remediation, and reduce false positives that can arise from surface-level inspection.

Identify and respond to account takeover attempts
Account takeover (ATO) attacks often unfold across multiple requests and sessions, making them difficult to detect with stateless monitoring. In serverless environments, this challenge is amplified because each invocation is isolated and short-lived.
Datadog’s Lambda library for Python enables your application to emit authentication-related events, such as user.login and session.create, directly from your business logic. By capturing these signals, AAP can analyze authentication behavior across invocations and detect suspicious patterns, including brute force attacks, credential stuffing, and distributed credential stuffing campaigns. These detections rely on indicators such as login velocity anomalies, repeated failures, and activity across multiple IP addresses.

Because these signals are enriched with application context, your teams can quickly identify affected users and investigate attacker behavior. This context also enables automated responses, such as blocking malicious IP addresses or enforcing additional authentication steps.
Start monitoring threats in your Python Lambda functions
By bringing in-process security monitoring to Python Lambda functions, Datadog AAP gives you the visibility that you need to detect real threats, not just suspicious traffic. You can observe how requests interact with your code, identify successful exploits, and correlate authentication activity across distributed serverless workloads.
To get started, enable AAP on your instrumented Lambda functions by setting DD_APPSEC_ENABLED=true. For detailed setup instructions, read our documentation for securing Python Lambda functions.
If you’re new to Datadog, you can sign up for a 14-day free trial to start monitoring threats across your Python Lambda functions.





