Inside JODR aMDR: sensors, deception and AI agents

Plenty of companies say they use AI in cyber security. Few explain exactly how, or what happened when the AI was left to work on a real platform. This article walks through JODR aMDR from the inside: the sensors and deception systems, where the data is kept, how each alert passes through four steps, and what the numbers showed after 15 days of live operation. Every figure here comes from measurement, and every alert and every block is counted once.

Layer one: sensors and deception systems

It starts at the edge. We ran four types of sensor in front of one live web platform that JODOR operates in Saudi Arabia. There are deceptive web paths that look like admin pages or forgotten configuration files, service sensors that pretend to be exposed services, sensors at the edge and inside the web application firewall, and network sensors. All of them are built to look weak, and all of them are hosted and run by JODOR inside the Kingdom. Over 56 days they recorded 450,908 requests from 22,924 addresses and confirmed 2,207 of those addresses as attackers.

What makes deception useful is how clean the signal is. A genuine visitor has no reason to ask for a .env file or the /.git/config path. Anyone who touches those paths tells us himself that he is an attacker, and hands us his address, his tool and the kind of weakness he is hunting for.

Layer two: stores inside Saudi Arabia

Everything the sensors capture goes to stores hosted inside Saudi Arabia, and it stays there. There is a store for raw telemetry, one for threat intelligence gathered from free public sources, one for indicators already proven hostile, one for the attacker groups we track, and the rule library. These stores are the system's memory, and they are how an agent knows whether an attacker has been seen before.

Layer three: detection

On top of the stores run the detection rules and blocklist matching. The part we are proudest of is that AI built this layer. AI engineering agents wrote the software and wrote 163 detection rules, each for a defined type of attack, following a policy set by people. They also wrote seven blocking rules that act only when a security control or a blocklist has already proven the attack. A rule-writing agent has since added 15 more detection rules, each checked by an AI reviewer before it went live. People decided what counts as proof, and AI turned each decision into a rule that acts in seconds.

Layer four: four steps for every alert

This is the heart of the system. An alert moves up one step only when the step below cannot settle it. Step one is the rule agent, and it uses no AI model at all. It settles an alert only when one of four conditions is true: the source is already blocked or a security control has already denied it; the firewall has denied every request the source sent; the source is on a public blocklist and was denied, or sent ten or more requests; or the same alert was judged before, or it comes from a known administrator. If none of the four is true, the alert moves up.

Step two is the first-look agent, a fast AI model that reads the alert and settles the clear cases, typically in 1.2 seconds. Step three is the analyst agent, a large expert AI model with 117 billion parameters that investigates whatever the first look could not settle, typically completing a deep investigation in 18 seconds. Step four is the human in the loop, a security professional who sets the policy and handles every alert the agents escalate.

Helper agents work around these steps. A fix agent applies recommended fixes once an AI reviewer approves them, a rule-writing agent proposes new detection rules for review, and a profiling agent groups alerts by attacker so we know who is behind them. Every block passes fixed safety checks that stop the agents from blocking administrators, partners, content delivery networks and real search engines, and every block can be undone.

What happened over 15 days

Over 15 days, 6,168 alerts were raised. The rule agent settled 2,506 of them, or 41%, without any AI model, because the proof already existed. The first-look agent settled 1,305, or 21%. The analyst agent settled 1,262, or 20%. 967 alerts, or 16%, were escalated to the person, and 128 were still open when the 15 days ended. Put another way, the agents settled 5,073 alerts, 82%, without a person, and the person saw only what needed a person.

There were 1,920 block decisions. The rule agent made 1,234 of them, the first-look agent 196, the analyst agent 457, the human in the loop 27 and the fix agent 6. Of the rule agent's decisions, 309 reused earlier AI findings stored as known attacker addresses. In the end 1,906 blocks were applied, and 14 failed or were withdrawn.

Speed

When the firewall had already denied every request from an attacker, the rule agent blocked it within about five minutes. When the analyst agent made the decision, the block typically followed within 14 minutes. Across all 1,759 blocks that could be timed, the typical time was 20 minutes, and the fastest block came 15 seconds after the attacker's first request. The firewall stopped the first request, and the agents then closed the door for good. The first request may well have been harmless, so the real times are shorter.

Had every alert been worked by hand, at about three minutes of hands-on work per alert and eight-hour days, it would have taken about three analysts every day. Instead the agents escalated about 64 alerts a day, which took roughly three hours of the human in the loop's day, and the rest of that time went to threat hunting.

And the mistakes

Fast is not always right, and we will not hide that. Of the 1,906 blocks applied, 102 were later undone, about 5%. Safety checks reversed 87 of them automatically, and 15 were reversed after escalation to the person. Most of those mistakes hit administrators, content delivery networks and real search engines, and a list of trusted addresses from day one would very likely have prevented them. The lesson we took away is simple: give an agent freedom in step with the proof. The rule agent may block alone when the attack is proven and the block can be undone, and a risky block proposed by an AI model goes past a person first.

How the same system works in Managed Deception

The same agents now watch the deception systems we build in each client's name. The important difference is that all of this happens on JODOR infrastructure inside Saudi Arabia, not inside the client's environment. When an agent decides a visitor is an attacker, that attacker goes onto the client's attacker list, and the client receives the alerts, the detection rules and the monthly report, then decides what to do. There is nothing to install, no access to the client's network, and no action inside the client's environment.

Sources: JODOR sensors and deception systems in Saudi Arabia, 29 August to 23 October 2026, collected by JODOR and not published in raw form. JODOR AI analysis and rules data and JODOR response data from a 15-day live test, in which every alert and every block is counted once. The manual workload figure is a JODOR estimate at about three minutes per alert and eight-hour days. Mohsin et al., human–AI collaboration in SOCs with trusted autonomy (2025), an academic study that proposes tying an agent's authority to the strength of the evidence.