Computer Vision for Security: How Real-Time Threat Detection Works in Production

Most security camera footage is watched by nobody. The industry's dirty secret is that "monitoring" usually means "recording evidence for after the incident." Real-time computer vision changes that — but the gap between a vision model that works in a paper and one that works on live camera streams is enormous.

I spent two years closing that gap building Sequence, the computer vision platform behind Zorel.ai's enterprise security products. Here's how a production threat detection pipeline actually works.

The pipeline: from pixels to decisions

A production system is a chain of stages, each with its own failure modes:

1. Person detection and pose estimation

The first stage finds people and reduces each one to a skeleton — typically 17 keypoints per person per frame. Working with keypoints instead of raw pixels makes everything downstream faster, more private, and more robust to lighting and camera differences.

The unglamorous details matter here: skeleton normalization (bodies at different distances and angles must map to comparable representations) and handling missing keypoints when someone is partially occluded.

2. Temporal modeling: actions live in time, not frames

A single frame can't tell you whether a raised arm is a wave or a strike. Activity recognition requires reasoning over sequences of frames.

This is where temporal transformers come in — models (we worked extensively with MMAction2) that attend over a window of pose sequences to classify what a body is actually doing. The engineering decisions that dominated our accuracy weren't exotic: pooling strategies, ragged vs. padded tensor handling, and how much temporal context to retain.

3. Event scoring and classification

Raw model output is not a security decision. A production system layers on:

• Event scoring — how confident, how severe, how urgent
• Context rules — a person running is normal in a gym, anomalous in a vault
• Deduplication — one incident seen by three cameras is one incident

4. The feedback loop

Every alert an operator confirms or dismisses is training data. Production systems that improve have a pipeline for capturing those judgments, versioning datasets, and retraining on a schedule. Ours did — and that feedback loop mattered more to long-term accuracy than any architecture choice.

The part nobody talks about: dataset engineering

Public datasets (we evaluated SPHAR and LIRIS Human Activities, among others) are a starting point, but real deployments face a distribution the papers never saw: your cameras, your lighting, your behaviors of interest.

Most of the project's accuracy gains came from dataset work — annotation strategy, missing-data handling, quality evaluation, and versioning. If you take one thing from this post: in applied computer vision, the dataset is the product.

What the numbers looked like

In production across finance and enterprise networks, the system delivered an 87% reduction in breach response time with a 92.3% true-positive rate — worth roughly $4.6M in prevented risk exposure. Those numbers came from the whole pipeline: detection, temporal modeling, scoring, and the feedback loop working together.

Frequently asked questions

Do we need special cameras?

Usually no. Modern pipelines work on standard IP camera streams; the compute happens on GPUs at the edge or in the cloud, depending on latency requirements.

What about privacy?

Pose-based approaches help: once video is reduced to skeletons, you're analyzing movement, not identity. Deployments should still be designed against local privacy regulation from day one.

How long does a system like this take to deploy?

A single-site pilot with real cameras and real alerts: weeks. Full multi-site rollout with feedback loops: a quarter. Anyone quoting a multi-year roadmap is selling a research project.

---

Have a monitoring, safety, or automation problem that cameras already see but nobody watches? Walk through the Sequence case study or book a scope call.