Sentinel Anti-Theft: Real-Time Device Tracking with AI Anomaly Detection

A stolen laptop is a race: the thief's head start against your ability to find the machine, lock it, and identify who took it. Sentinel Anti-Theft is an open-source system built to win that race — a real-time device-tracking platform with an AI anomaly-detection engine and a stealth desktop agent capable of remote locking and silent camera capture. It combines a NestJS WebSocket backend, a FastAPI machine-learning microservice, and a Tauri/Rust desktop agent into one coordinated platform.

The repository (github.com/Shivay00001/sentinel-anti-theft) is a multi-component monorepo: backend/, ai-service/, desktop/, with mobile clients and a web dashboard referenced as submodule links. I verified the backend, AI engine, and desktop agent code directly. This article says exactly what is working, what is a skeleton, and what is still a stub — because an anti-theft system that oversells itself is worse than none at all.

The problem it solves

Consumer device tracking (Find My, Google's Find My Device) is tied to platform accounts, limited in enterprise control, and thin on anomaly intelligence. Sentinel's premise is a self-hosted, extensible alternative: devices stream live GPS over WebSockets to a backend you control, a machine-learning engine watches the movement pattern for anomalies (a device moving while it reports itself locked), and a desktop agent executes OS-level responses — lock the workstation, sound an alarm, silently photograph the intruder — on remote command.

The design insight is the anomaly rule: location data alone is a dashboard; location data combined with device state is an alarm. A laptop moving at 2 a.m. while reporting "locked" is a different fact than a laptop moving at 2 p.m. while in use. The AI engine encodes exactly that conjunction.

How it works

1. Backend — NestJS + Socket.IO (backend/)

The backend is a NestJS 11 application (TypeScript) bootstrapping on port 3000. Its core is src/tracking/tracking.gateway.ts, a TrackingGateway decorated with @WebSocketGateway({ cors: true }). Two message handlers do the real work:

@SubscribeMessage('updateLocation')
handleLocationUpdate(
  @MessageBody() data: { deviceId: string; lat: number; lng: number; battery: number },
  @ConnectedSocket() client: Socket,
) {
  this.logger.log(`Location received from ${data.deviceId}: [${data.lat}, ${data.lng}]`);
  this.server.emit(`location-update-${data.deviceId}`, data);
  // Here we would also push this to the AI anomaly detection engine or MongoDB
  return { status: 'success' };
}

@SubscribeMessage('triggerAlarm')
handleTriggerAlarm(@MessageBody() data: { deviceId: string }) {
  this.logger.log(`Alarm trigger requested for ${data.deviceId}`);
  this.server.emit(`command-${data.deviceId}`, { action: 'sound_alarm' });
}

Devices emit updateLocation with device ID, latitude, longitude, and battery; the backend rebroadcasts on a per-device channel (location-update-<deviceId>) that dashboards and the devices themselves subscribe to. A triggerAlarm event pushes a { action: 'sound_alarm' } command down to the target device over command-<deviceId>. Connection and disconnection are logged per socket. The comment in the code is refreshingly candid: the hook points where data should be forwarded to the AI engine or a database are marked as future wiring, not pretended into existence.

The backend is a properly tooled TypeScript project: typed ESLint rules, Prettier formatting, Jest unit specs (*.spec.ts), and an e2e suite (test/app.e2e-spec.ts). One wart: backend/dist/ — compiled JavaScript output — is committed to the repository. It is real build output, but committing build artifacts bloats the repo and will drift from source; it belongs in .gitignore.

2. AI engine — FastAPI + scikit-learn (ai-service/main.py)

The anomaly engine is a single-endpoint FastAPI microservice running on Uvicorn, port 8000. The input model is a Pydantic class with exactly the fields the anomaly rule needs:

class LocationData(BaseModel):
    device_id: str
    lat: float
    lng: float
    timestamp: int
    is_locked: bool

POST /analyze appends each point to an in-memory history buffer. With fewer than 10 points it returns {"status": "learning", "anomaly_detected": False} — a deliberate cold-start behavior rather than a confident guess. With 10 or more, it fits scikit-learn's IsolationForest (contamination=0.01) on the last 10 points and predicts the current one; the alert fires only when the point is an outlier and the device reports locked:

is_anomaly = prediction[0] == -1 and data.is_locked

Now the honesty section, which the code itself demands. The source contains the comments "Dummy mock for in-memory historical data tracking (would use DB in production)" and "Very naive implementation of anomaly detection for the skeleton. In reality, this would use a robust Spatio-Temporal model." The model refits on every request against a 10-point window, holds no per-device profiles, and persists nothing. It is a working demonstration of the detection logic — the locked-and-moving conjunction — not a trained security model. The README says the same. Credit where due: many repos would have buried those comments. This one is the specification for what "done" looks like.

3. Desktop agent — Tauri/Rust (desktop/)

The desktop agent is the component closest to real. desktop/src-tauri/src/main.rs is a Tauri application that runs headless — no main window, a background thread listening for remote commands — and exposes two commands:

#[tauri::command]
fn trigger_remote_lock() -> Result<String, String> {
    #[cfg(target_os = "windows")]
    {
        Command::new("rundll32.exe")
            .args(["user32.dll,LockWorkStation"])
            .spawn()...
        Ok("Windows Locked".into())
    }
    #[cfg(target_os = "macos")]
    {
        Command::new("pmset")
            .args(["displaysleepnow"])
            .spawn()...
        Ok("macOS Locked".into())
    }
    ...
}

The remote lock is real OS calls: rundll32.exe user32.dll,LockWorkStation on Windows, pmset displaysleepnow on macOS, with conditional compilation and an explicit "unsupported OS" error elsewhere. The silent webcam capture (capture_intruder_selfie), by contrast, is honest pseudocode — the function returns an "ok" string while its body is a commented recipe naming the nokhwa or escapi crates as the real implementation path. That stub is the one place in the repo where a claimed feature has no implementation at all, and the code marks it as such.

What's referenced but not verified

The tree lists mobile and web-dashboard as submodule commit pointers (gitlinks) — the code behind those names was not inspectable in the main tree. The README's architecture describes mobile clients streaming location and a web dashboard subscribing to the per-device channels; until the submodules resolve, treat those as planned surfaces. The mermaid architecture diagram also shows the backend posting each location to the AI engine's /analyze — the code comment marks that forwarding as a hook point, so the end-to-end pipeline (device → backend → AI → alert) is architecturally drawn but not yet wired.

How to run it

Each component runs independently. Backend:

cd backend
npm install
npm run start:dev     # NestJS on port 3000

AI engine:

cd ai-service
pip install -r ../requirements.txt   # fastapi, uvicorn, scikit-learn, pandas, numpy
uvicorn main:app --host 0.0.0.0 --port 8000

Desktop agent (requires the Rust toolchain and Tauri prerequisites):

cd desktop
# Tauri build produces the background daemon

A Dockerfile and docker-compose are present at the repo root for containerizing the backend and AI service together. Clients connect over Socket.IO: emit updateLocation with { deviceId, lat, lng, battery } and listen on location-update-<deviceId>; emit triggerAlarm with { deviceId } to push the alarm command.

Honest status and roadmap

Status: partial prototype with real, working parts. The WebSocket relay is functional, the remote lock on Windows and macOS executes genuine OS calls, and the anomaly-detection logic is implemented and testable — against an in-memory, per-request, naive IsolationForest that the code itself labels a skeleton. The webcam capture is a stub. Mobile clients and the web dashboard are submodule references. The committed dist/ output is a hygiene issue.

The roadmap writes itself from the code comments: (1) implement the silent capture with nokhwa/escapi; (2) replace the in-memory history with per-device persistent profiles and a properly trained model; (3) wire the backend's AI-forwarding and database hook points; (4) resolve the mobile and dashboard submodules into inspectable code; (5) add authentication to the gateway — right now any client can emit alarm commands for any device ID, which is the single most important security gap for a system whose entire job is remote device control; (6) drop dist/ from version control.

Frequently asked questions

Does the remote lock actually work?

Yes — on Windows and macOS, via real OS calls (rundll32.exe user32.dll,LockWorkStation and pmset displaysleepnow). Linux is explicitly unsupported.

Is the AI anomaly detection production-grade?

No, and the code says so. It is a working demonstration of the locked-and-moving rule on a 10-point sliding window with no persistence and no trained per-device model.

Can I track a phone with this?

The mobile clients are referenced as submodules; the backend protocol (Socket.IO events) is documented and any client can implement it. The verified code covers desktop.

Is there authentication?

Not in the verified code — a noted gap, and the top priority before any real deployment.

The bottom line

Sentinel Anti-Theft is an unusually honest security prototype: a working WebSocket tracking backend, a real remote-lock agent, and an anomaly engine that demonstrates its core detection rule while labeling its own naivety in comments. It is not a finished product, and it never pretends to be. As a foundation for a self-hosted device-security platform — with auth, persistent models, and the camera stub implemented — it is a credible start, and the candor in the code is the best reason to take it seriously.

For teams evaluating it as a base to build on, the architecture's cleanest property is its decoupling: the backend, the AI engine, and the device agent communicate over documented protocols (Socket.IO events and a single REST endpoint), so each component can be replaced or upgraded independently. That is the shape of a system designed to grow — and the comments marking exactly where the growth should happen are a roadmap written by someone who already knows the way.

Source: verified against the public repository github.com/Shivay00001/sentinel-anti-theft — tracking gateway, AI engine, and desktop agent source read directly. Submodule contents were not inspectable.