From Detection to Action: Introducing Real-Time Response using eBPF agents

When seconds matter, detection alone isn't enough.

Today we're announcing an expansion of Stream.Security's response capabilities: Workload response Actions - the ability to contain threats inside workloads directly from the investigation workflow, executed in real time by the same agents that detect them.

Security teams have long faced a frustrating gap between knowing about a threat and doing something about it. An alert fires. An analyst triages. A ticket is filed. Someone SSHs into a node. Minutes - sometimes hours - pass before containment begins. Attackers don't wait.

Response Actions close that gap.

‍

What It Does

From the Stream.Security Investigator, analysts can now take immediate action on any monitored workload - whether it runs on Kubernetes (EKS/GKE/AKS), Amazon ECS, or bare-metal/VM infrastructure. No SSH. No separate tooling. No context switching.

‍

‍

The full action catalog includes:

Process Control

• Kill, suspend, or resume processes by PID - with identity verification to prevent stale-PID mistakes

Network Containment

• Block or unblock IP addresses and CIDR ranges via iptables rules
• Kill active network connections
• Full pod network isolation (and removal) with a dedicated firewall chain
• DNS sinkholing to block command-and-control domains

Container & Pod Operations

• Kill, pause, or unpause containers
• Delete compromised pods

Filesystem

• Quarantine suspicious files (moved to a secure directory with metadata preserved)
• Delete malicious artifacts

Advanced

• Execute custom scripts inside container namespaces for tailored response playbooks
• Interactive container shell for deep forensic investigation

Every action is visible in a live history panel with status tracking, timestamps, and error details - giving the full team visibility into what was done, when, and by whom.

‍

How It Works

Response Actions are executed by the same lightweight eBPF-based agent already deployed for detection. There's no additional software to install, no sidecar to manage, and no new network paths to open.

The architecture is intentionally simple:

1. Analyst or AI Agents trigger an action
2. The backend persists the action with an expiration window and targeting metadata
3. The agent polls and claims the action via authenticated HTTPS - no message bus, no inbound connections to customer infrastructure
4. Execution happens locally on the node, using host-level tools accessed through namespace entry
5. Results flow back to the UI in seconds

Actions are atomically claimed - if multiple agents match, only one executes. Expired or stale actions are automatically swept. The system is distributed, idempotent, and resilient to agent restarts.

Built-In Safety Rails

Giving an agent the power to kill processes and block traffic demands rigorous self-protection. Every action passes through a safety layer before execution:

• Self-protection: The agent will never kill its own process, container, or pod
• Backend protection: IP blocks and DNS sinkholing automatically exclude the Stream.Security backend (resolved dynamically, refreshed every 5 minutes - no hardcoded domains)
• CIDR-aware: Blocking a network range that contains the backend is rejected, not just exact IP matches
• Critical path protection: System directories (/bin, /proc, /sys, /etc/passwd, etc.) cannot be quarantined or deleted
• Process identity verification: PID-based actions verify the process start time to prevent acting on a recycled PID
• Domain validation: DNS blocks reject IPs, localhost, and malformed inputs - only valid FQDNs are accepted

These protections cannot be bypassed by the operator. They are enforced at the agent level, every time.

Why This Matters

Cloud-native environments are ephemeral. A compromised container might be gone before a human finishes reading the alert. Automated detection is necessary, but insufficient - the response has to be equally fast and equally close to the workload.

By embedding response capability directly in the detection agent:

• Mean time to containment drops from minutes to seconds
• No new attack surface - agents poll outbound over HTTPS; no inbound ports, no new credentials
• Full audit trail - every action is tracked with who triggered it, what happened, and when
• No infrastructure changes - the same Helm chart, the same agent binary, one feature flag to enable

‍

Agentic Response

StreamForce and the Stream MCP server enable AI-driven orchestration at machine speed. By exposing eBPF response capabilities as tools that AI agents can use, and capabilities like impact simulation. Each AI agent can assess the expected impact of every potential change on the application, then choose the least disruptive path to execute quarantine or remediation.

‍

Getting Started

Response Actions are available today for all Stream.Security customers running the latest runtime agent. To enable:

1. Update your runtime agent to the latest version
2. Enable the response capability via your deployment configuration
3. Navigate to any workload in the Investigator and open the Response tab

For questions or to schedule a walkthrough, reach out to your Stream.Security account team.

‍

‍