Nosana and Decentralized Compute: Auditing My AI Security Platform and Planning the GPU Experiment

Signup Write New Story Nosana and Decentralized Compute: Auditing My AI Security Platform and Planning the GPU Experiment by Igboanugo David Ugochukwu by Igboanugo David Ugochukwu | @ drechi Technical writer at Independent Technical Writer (Open to Work) Technical writer crafting docs, APIs & cybersecurity content that drives clarity and trust

Technical writer crafting docs, APIs & cybersecurity content that drives clarity and trust

A round two engineering report on brute force detection, a deployment that works, a GPU module that does not yet exist, and the experiment that would settle whether decentralized compute earns a place in this pipeline.

Most security teams do not lack events. They lack the story that connects them. A failed login at 02:14, a success at 02:19 from the same address, and a read of a sensitive resource at 02:21 are three log lines in three systems. Together they may be one account takeover. Apart, each looks like noise.

That is the problem SentinelIQ targets, and it is still a live one. Verizon's 2026 Data Breach Investigations Report, drawing on more than 22,000 confirmed breaches, found vulnerability exploitation overtaking credential abuse as the top initial access vector, at 31 percent. The headline is real, but Push Security points out that the report's taxonomy splits identity attacks across phishing, credential abuse and pretexting, and that identity related access comes to roughly the same share as exploitation once combined.

More telling for anyone building detection: credential abuse still appears in 39 percent of all breaches across the full attack chain. Stolen credentials may no longer be the front door in every case, but they remain the connective tissue of the breach. Detecting how they get used is still worth building.

Brute force against an account is catalogued as technique T1110 in MITRE ATT&CK. It is the technique SentinelIQ models first. I built it in public, and for this second article I did something uncomfortable: I reread my own code line by line, as a skeptical reviewer would, and wrote down what it does.

SentinelIQ is a Python 3.12 and FastAPI service, packaged with Docker, with a browser dashboard. The README describes the flow as events entering an API layer, then a UEBA risk engine, a correlation engine, MITRE ATT&CK mapping, an attack graph builder, a response engine and a dashboard. The repository is MIT licensed and has a live Swagger interface on Nosana at the deployment URL.

I want to be precise about the word "AI" here. I audited four modules in depth: the UEBA engine, the correlation engine, the threat intelligence check and the GPU anomaly module. In those files, nothing is trained, and no model is loaded. The logic is rule based, which is a fair starting point for a transparent system, as long as it is labelled correctly.

Counts failed logins per user in memory and computes a linear risk score

Applies two thresholds to risk plus a threat intelligence flag

Checks an IP against a hardcoded list of two addresses

Simulated. Builds a three number vector and applies a random multiplier

Static T1110 label attached to every outcome

{ "user_id": "admin", "event_type": "LOGIN_FAILURE", "ip_address": "8.8.8.8" } In ueba_engine.py, each user has an entry in an in memory dictionary holding a failed login counter and a suspicion counter. Every LOGIN_FAILURE adds one to the counter. From the third failure onward, the suspicion counter rises by two with each failure. The risk score is failed_logins * 20 + suspicious * 25.

I traced that arithmetic by hand from the source. These are derived values, not recorded API output:

The score is not capped, and nothing decays it.

correlation_engine.py then combines that score with a threat intelligence flag. If the IP is flagged and risk is at least 60, the result is CONFIRMED_ATTACK (T1110 Brute Force). If the IP is flagged and risk is at least 30, it is SUSPICIOUS_ACTIVITY. Everything else is NORMAL.

Here is the finding that matters. threat_intel.py flags exactly two addresses: 10.0.0.99 and 185.220.101.1. Under this code, the README's 8.8.8.8 example returns NORMAL, even after four failures and a risk of 180. Submit the same events from 185.220.101.1 and the third failure produces CONFIRMED_ATTACK.

The README's sample risk of 65 does not appear anywhere in the UEBA arithmetic above, so it likely came from another module, most plausibly ai_risk_engine.py, which I have not yet verified.

Two more observations. The technique label T1110 is attached to every outcome, including NORMAL, so the mapping is static rather than inferred. And the per user state lives in a process level dictionary, so it vanishes on restart and would diverge across multiple workers.

None of this is shameful. It is what a first prototype looks like. It becomes a problem only if the documentation claims more than the code does, and I would rather find that myself than have a reviewer find it.

It establishes that the pipeline runs end to end and that its thresholds behave deterministically. It does not establish detection quality. A rule that fires on a hardcoded address list is a demonstration of control flow, not evidence of recall against real attackers. A risk score is a prioritisation signal. A correlation label is a hypothesis. Neither is confirmation of compromise, and the string CONFIRMED_ATTACK in the current code is a stronger word than the logic earns. Renaming it is on my list.

The repository contains a gpu directory and a file called gpu_anomaly_engine.py. Its header calls it a simulated GPU based anomaly scorer. It builds a three number "embedding" from the length of the user name, a sum of IP octets modulo 50 and the length of the event type. It then takes the vector's magnitude and multiplies it by a random number between 0.8 and 1.3. The code comments say a real model, such as sentence transformers, ONNX or CUDA, should replace it later.

So the accurate statement is this: SentinelIQ currently contains no GPU workload. There is no model, no CUDA call and no tensor operation in that module. A random multiplier also makes the score non reproducible, which is a defect in its own right for a security tool, because the same event can score differently on two runs.

This shapes the Nosana story, and I prefer to tell it straight. My deployment demonstrates that a containerised FastAPI service can be built, shipped and exposed on Nosana 's network using the free credits I received. That is a hosting result. It is not evidence of GPU inference, and it is not evidence that decentralized compute improved speed or cost. I have not measured either, so I make neither claim.

That is also why the question is interesting. A rule engine like this one is CPU work. It would be wasteful to put it on a GPU, and any honest architecture would say so. Decentralized GPU capacity becomes relevant only when there is a workload that needs it, such as embedding model inference or anomaly detection over large synthetic event histories. Deciding whether that workload exists in this pipeline is the real engineering question.

With limited credits, I cannot explore broadly. I can run one disciplined experiment.

Replace the random multiplier with a small, fixed embedding model exported to ONNX. Run on CPU first and seed everything.

Deterministic scores for identical input

Build a labelled synthetic dataset of benign sequences (including legitimate users who mistype passwords) and scripted brute force sequences, with ground truth stored beside each.

Measure the CPU baseline: precision, recall, false positive rate, p50 and p95 latency per event, throughput per second. Document hardware and versions.

Run the identical workload on a Nosana GPU node and record the same metrics plus cost per thousand events.

State whether decentralized compute helped, whichever way the numbers fall.

If a small model on CPU turns out faster and cheaper, that is a valid and useful finding for Nosana's developer relations team, because it tells them which workloads do not belong on the network.

Reconcile the documentation with the code

A stranger can run the documented request and get the documented response

Add tests. The README lists a tests directory, but the repository listing I inspected does not contain one

Tests cover the brute force path, the benign mistyped password path and the threat intelligence boundary, and pass in CI

A restart does not erase history, and scores stay on a fixed scale with decay

Run the CPU versus Nosana GPU experiment

The metrics table is published with the dataset and scripts

I have used my free Nosana credits and cannot buy more. I treat that as a design input. It is the reason the plan above is one experiment with a baseline rather than a scatter of demos. A small budget forces a precise question, and a precise question is what produces a result other engineers can trust.

It is a transparent, runnable prototype of a security analysis pipeline, with an honest gap between its ambition and its current logic, and a concrete, measurable path across that gap. The hackathon gave me a reason to look closely. The audit gave me the plan.

If you maintain detection engineering tools, or work on workload placement at Nosana, I would value your critique of the evaluation design. Break the assumptions. That is how this gets better.

A Practical FinOps Playbook for AI Infrastructure Costs