Cyber deception.
Explainable threat evidence.

Abstract

The AI Deception System investigates how interactions with decoy resources can be converted into intelligible security evidence. The system accepts bounded synthetic session features, applies a trained Isolation Forest and explicit detection rules, and records the resulting event for analyst review. A canary interaction produces a high-confidence signal linked to its decoy. The hosted research implementation uses on-demand execution and a persistent evidence store, allowing an evaluator to demonstrate ingestion, scoring, review and export without operating a public honeypot. This report separates implemented functions, synthetic evidence and future sensor integration. It makes no claim of measured real-world detection accuracy.

1. Problem and scope

Traditional logs are difficult to interpret in isolation. A decoy resource supplies context: interaction with an intentionally unused resource can warrant attention even when a statistical model is uncertain. The engineering problem is to preserve that context from ingestion through scoring and review, rather than merely animate a security dashboard.

The student repository is AI-Deception-System; the portfolio previously used SafeCity AI and CyberDecoy AI. The established safecity-ai URL is retained for link compatibility. The subject is cybersecurity deception, not city surveillance.

2. System architecture

The browser renders the interface and sends bounded requests. An AWS Lambda function computes inference and applies domain rules. DynamoDB stores each laboratory's events and decoy inventory. Conditional version writes prevent one concurrent update from silently overwriting another. Canary interaction and its resulting security event are written in a single state update.

The original local reference uses Python, FastAPI, scikit-learn and SQLite. The hosted edition exports the fitted tree structure and evaluates it in JavaScript on the server. It does not replace the forest with a random number or an animation. Static pages continue to use the existing company CloudFront distribution.

3. Features and training data

The reference trains 160 isolation trees with seed 42 and contamination 0.08 on 350 generated routine examples plus five constructed suspicious examples. These are synthetic training data. Contamination is a model setting, not an observed attack prevalence. There is no independently labelled real-world test set in this release.

4. Inference and mathematics

Isolation Forest isolates unusual observations through random feature splits. Shorter expected path lengths indicate unusual feature combinations. For a node containing n observations, the path adjustment is c(n) = 2[ln(n−1) + γ] − 2(n−1)/n for n > 2; c(2)=1 and c(1)=0. The anomaly score uses 2^{−E[h(x)]/c(n)}. The exported evaluator preserves the reference forest's offset and decision function.

The displayed anomaly indicator is clip(50 − 220 × decision, 0, 100). This transformed indicator is not a probability. The rule component caps contributions from failed logins, command count, duration and suspicious commands at 34, 20, 14 and 32 respectively. The initial hybrid score is 0.72 × rule score + 0.28 × anomaly indicator.

Strong evidence establishes explicit floors: at least 40 failed logins gives a minimum score of 65; at least four suspicious commands gives 60; a canary interaction gives 85. Severity thresholds are Low below 30, Medium from 30, High from 60 and Critical from 80. These are transparent research rules requiring future calibration.

5. Honeypots and canaries

The implemented honeypot simulator creates routine, repeated-login, reconnaissance and prolonged-session events using documentation-only IP ranges. It never scans, authenticates to or exploits an external system. The simulator exists to exercise the complete detection pipeline.

Canary records are harmless named decoys. A controlled trigger produces a linked security event and increments the token counter. Future real sensors should provide signed, deduplicated events with provenance, observed timestamps and redacted session features. A real Cowrie service is not deployed by this release.

6. Persistent evidence and access

Each visitor receives a cryptographically random bearer capability. Only its hash indexes the session in the evidence store. The browser retains the capability locally; possession grants access to that session. This provides isolated demonstration records without pretending to be a student account or enterprise identity system.

Sessions expire after seven days; records have a 200-event and 20-decoy bound. The API rejects expired sessions even before storage expiry removes them. An export contains event features, scores, rule explanations, model version and review state. Public demonstration data must be synthetic; sensitive network or personal data should not be uploaded.

7. Evaluation procedure

Use the accompanying operator guide and eight-event dataset. Compare the saved event total before and after import, trigger a registered canary, inspect its Critical classification, save an analyst observation and reload the workspace. Retain the downloaded JSON as the demonstration evidence.

The local Python implementation passed 11 backend tests and seven live workflow checks during the preceding rebuild. The exported server model is compared against the reference on 40 deterministic vectors, including anomaly labels, severity and score tolerance. These are software parity tests; they are not a substitute for precision, recall, false-positive or latency benchmarks on real traffic.

8. Future expansion

1. Authenticated institutional workspaces, reviewer roles and revocable sessions.
2. Isolated Cowrie sensors with signed ingestion, deduplication and command redaction.
3. A curated, consented dataset and a time-separated train/validation/test split.
4. Measured precision, recall, false positives per hour and score calibration.
5. Versioned model registry, retraining review and drift observation.
6. Append-only investigation history, case ownership and evidence retention policies.
7. Replay of chronological sessions and comparison against rule-only baselines.

Each expansion requires separate engineering and validation. It is not represented as an existing feature.

9. Company stewardship and attribution

This project is developed and presented under Chatake Innoworks Private Limited, through MindForgeAI. Project sponsorship, stewardship and rights are governed by the applicable company–student agreements. Company ownership claims do not override third-party licences or erase student authorship.

Student contributors: Shweta Suresh Hitanalli, Abhilasha Dilip Wankhare, Praniti Lingraj Nandure and Trupti Sunil Waychal. The preserved student source is AI-Deception-System, reviewed at commit 1f2458773859ab38b5d17e83cd35482410f1ed66. The local research rebuild and hosted engineering adaptation are retained separately from that history.

Company website · MindForgeAI · Team portfolio and project documents

Technical references

scikit-learn IsolationForest reference
RFC 5737: IPv4 documentation address blocks
Cowrie documentation
DynamoDB item operations