Stream now collects and analyzes full API traffic via our eBPF sensor and cloud-native log ingestion, with threat detection running across all of it.
Today we're excited to announce API log collection as a new capability in the Stream platform, giving security teams complete visibility into application-layer activity across their cloud and hybrid environments, with Stream's threat detection engine running on all of it.
We built this because the API layer has become the primary attack surface in modern cloud environments, and it's still the most under-monitored one. Flow logs tell you traffic metadata. Endpoint agents see processes, not payloads. API gateways and Firewalls capture entry-point requests but miss everything happening inside the cluster. And none of that was built with AI workloads in mind, where the most important signal isn't the status code, it's what was actually in the request body.
Stream now closes that gap, from the load balancer all the way down to the kernel socket.
We've designed the collection layer to give teams flexibility. You can go deep with kernel-level interception using the Stream eBPF sensor, pull in managed log sources from your cloud provider, or use both together for complete coverage.
The Stream Agent intercepts HTTP and gRPC traffic at the kernel socket layer, no proxies, no code changes, no sidecars required. It runs on both Kubernetes pods and VM workloads, capturing full request data. Payload collection is customer-controlled: you decide what gets captured.
Stream also ingests access logs directly from your managed infrastructure: AWS ALB and API Gateway, GCP Cloud Load Balancing, and Azure Application Gateway. This requires no additional agents and gives you instant visibility across all managed entry points without touching your workload configuration.
Both paths feed into the same CloudTwin model, so every event is automatically enriched with identity context, resource relationships, and the live topology of your environment.
For most API traffic, payload capture lets you answer the hard questions during investigations: what data was in the request, what did the service return, was there anything in the body that a status code would never expose?
But the real differentiation is what this unlocks for AI workloads. When your services call Amazon Bedrock, the Anthropic API, or any other LLM backend, enabling full payload collection gives you visibility into exactly what was sent and received, the actual prompt content, system instructions, MCP tool invocations, tool parameters, and model responses. In case this is enabled stream baess lines workloads with Tools and MCPs usage for each application.
Without payload visibility, this request is invisible as a threat. With it, Stream can detect the instruction, correlate it with the identity and permissions of the calling workload, and trace what happened next, all within the context of CloudTwin.
With API log collection enabled, Stream gives you visibility into:
Visibility alone doesn't protect you. Stream runs its full detection engine across every collected API event, the same engine that operates over your cloud posture data, identity activity, and runtime behavior.
That means three detection layers running in parallel:
Every alert surfaces with the full CloudTwin context attached: the complete identity chain, the resource graph, what the affected workload can reach, and what happened downstream. A suspicious Bedrock call isn't an isolated event, it's a complete picture of the attack path.
API visibility is only useful if it covers the environments where your workloads actually live. Stream operates uniformly across Kubernetes and VMs, on AWS, GCP, Azure, and VMware — with the same detection model and the same CloudTwin correlation across all of them.
Whether you're running a managed EKS cluster, legacy vSphere VMs, or a hybrid mix of both, Stream sees the same application-layer activity and treats it as a single unified environment. That's especially important for teams that have expanded beyond pure cloud-native: the eBPF sensor runs on vSphere VMs too, and NSX distributed firewall logs feed into the same detection pipeline.
Stream's core thesis has always been that defenders have the home-team advantage. The attack happens in your environment, your API topology, your identity graph, your service call patterns. An attacker has to discover all of that from scratch. You already know it.
CloudTwin turns that knowledge into a detection surface that no attacker can anticipate. API visibility completes the picture, because the most dangerous activity in modern cloud attacks isn't in your SIEM or your posture score. It's in the payloads moving through your services, and in the instructions your AI agents are being given.
Now you can see them.
API log collection is available now. Reach out to your account team to enable it, or request a demo to see it in action against your own environment.
Stream Security is an AI Detection & Response (AI DR) company built for the era of AI-driven environments across cloud, on-prem, and SaaS. As AI agents operate with real permissions and attackers move at machine speed, Stream enables security teams to keep pace by continuously computing a real-time, deterministic model of their entire environment. Powered by its CloudTwin® technology, Stream instantly understands the full impact of every action across identities, permissions, networks, and resources, allowing organizations to detect, prioritize, and safely respond to threats before they propagate. This transforms security from reactive detection into a true control plane for modern infrastructure.
.png)
