How Juno closes false positive investigations in 90 seconds.
GuardDuty flags unauthorized access on one of your IAM users.
You stop what you're doing and start digging through CloudTrail, IAM activity, and VPC Flow Logs to trace the IP and API calls. Two hours later you finally piece it together. Instead of being an attack, it was just a false positive caused by an IP that should never have been on your threat list.
Unfortunately, this kind of investigation is common. The 2026 Microsoft–Omdia State of the SOC report found that 46% of security alerts turn out to be false positives. The average organization receives around 1,000 alerts per day, and large enterprise SOCs often see more than 3,000, with each alert taking roughly 20 to 40 minutes to investigate, ~300+ hours a week just to confirm that nothing happened.
We typed one sentence into Juno and walked away. Ninety seconds later, it was done.
“Hey Juno, GuardDuty just flagged an unauthorized access alert on one of our IAM users. Investigate.”
Juno generated its own investigation plan and started working: seven steps, eight SQL queries across four different data sources.
First, Juno queried all unauthorized access findings from the past seven days.
50+ alerts. All from 18.208.42.89. All targeting instance i-0eb2c85b47622cc0f. All triggered by the same custom threat list.
This is where a manual investigation turns into a multi-tab grind which Juno effortlessly handled by running three queries in parallel.
Every API call from the flagged IP was a standard SSM agent operation: UpdateInstanceInformation, PutInventory, PutComplianceItems. The user agent confirmed it: amazon-ssm-agent/3.3.3050.0. No reconnaissance, lateral movement or data access. Just a machine running its scheduled tasks.
Juno didn't just look at the flagged IP in isolation. Without being told to, it pulled activity from every IP using the same SSM role over the past seven days and compared them.
Five IPs. Same operations. Same frequency. Same user agent. The flagged IP logged 5,904 events. Its peers: 5,881 to 5,919. The only difference was that 18.208.42.89 was on the threat list and the others weren't.
This is the kind of analysis that takes significant time to assemble manually. Identify the peer set, write the queries, aggregate the results, compare.
Juno also pulled the hourly activity timeline for the flagged IP.
Flat. ~32 API calls per hour, 24/7, for over 35 hours. Juno learned that this was automated agent traffic. A compromised credential wouldn't be this consistent.
IP 18.208.42.89 is the public IP of EC2 instance i-0eb2c85b47622cc0f. It was incorrectly added to a custom GuardDuty threat list named threatip. Every alert it generated (20+ in the past 24 hours alone) was legitimate SSM agent traffic being flagged as malicious. Juno classified this incident as false positive.
Not only that, but Juno provided the fix: remove the IP from the threat list, archive the false positive findings, and implement a review process before adding IPs to custom lists. It even included the AWS CLI commands to do it.
Instead of retrieving pre-computed answers, Juno investigates.
Eight SQL queries across four data sources: GuardDuty findings, CloudTrail events, IAM roles, EC2 instance metadata. Parallel queries, along with a behavioral comparison Juno decided to run on its own.
We at Uptycs call this Dynamic Reasoning. Juno generates an investigation plan, tests hypotheses, adapts based on what it finds, and follows the evidence wherever it leads.
But speed without proof is just a faster black box. Every query Juno ran, every log it cited, every hypothesis it tested and ruled out, all of it is visible in the Glass Box view. The analyst doesn't have to trust Juno's conclusion. They can verify every step.