ITOps and SecOps: neither AIOps nor AI SOC
Every time a new category gets hot, the market produces two labels before it produces a definition. In security operations, the labels of the moment are "AI SOC" and "AIOps". We reject both, and the reason is worth explaining, because the explanation says more about the product than the label would.
A label invites comparison. A definition invites a test
Accepting the "AI SOC" label would mean accepting someone else's category. Inside it, we are one more name on a long list: KuppingerCole counts 123 AI SOC vendors, evaluated 39 of them in its April 2026 Leadership Compass, has another 84 candidates under screening, and expects around 20 independent vendors to remain by 2030. It is a crowded category, and it is half of what we do.
Accepting "AIOps" would be worse, because today that label describes observability and telemetry. And observability is not operations.
The practical difference is this: a label invites comparison with whoever already owns it. A definition with tests invites an experiment. We prefer the experiment.
ITOps, taken literally
IT Operations means deploying, operating and supporting. It does not mean observing. It was the market that loosened the term by selling dashboards as operations.
The definition we use is this:
ITOps is acting on any technology, from any vendor, connecting to it to deploy, operate and support, running the command inside the technology itself, with no intermediary: no third party product in the middle and no script written in advance per technology.
It breaks down into four tests. All of them mandatory.
| Test | What it rules out | |
|---|---|---|
| T1 | Any technology, from any vendor | Anyone who only operates their own ecosystem |
| T2 | Deploys, operates and supports, not just observes | Anyone who monitors and alerts |
| T3 | Runs the command inside the technology itself | Anyone who only opens a ticket, recommends or shows a dashboard |
| T4 | No intermediary: no third party product in the middle, no script written in advance per technology | Anyone who depends on a human playbook per technology, or on an intermediate connector |
Four tests anyone can apply to the vendor they already have, including us.
Where each family of tools stops
- Observability (Dynatrace, Datadog, Zabbix, Splunk ITSI): stops at T2 and T3. It sees very well and it does not execute. It is still necessary, and it is still not operations.
- Script based automation (Ansible, Terraform, Puppet, endpoint management tools): stops at T4. It runs exactly what someone wrote beforehand, one technology at a time. The work did not disappear, it moved: now it is writing and maintaining the script.
- ITSM and ITOM: stop at T4. They orchestrate through connectors and an intermediate server.
- Security copilots bound to a single ecosystem: stop at T1. They are good inside their own platform, and whatever comes from outside arrives as ingested telemetry, not as equipment being operated.
None of these families is doing anything wrong. They are solving a different problem.
Why the intersection is the point
AINEXT's thesis is easy to state and uncomfortable to accept: most security exposure is born in the daily work of deploying, operating and supporting the stack. A rule created for a test and never removed. Access granted for a migration and never reviewed. A device that entered the estate without entering the inventory. None of that is a sophisticated attack. It is operations.
Whoever acts only on the effect receives the alert. Whoever acts on the cause operates the IT and, by operating it, changes the security posture.
That is why ITOps is not a second product line next to SecOps. It is its precondition. You cannot sustain a mature security operation on top of a third party stack that nobody can operate.
How to test this, including against us
A definition without an experiment is marketing. The two experiments we use internally can be reproduced by any evaluator:
- Configure a device from another vendor and check the change in that vendor's own console. If the change shows up there, the product passed T1, T2 and T3. If it only works on assets where the agent is installed, the reach is that of its own ecosystem and the result is partial.
- Run an IT operations task and watch the posture score move. That is what demonstrates convergence. Without this second experiment, ITOps and SecOps are two tabs, not one operation.
Apply both to your current vendor before applying them to us. The question that matters is not which acronym they use on their website, it is what they can execute on a Tuesday morning.
What this means for anyone evaluating Myrmex
Myrmex is a multi-agent AI platform that does ITOps and SecOps in the same operation, on top of the tools the organization already has, with a human decision before action on a critical asset and a record of what was executed. We do not replace your firewall, your SIEM or your EDR. We operate with them.
If your evaluation starts with which quadrant a vendor sits in, we will disappoint: we sit in none. If it starts with the four tests, that is exactly the conversation we want to have.
You can see the capabilities in Features, the operating design in SOC, and start testing in your own environment from the Pricing page.
The technical classification of the tool families cited is AINEXT's own assertion, supported by each vendor's public documentation.