Cloud attacks do not stay within the boundaries of a single security tool. An intrusion can begin with an API request, execute a process inside a Kubernetes workload, modify a file, contact an external host, use a cloud identity, and change cluster state, all as part of the same incident.
But the evidence needed to understand that incident is often scattered across application security tools, cloud audit logs, Kubernetes platforms, network systems, and endpoint telemetry. Analysts are left to collect the pieces, reconstruct the sequence, and determine what actually happened.
This fragmentation also creates a fundamental limitation for AI-assisted investigation. An AI model can summarize the alerts it receives, but it cannot explain activity that exists outside its field of view. Better summaries cannot make up for missing evidence.
Upwind Blue Agent is built on a different premise: an AI investigator needs access to the security objects and events that describe what happened and an architecture capable of evaluating that evidence before reaching a conclusion.
An alert is not an investigation
Cloud alerts are designed to identify suspicious conditions or events: a process was executed, a policy changed, an unusual connection occurred, or a sensitive API was called.
An investigation must go further. Analysts need to determine:
- How the events are connected
- Whether the activity is malicious
- Which resources and identities are involved
- Whether the behavior spread across the environment
- What action the security team should take next
That work cannot be reduced to summarizing one alert at a time.
Upwind’s Auto-Generated Threat Story Investigations correlate related detections into a unified incident narrative. Starting with a Detection or Story, Blue Agent gathers relevant evidence and produces a verdict with an associated confidence level. Depending on what the evidence supports, the activity can be classified as a true positive, false positive, or inconclusive.
That final category matters. Inconclusive is a valid security outcome. A trustworthy investigation system should communicate uncertainty when the evidence does not support a definitive answer—not manufacture confidence from incomplete telemetry.
In the Investigation view, analysts can review the verdict and confidence level alongside the incident timeline, supporting evidence, and remediation guidance. Material claims can be traced to the events and investigative tool activity behind them, giving security teams a reasoned and auditable investigation instead of an opaque paragraph generated from an alert title.
A Broader Evidence Foundation Changes What Blue Can Answer
An AI investigator is only as capable as the evidence it can access. The Blue Agent brings multiple security data sources into one investigation while preserving what each event represents and how it relates to workloads, resources, identities and time.
Runtime Events gives Blue access to process, file and syscalls activity. This allows it to examine what actually executed inside a workload, what changed and how the behavior developed, not only the cloud configuration surrounding it.
Network Events adds ingress, egress, internal and cloud-service flows. The Blue Agent can connect process execution to payload retrieval, communication between production workloads, reconnaissance and access to cloud services.
Kubernetes Audit Logs in Investigation + Custom Rego Detections adds Kubernetes control-plane and admission logs from environments including EKS and GKE. These events help establish which identity created or modified a workload, whether the action came through an expected deployment path and whether cluster state changed before suspicious behavior began. Custom Rego detections apply each organization’s policies and operational context to that activity.
API Security extends the evidence to application-layer events, including method, URI, host, response status, latency and sensitive-data locations. This lets Blue move beyond knowing that two systems communicated to understanding which API operation occurred.
The Investigation view shows why this breadth matters. In the example, the Blue Agent connects a root shell on a production MongoDB host to an external payload download, file modification, Python execution, re-staging on an Elasticsearch node and subsequent network enumeration.
No individual log source explains the full sequence. Blue can reconstruct it because it investigates workload, network, Kubernetes, API and cloud evidence together while retaining the source-level detail behind its verdict.
Blue is an orchestrator, not a single prompt
Broad telemetry is essential, but access to more data alone is not enough. Different evidence domains require different investigative methods.
The Blue Agent uses an orchestrated investigation model. A lead investigation process delegates work to domain-specialized investigators that examine areas such as process and file activity, cloud and Kubernetes events, network behavior, forensic artifacts, and historical baselines.
Their findings are assembled into structured evidence. Claims are evaluated according to their source, severity, and confidence before a verdict is produced. Historical context can also help distinguish behavior that is simply unusual from activity that has been seen and approved before.
This approach addresses a key weakness of monolithic AI analysis. Asking one model to inspect an undifferentiated collection of records makes it difficult to control scope, preserve domain-specific reasoning, or explain how the system reached its conclusion. Specialized investigation paths can gather the right evidence in parallel, then reconcile their findings through a consistent verdict process.
It also creates a more effective division of labor between the Blue Agent and the analyst. Blue handles repetitive evidence collection, correlation, and initial assessment. Analysts can inspect the reasoning, challenge individual claims, and focus their attention where human judgment matters most.
From Manual Invocation to Event-Driven Investigation
Event-Driven Auto-Triggering is currently in beta. It initiates a Blue Agent investigation when a Story is created or updated, rather than requiring the analyst to start the investigation manually.
This is more than a workflow convenience. Manual initiation introduces delay precisely when context is accumulating fastest. By beginning evidence collection as the incident develops, the platform can prepare the narrative, verdict and supporting evidence before an analyst opens the Story—or show that the investigation is still in progress.
The goal is not to remove analysts from incident response. It is to remove the waiting and mechanical correlation that prevent them from applying their expertise quickly.
Agentic Cloud Investigation Begins With Architecture
The value of an AI security investigator depends less on how fluent its response sounds and more on the system behind it.
An effective investigator needs access to the right evidence. It must understand the security boundaries involved, connect changes across applications, workloads, networks, Kubernetes, and cloud infrastructure, and preserve source-level detail. It also needs to distinguish confirmed conclusions from unresolved questions and provide an auditable path from evidence to verdict.
That is the model behind the Upwind Blue Agent. It is not simply a summary layered over a collection of alerts. It is a structured process for gathering domain-specific evidence, reconstructing an incident, and explaining why the available facts support a particular conclusion.
Cloud attacks already cross product boundaries. Cloud investigation should not recreate them.
