New in 1.9.0 · Daily briefing in beta
A digital NOC and SOC, built into every organisation.
Helix’s AI engine takes the first watch over your network. Every night it reviews the last 24 hours and writes down what happened and what to do about it. During the day it answers your questions in plain words. It reads what Helix already measures, and it never changes a router.
The first watch, done for you.
A network operations centre watches whether the network is healthy. A security operations centre watches whether anyone is getting in. Few ISPs have either on staff around the clock: they have an engineer who is also the one answering the phone. The AI engine does the first watch, and hands the decision to a person.
It works from what Helix already measures
Traffic and ports, routing and outages, router logs and logins, console sign-ins, configuration changes, backups and firmware: all collected by the same platform that manages your routers and bills your subscribers. The engine opens no router session to read them, so asking costs your routers nothing.
Code first, AI second
Rules written in code raise the first findings for every organisation, whether or not it uses AI, and each one carries its evidence and an action. The AI writes the briefing on top of them, and anything it found on its own is labelled as not verified by code.
Unread is never quiet
A part of the day that could not be read says so, and the AI is told never to call it quiet. A router Helix does not poll is named as unread rather than reported as fine, because a silent all-clear is the most expensive mistake a watch can make.
The digital NOC: is the network healthy?
A daily briefing for the morning, an assistant for the rest of the day, and the monitoring screens both of them are built on.
The 03:00 briefing
Beta · new in 1.9.0- At 03:00 East Africa Time the engine reviews the 24 hours before, for every active organisation with a live router, and for each router in it.
- It reads traffic against the previous seven days, outages, BGP, OSPF and port events, configuration changes, alerts, router log volume, backups and firmware.
- Findings are grouped as Security, Network, Traffic, Changes, and Backups and firmware, each with its severity in words, the router it concerns, the evidence and the action.
- Each one says whether it is new, still open or resolved since the day before, and the last 14 days are kept.
- The briefing is announced in the console and, for owners and admins who link it, in Telegram. The organisation dashboard shows its critical and high counts.
An assistant that shows its working
In the console and in Telegram- Ask in plain words. It can read fleet health, one router’s detail, firmware, open incidents, backups, recent operations, the busiest interfaces, recent alerts, the VLAN map, bridges and spanning tree, security posture, exposed services, configuration changes, billing, receivables and the daily briefing.
- Every answer lists the data it read, so you can check it rather than trust it.
- Tag a question with one router to focus it, and choose a quick answer or a deeper analysis.
- Conversations are private to the person who asked, can be deleted, and are removed 90 days after the last message.
Explain with AI, where you are looking
Graphs and the VLAN map- On a full traffic graph, Explain with AI sends the figures on screen to the assistant: the router’s own interface name, never the name you gave the port.
- On the VLAN map it explains the map in plain words, without adding a link the map does not hold.
- The answer waits in your assistant, beside your other conversations.
The screens it sits on
Monitoring- The Live Wall for the operations room: a tile per router, the ten busiest interfaces, subscribers and routers, open incidents, and BGP, OSPF and spanning-tree cards that say how many routers they read instead of giving an all-clear.
- Device graphs over an hour, a day, two days and the full period your plan keeps, with the peak and the 95th percentile.
- Early access, new in 1.9.0: a Graphs view of every router and port with a full graph behind each, and a Traffic view that ranks interfaces, clients and routers.
- Alerts your organisation sends can reach owners and admins in Telegram as they happen, and the assistant can read the last 30 days of them.
| What it watches | When it raises a finding | Severity |
|---|---|---|
| A router that went down | Down for 30 minutes or more of the day | MediumHigh if still down |
| A router that went silent | Online, sent logs during the week and none today | Medium |
| A flapping BGP or OSPF peer | Down or reset 3 times or more in the day | MediumHigh at 10 |
| A port losing link | Lost link 5 times or more in the day | Medium |
| A link at its limit | Peak at 90% of link speed, or the day’s 95th percentile at 80% | Medium at the peakHigh on the 95th |
| A router with no backup to restore | Online, with no restorable backup in the last 7 days | Medium |
| Firmware behind | RouterOS behind the router’s own update channel | Low |
| An alert storm | 50 or more alerts in the day, or 20 or more of one kind | Medium |
| A log surge | Router log volume three times a normal day | Low |
The digital SOC: is anyone getting in?
RouterOS has no login lockout, so a password can be guessed at for as long as the service is reachable. How fast the attempts arrive, and what happens after them, is the signal. That is what the SOC half watches, along with your own team’s accounts and the doors left open.
Router logins
From the routers’ own logs- Your routers’ logs are collected centrally, with sign-in attempts picked out and rated, and the span they cover stated: a hundred attempts in a minute and a hundred over a week are different problems.
- The daily briefing turns them into findings: a burst of guesses, a guess that worked, a password sent in clear text.
- Helix’s own management addresses never count against you.
Your team’s console accounts
Sign-ins to Helix- Sign-ins by your organisation’s members are checked as well as the routers: a sign-in from a country not seen in the last 30 days, a sign-in the checks rate highly suspicious, and repeated failures.
- Each finding says what to do: ask the member, and if it was not them, reset the account and read what the session changed.
The doors left open
Exposure and access- Which routers offer Winbox, the API, SSH or the web console to any address, and which still have telnet and FTP switched on at all, with internet-facing routers listed first.
- A router not read yet is reported as unread, never as clean.
- Each router shows whether it still admits the address Helix manages it from, and one control adds Helix’s address without removing anything already on its list.
Changes you did not make
Configuration tracking- Each night Helix compares every router’s management services, address restrictions, admin accounts, scheduled jobs and scripts with the night before, and flags a change that was not made through Helix.
- A service switched on, a port moved, a restriction removed or widened, or a full-rights user appearing raises a security alert.
- Hardening your own router is recorded, not alarmed, and the first reading is a baseline that raises nothing.
A high or critical security finding in the daily briefing also raises a security alert on your organisation’s alert channels. MikroTik releases and security advisories are tracked in the console, and the briefing flags every router running RouterOS behind its update channel.
| What it watches | When it raises a finding | Severity |
|---|---|---|
| A password that was guessed | 5 or more failed logins from one address on a router, then a successful one | Critical from the internetHigh from inside |
| Someone guessing passwords | 20 or more failed logins from one address on a router, across any user names | MediumHigh at 200 |
| A password sent in clear text | A successful login over telnet or FTP from a public address | High |
| A console open to the internet | A successful Winbox login from a public address | Medium |
| A suspicious sign-in to Helix | A team member’s console sign-in that the sign-in checks rate highly suspicious | High |
| A sign-in from somewhere new | A team member signing in from a country not seen in the last 30 days | Medium |
| Failed sign-ins on your team’s accounts | 10 or more failed console sign-ins in the day | Medium |
The guardrails are part of the product.
You are being asked to let a model read about your network. These are the terms, and each one is enforced by the platform rather than promised in a policy.
Nothing leaves without consent
- The AI half runs only after your organisation’s owner agrees to data going to the AI service. The agreement is recorded and audited.
- A consent that cannot be read is treated as a no.
- Without consent the daily briefing is still written, by the code rules alone, and it says so.
Names never reach the model
- Router and customer names are replaced by stand-ins keyed to your organisation before anything leaves the platform, and restored in the answer you read.
- A stand-in the model invents resolves to nothing: never to a router that belongs to someone else.
It reads; it does not act
- The assistant and the daily sweep read what Helix already stores. They open no router session and write nothing to a router.
- Nothing runs from a chat message. Every finding names an action for a person to take.
- The few actions the AI may draft for Helix’s own operators run only after a person approves them in the console.
Caps and limits
- AI is switched on per organisation, with a monthly cap. Every call is reserved against that cap and the platform’s own ceiling before it is made, and refused once the cap is spent.
- Your organisation’s usage view shows what was spent.
- A single question stops, with the reason shown, at a time limit or after a set number of reads.
Helix pays for the beta sweep
- During the beta the daily sweep is paid from Helix’s own budget, under its own monthly cap.
- It is never billed to your organisation and does not touch your cap.
- Your owner’s consent still decides whether its AI half runs.
Every call on the record
- Helix keeps every model call for review for 90 days: what was sent, with names already replaced, what came back and what it cost.
- An owner or admin sees what the assistant costs, never what a colleague asked it.
What it is not, yet.
- It is a first watch, not a replacement for your engineers. It recommends; a person decides.
- The daily briefing is in beta. Its rules and its wording will keep improving as it meets more networks.
- It knows only what Helix stores. A router Helix does not poll, or whose logs do not reach Helix, is named as unread rather than guessed about.
- It does not act on its own. An agent that plans changes and hands them to the platform for approval is on the roadmap as agentic orchestration, and it is not built.
- The live demo’s guest account cannot use the assistant. In a real organisation it runs only after the owner has agreed.