Designing SentinelMesh: Architecture for an AI-Powered IoT IDS
IoT devices are everywhere now: cameras, thermostats, smart plugs, TVs, door locks, sensors, and gateways. The problem is that many of these devices are small, noisy, difficult to patch, and usually not monitored like normal laptops or servers.
That makes IoT networks a good target for attackers.
For this project, I built SentinelMesh Edge, a prototype AI-powered intrusion detection system for IoT environments. The goal was simple:
Can we use machine learning at the network edge to detect malicious IoT traffic quickly enough to be useful?
This post is Part 1 of a three-part series. In this first post, I will walk through the system design and explain how the architecture works.
What SentinelMesh is trying to solve
Traditional security tools usually work well for laptops, servers, and cloud workloads. IoT is different.
IoT devices often have limited compute power, inconsistent firmware updates, weak default configurations, and unusual network behavior. A smart camera, for example, does not behave like a laptop. A thermostat does not behave like a server. So instead of trying to install agents on every device, SentinelMesh watches the network traffic those devices generate.
The basic idea is:
- IoT devices send telemetry and network-flow data.
- An edge gateway preprocesses that traffic.
- AI models classify suspicious flows and detect rate anomalies.
- Alerts are sent to a dashboard or SIEM.
- Long-term data is stored for analysis, model retraining, and reporting.
Dataset behind the project
SentinelMesh was designed around the CIC-IoT-2023 dataset. The dataset includes network-flow telemetry from 105 real IoT device types, labeled across 34 attack categories plus benign traffic. For this build, I used a balanced subset of 240,000 records: 120,000 benign and 120,000 attack flows.
The features include values such as:
- Header length
- Protocol type
- Time to live
- Flow rate
- Inter-arrival time
- Packet size statistics
- TCP flags
- Protocol indicators
- Attack label
The goal was not just to train a model in a notebook. The goal was to design the system as if it could eventually run in a real IoT network.
Layer 1: Device layer
The device layer represents the IoT endpoints. In my design, this includes devices such as:
- IP cameras
- Smart plugs
- Smart thermostats
- Smart TVs
- Smart door locks
- Gateway routers
These devices sit on an isolated IoT VLAN instead of sharing the same network segment as normal corporate systems.
Example:
IoT VLAN: 192.168.10.0/24
Traffic: IoT devices only
Purpose: Limit blast radius if a device is compromised
This matters because segmentation is one of the most practical things you can do in IoT security. If a camera gets compromised, it should not automatically have a path to internal business systems.
Layer 2: Edge processing layer
The edge processing layer is the heart of SentinelMesh.
This is where the AI models run locally, close to the devices. Instead of sending every packet or flow to the cloud first, the edge gateway performs local inference and generates alerts quickly.
The edge layer includes:
- MQTT broker
- Feature preprocessor
- 1D-CNN attack classifier
- LSTM traffic-rate predictor
- Rules engine
- Local database
- Alert generator
The reason for edge inference is latency. In security, speed matters. If detection depends entirely on cloud round trips, the attack may already be spreading by the time the system responds.
Why MQTT?
For IoT communication, SentinelMesh uses an MQTT-style design.
MQTT is lightweight and works well for constrained devices. Devices publish telemetry to topics, and the edge broker receives those messages.
Example topic structure:
sentinelmesh/camera/{device_id}/flow
sentinelmesh/thermostat/{device_id}/flow
sentinelmesh/doorlock/{device_id}/flow
sentinelmesh/alerts/{severity}
This pattern keeps devices decoupled from the ML pipeline. A new device type can publish telemetry without rewriting the entire inference system.
Layer 3: Cloud and analytics layer
The cloud layer is not responsible for first-response detection. It is responsible for storage, dashboards, retraining, and deeper analysis.
In a production-style design, this layer could include:
- Object storage such as AWS S3 or Azure Blob
- Streaming tools such as Kafka or Spark Streaming
- Model registry with MLflow
- Tableau or web dashboards
- SIEM integration
- Weekly or monthly model retraining
The edge handles fast detection. The cloud handles long-term intelligence.
How the pieces connect
The complete SentinelMesh flow looks like this:
IoT Device
↓
MQTT Broker
↓
Feature Preprocessor
↓
CNN Classifier + LSTM Predictor
↓
Decision Fusion Engine
↓
Alert / Dashboard / SIEM
↓
Cloud Storage + Model Retraining
This creates a layered detection strategy. The CNN looks at each flow and asks, “Does this look malicious?” The LSTM watches traffic behavior over time and asks, “Is the rate pattern abnormal?”
That combination is stronger than either model alone.
Practical security design decisions
A few design choices are important:
1. Segment IoT devices
Do not put IoT devices on the same flat network as workstations or sensitive systems.
2. Run inference at the edge
Edge inference reduces detection delay and allows the system to keep operating even if cloud connectivity is degraded.
3. Store locally and in the cloud
The edge gateway can keep short-term local logs. The cloud can store long-term telemetry for analytics and retraining.
4. Treat the MQTT broker as critical infrastructure
The broker is a high-value target. A production design should use TLS, authentication, authorization, and ideally mutual TLS.
5. Retrain models over time
Attack behavior changes. IoT devices change. Models should not be trained once and forgotten.
What comes next
In Part 2, I will move from architecture to model building. Specifically, I will show how I trained a 1D Convolutional Neural Network to classify IoT network flows as benign or attack traffic.
The CNN is the reactive detection engine of SentinelMesh. It takes engineered network-flow features and outputs a threat probability.