My lunch-break response to ARTEX: a host intrusion sentinel

A host intrusion sentinel you run yourself. A small agent on each machine watches running programs and their network connections, scores what it sees in code, and reports the cases that look like an attack to a service you deploy in your own Cloudflare account. By default it also ends a hostile program, and everything that program started, on the spot.

It was built in response to FBI FLASH-20261113-001 on agentic intrusion frameworks, and it is aimed at the things those tools do on a machine: web shells, s, remote-access implants, movement between Windows machines, Active Directory attacks, and the pace and repetition of an automated operator.

Status: draft, not yet released. Read "What has and has not been tested" before relying on it.

 each machine                                   your Cloudflare account
┌──────────────────────────────┐   HTTPS out   ┌─────────────────────────────────┐
│ agent/sentinel_agent.py      │ ────────────► │ server/src/worker.mjs  (Worker) │
│  sensors  → scoring → cases  │ ◄──────────── │  cases, decisions, learning     │
│   / stop (if approved)  │  decisions,   │  D1 database, optional AI       │
└──────────────────────────────┘  weights      └─────────────────────────────────┘

• The agent reads the operating system's own process and connection tables. It captures no packets and reads no file contents. It opens no port. Scoring happens on the machine.
• Only cases leave the machine : a program that reached the SUSPECT or HOSTILE level, with the signals that fired, the programs that started it, and the addresses it talked to. A command line never leaves the machine; the agent reports which pattern matched, not the text.
• The service checks every field, scores the signals again (the level is never taken from the device), stores the case encrypted, raises an alert, and hands back two things: the operator's decision on a program that agent d, and the learned signal weights.
• It acts, within limits. It never touches operating-system processes, security software, container runtimes, remote access (sshd ), the web server itself, or the browser, mail or document program a person is working in: it ends the harmful thing those programs started, not the programs. It never signals a process that has already exited.

Set the ceiling for the whole deployment with the service variable RESPONSE_MODE, and a machine's own mode with --mode at enrolment. A machine gets the lower of the two.

The default. With RESPONSE_MODE left empty, a deployment with a model configured runs decide, and one without runs kill. Agents ask for kill unless told otherwise.

How decide works. The agent freezes the program the moment it is judged hostile, so the attack is already stopped while the decision is made. The service asks the model once, with an eight-second limit, and answers in the same exchange:

• stop when the model recommends it with high confidence: the agent ends the program.
• release only if you setDECISION_RELEASE tohigh-confidence , the model is highly confident, and no locked signal is involved (a published indicator, credential theft, a directory attack). The agent lets it run and leaves it alone afterwards. A model's release does not mark the program as yours and teaches nothing.
• hold in every other case: it stays frozen until an operator decides.

If the model fails or times out, DECISION_FALLBACK decides: kill (the default) or hold. An agent that hears nothing from the service at all for twenty seconds applies the same fallback by itself.

Kill is not reversible. In kill mode a false alarm ends a legitimate program; decide exists to avoid exactly that. The agent acts only on specific launch chains with almost no honest use, or on cases whose evidence spans three categories, and a program an operator marks "ours" is never touched again. Even so: run `` or report first on machines where a wrong stop is costly, and watch what it would have done.

If you run report or ``, run the AI analyst as well (see "The AI part"). In those modes nothing ends an attack until a person reads the case, and an automated intruder works in minutes. A second, independent model reading every case and recommending stop or release shortens that wait; keep it separate from whatever AI your organisation already uses, so one compromised or confused system is not judging its own work.

Signals are weighted and grouped into categories. A case is called HOSTILE only when the evidence spans at least three categories, so no single rule decides it.

Needs Node.js 22.5 or newer and Python 3.9 or newer.

cd server
export SENTINEL_ENROLL_KEY=$(python3 -c "import secrets;print(secrets.token_hex(24))")
export SENTINEL_ADMIN_TOKEN=$(python3 -c "import secrets;print(secrets.token_hex(24))")
node local.mjs            # in-memory database, for evaluation only

In another terminal, with the same two variables set:

python3 agent/sentinel_agent.py --state-dir ./state enroll --server http://127.0.0.1:8787
python3 agent/sentinel_agent.py --state-dir ./state run
curl -H "Authorization: Bearer $SENTINEL_ADMIN_TOKEN" http://127.0.0.1:8787/v1/devices
curl -H "Authorization: Bearer $SENTINEL_ADMIN_TOKEN" "http://127.0.0.1:8787/v1/cases?state=open"

Copy server/wrangler.example.jsonc to server/wrangler.jsonc, then follow the commands at the top of that file: create the D1 database, load schema.sql, set the three secrets, deploy. Three secrets are required and each must be at least 32 characters:

Optional: ALERT_WEBHOOK_URL receives a JSON alert for each new case. The alert text is written by the service from the signal ids; text from a device is never placed in an alert.

Run the agent with administrator or root rights where you can. Without them it sees only the current user's programs, and on Windows it cannot read the Security log.

Every installer enrols in kill mode unless you name another.

What an intruder does in Microsoft Entra, Azure or AWS leaves nothing on a machine; it is all in the audit logs. Forward those records to the service and it applies the cloud rules:

curl -X POST https://your-service/v1/cloud-events \
  -H "Authorization: Bearer $INGEST_TOKEN" -H "Content-Type: application/json" \
  -d '{"source": "aws-cloudtrail", "records": [ ...CloudTrail records... ]}'

source is entra-audit, entra-signin, aws-cloudtrail or azure-activity; send up to 1000 records at a time, exactly as the cloud wrote them. Use whatever already moves your logs (an Event Hub or EventBridge target, a scheduled export, your SIEM's forwarder). The service never calls a cloud API and holds no cloud credential. Each identity whose records add up to a case gets one, under a stand-in device named after the source; an operator can mark an identity as theirs so it is not raised again.

Each batch is judged on its own, so forward records in batches that cover a few minutes. The rules are written from the vendors' published log references and tested with records in those shapes; they have not been run against a live tenant.

Detection, scoring, stopping, pausing and learning are all plain code. They need no model and work with AI_PROVIDER set to none, which is the default.

One optional model does two jobs, both in server/src/analyst.mjs:

• Analyst. It adds a second opinion to every case for the operator: a two-sentence summary, the likely technique, and a recommendation.
• Decision model. Indecide mode the same answer settles what happens to a frozen program, within the limits under "Howdecide works".

The model never changes a score and never teaches the policy. It sees signal ids with the service's own sentences, program names and counts; it is never sent a command line, and it is told that everything in the case is data. Choose it with one variable:

To plug in a different model, add a branch in that file.

What one decision model covers. Every case the agent can freeze passes through the same model: email and document launches, web shells, s, implants, credential theft and movement between Windows machines. It does not decide cases where there is nothing on the machine to stop: web-request attacks, connection bursts, directory-log patterns and antivirus detections are analysed for the operator, not acted on. And a model adds judgement, not sight: it covers only what the sensors report and what you forward.

The service learns from your operators' own verdicts and nothing else:

• Each case an operator marks "ours" or "an attack" is remembered as its shape: the signal ids, the platform and the verdict. No program name, path, address or command line is kept in that memory.
• A signal your operators keep dismissing becomes worth less on your machines; one they keep confirming becomes worth more. A weight moves one point at a time and at most two points in total.
• Published indicators, antivirus verdicts, attacks on a service and directory attacks never move.
• A change is adopted only if every attack your operators confirmed before, and every reference attack in server/src/signals.mjs , would still be reported under it. Otherwise it is rejected.
• POST /v1/learning/reset forgets everything learned.

No model takes part in this. It is bounded tuning, not a system that rewrites itself.

Plugging in a memory engine. Recall of similar past cases works out of the box by comparing shapes. If you have a semantic memory store, bind an object as SENTINEL_MEMORY with remember(text) and recall(query, k); the service will write each verdict to it and show what it recalls beside a new case.

All operator calls need Authorization: Bearer <ADMIN_TOKEN>.

There is no web dashboard in this repository yet; the API is the interface.

Measured on the development machines; your numbers will differ.

cd agent  && python3 -m unittest discover -s tests -p "test_*.py"   # engine, /stop, 100 scripted events
cd agent  && python3 tests/test_cases.py                            # the per-event table
cd server && npm test                                               # the service

MIT. See LICENSE.