Detection Engine
The engine writes the detection, runs the exploit, and throws away the noise
Field pentesters and threat researchers feed the same engine. It turns what they break into checks that run against every customer, and it drops the findings it cannot prove.
412 scanner alerts dropped for every 9 promoted, across the 2026 cohort.
Field pentesters
Shadow API found
S3 bucket leaked
IAM over-privileged
Threat research
New prompt injection
SQLi bypass found
SSRF in an AI SaaS
Osprey detection engine
Swept 1,190 endpoints and 3 clouds for 138 new detections
New prompt-injection class written, tested and shipped in 6 hours
412 scanner alerts dropped, 9 promoted with a confirmed exploit
How a detection gets built
01
A tester breaks something
A pentester on a live engagement finds a class of bug that is not in the catalogue yet. They write it up with the exploit attached.
02
The engine generalises it
The finding becomes a detection: the request shape, the signals that confirm it, and the conditions under which it is a false alarm.
03
It runs against everyone
The detection ships to every customer whose surface can be reached by it, usually inside a day, and back-runs against historical scans.
04
Noise gets thrown away
Anything the engine cannot prove by replaying the exploit never reaches a queue. That is where 412 out of every 421 alerts go.
Why the queue stays short enough to clear
Detections come from real engagements
Every check in the catalogue started as something a human broke on a live target, not as a pattern lifted from a public CVE feed.
Six hours from finding to fleet
The prompt-injection class found on a Tuesday morning was running against every customer before the end of that day.
Proof gates the queue
A detection only files a finding when the exploit replays successfully. Everything else is logged for research and never shown to you.
Correlation across surfaces
App, API and cloud findings share one graph, so three separate symptoms get reported as the single attack path they actually are.
Back-running on history
New detections re-run against your previous scans, so a class found this month can surface a bug that shipped last quarter.
Blast radius over CVSS
Severity is computed from what the finding actually reaches in your environment, not from a score written by someone who has never seen it.
138
New detections shipped this quarter
6 hours
Median time from finding to fleet
412 : 9
Alerts dropped for every one promoted
What people ask about the engine
Is this just an LLM writing scan rules?
No. A human finds and proves the bug first. The engine generalises the finding into a detection, decides where it can apply, and gates it behind a replay of the exploit.
How often does the catalogue change?
Continuously. 138 new detections shipped in the last quarter, and the median time from a tester proving something to it running against every customer is six hours.
What happens to findings you cannot prove?
They never reach you. They go into a research queue where they either become a working detection later or get dropped. Your queue only ever holds things that replayed.
Does it back-run against old scans?
Yes. When a detection ships, it re-runs against your scan history, so a class of bug discovered this month can surface something that shipped a quarter ago.
Can we see why a finding was ranked critical?
Every finding carries the path that produced its rank: what it reaches, whether it needs authentication, and which other findings it chains with.