GEDS.NEURALCIBERGUARD.ORG

GuardEndDev Suite

Four surfaces, one incident. A Linux endpoint, an Android phone, a network segment that takes no agent, and your own website — all reporting to one dashboard, one account, one device record. What lands there is an incident with a severity and a history, not four notifications from four tools.

ArchitectureOne backend, four clients. Wire contracts written once, generated into Python and Kotlin.
IsolationPostgres row-level security. Re-proved in CI on every merge, as the runtime role.
EdgeFour Cloudflare Workers. No origin server to run or patch.
AI boundaryAdvisory only. Output never becomes a command, a query, or a file write.
DeploymentOne package per endpoint. Nothing on-premises needs inbound access.
TenancyMulti-tenant throughout — one console carries many client sites.

Built for small businesses priced out of enterprise security. Every capability below is traceable to the source that implements it, and work that is designed but not built is labelled as such beside the thing it belongs to.

Guardian DesktopLinux endpoint protection — seven ATT&CK-mapped signature rules, in user space
Guardian MobileAndroid and Senior — scam detection that runs where the message is
Guardian SentryA physical sensor for the network segment: decoys, Wi-Fi and RF
Securing WebEdge protection for your own site — a Dashboard capability, not a browser add-on

Interactive demonstration

dashboard-geds.neuralciberguard.org

The web dashboard lives at dashboard-geds.neuralciberguard.org. Press Play the attack below and watch a scripted intrusion unfold: each attacker move is answered by the dashboard as the alert lands, and the related alerts collapse into a single incident with a plain-English summary. That collapse is the whole product claim — and a screenshot cannot show it. Below the dashboard: Guardian Mobile, as it behaves on the phone.

dashboard-geds.neuralciberguard.org Demonstration

Dashboard — press play, then watch the fleet, alert feed and incident react

This preview animates with JavaScript enabled. In short: the dashboard shows the endpoints enrolled against your account, a single alert feed every surface writes into, and the incident that related alerts are grouped into, with the techniques involved.

Guardian Mobile — a message checked on the device

This demonstration needs JavaScript. In short: a message is checked against three named signals — urgency, payment and link — and answered in one sentence, on the phone. One button asks a trusted family member, and sends the verdict rather than the message.

Demonstration only. Every value above is a literal in this site's own scripts. Nothing is fetched, nothing is sent, no account exists and no customer data is involved. Look-alike domains shown in the scam examples are deliberately misspelled and resolve to nothing.

Where it will run. dashboard-geds.neuralciberguard.org is the deploy target; until it is stood up it has no DNS record and does not resolve. No Android package is on Google Play. The demonstration on this page works regardless — no account, no install.

Behind the frame

What the demonstration deliberately leaves out — the honest list

What the demonstration doesn't show

Six things sit behind that screen that an animation cannot make visible. Each is described once, here, and evidenced later on this page.

Endpoint enrolment: An owner or administrator enters a hostname, picks the endpoint type and the site. The Dashboard creates the device record, activates the product entitlement and issues an Ed25519-signed device token, shown once. That token is the agent's only secret; no signing key ships inside an agent.
Centralised settings: One surface has a settings panel: Settings → Senior, which a family member uses to set Senior up for someone else. What it changes that reaches a running surface is the family alert — who it goes to, how often it may fire, and the verified contact list. The appearance preferences stored beside them are read back by that panel and by nothing else yet. Every other Guardian is read from the Dashboard, not steered by it.
Managing connected surfaces: The Admin panel lists every enrolled endpoint with its type, site, status and last check-in, and carries one revocation control: the per-product kill switch for the whole account. Two further levers — disabling a single host, and revoking a single leaked token by name — are enforced on every check-in, and neither has a control in the panel yet: setting them is a database operation today. Stated this way round on purpose, because "three levers" is true of the enforcement and false of the interface.
Device configuration: The Desktop agent reads /etc/guardian-desktop/agent.env on the host; Sentry reads a YAML file on the sensor. Neither is pushed from the Dashboard yet — the signed channel that carries alerts is designed to carry configuration back, and that work is not written.
Cross-surface visibility: Alerts from every surface land in one tenant-scoped feed and one incident model. What groups into a single incident, and what does not, is a rule with a stated shape — set out under how the pieces fit.
Supported integrations: Cloudflare, for the edge ruleset — the edge-event feed has a built receiver and no sender, so nothing is flowing into it. Auth0 is the intended identity provider: the multi-factor gate is written and enforced in middleware, and the sign-in route handler itself is not mounted yet. GitLab, for the package build and the signature over its checksum manifest — no Release has been published and the release key is not cut. Google Play is the intended route for the Android app and no package has been published. A syslog/CEF connector for appliances is Phase 2 and does not exist.

The Guardians

Each Guardian protects one surface

Four products, one owner each. Owners are given as initials, in line with the published privacy policy.

01 / 04 · Owner N.A

Guardian Desktop

Linux endpoint · Python 3.11 · Debian and Ubuntu, amd64

A user-space agent that watches the processes running on a Linux host and reports what it finds. It decides; it does not act.

Full capability detail — rules, containment, anomaly model, packaging

Detection: Each polling pass runs all seven MITRE ATT&CK-mapped signature rules over the process table. Stated precisely, because it changes what a pass produces: a rule reports the first process that trips it and then stops, so one pass yields at most one alert per rule — three staged binaries raise one masquerading alert naming the first of them, not three. The interval is configurable from 1 to 3600 seconds; the default is 5. Telemetry is read from /proc through psutil — no kernel module and no kernel-source changes.
Anomaly ranking — demonstration only: The model is real code and it runs, but only in one place. An IsolationForest of 128 estimators scores each process on nine behavioural features — executable path depth, argument length, uid 0, network presence, CPU, open files, shell identity, LD_PRELOAD presence, and whether the binary sits in a standard path — plus a stable hash of the process name, ten inputs in all. A score under -0.05 is informational and under -0.15 high. Findings are tagged AI-EDR rather than a technique, because a novelty finding has no technique to cite, and this is the one path that reports per process rather than stopping at the first match. Where it runs: guardian-desktop --demo, which trains it in memory on the agent's built-in benign baseline. Where it does not: an installed host. Nothing in the agent, the package or the pipeline trains or ships a model file, so a stock install finds none, says so at start-up, and runs the seven signature rules alone. Training and persisting a model for a live host is on designed, not built.
Fault isolation: Rules are independent and evaluated in isolation. A rule that raises is logged and skipped, and the scan completes.
What leaves the host: Command lines and process environments are redacted at the point of collection, before a value enters an in-memory record — nothing downstream sees the raw text, including the local journal. By default only seven execution-hijack variables are retained and every other variable is discarded. Two of those seven — LD_PRELOAD and GCONV_PATH — are what the current rules read; the other five (LD_AUDIT, LD_LIBRARY_PATH, PYTHONPATH, PERL5LIB, NODE_OPTIONS) are collected and sent with an alert but consulted by no rule yet, and are kept for the rules that will need them. Passwords inside connection URLs, Authorization and Cookie values, bearer material, secret-named variables and high-entropy key material are replaced before transmission, and the argument following a password- or token-class flag is dropped.
Containment: The agent is read-only against the host. Every alert is evaluated against five guardrails — master switch, acknowledged tuning period, per-host exclusion list, severity floor and dry run — and the decision reached is recorded for every alert, including under the default alert-only posture, so the reasoning is auditable before anything is enabled. The guardrails are re-checked independently at the point of action, and a disagreement performs nothing and logs loudly. This release does not modify host firewall state: isolation is decided and recorded, never enforced.
Reporting: Alerts are batched — up to 100 per request, the server's cap — and posted over HTTPS with the device token as a bearer credential. Plain HTTP is refused unless the destination is loopback. Redirects are never followed, because following one would replay the device token to whatever host named it. Server errors and rate limits are retried with bounded backoff and jitter, honouring a numeric Retry-After — the HTTP-date form of that header is not parsed and falls back to plain exponential backoff. A partially accepted batch is reported as partially accepted, never as success.
Identity: The agent asserts no tenancy. Its payload carries the hostname, the alerts and the response decisions. Account, site and device identity are read from the signed enrolment token by the server and never accepted from the request body.
Installation: A .deb that creates a dedicated non-login guardian-desktop account and runs the agent under a hardened systemd unit: no new privileges, strict system protection, private /tmp and /dev, protected kernel tunables and modules, a syscall filter, a capability bounding set of CAP_SYS_PTRACE alone with no ambient capabilities, write access limited to two directories, and ceilings of 10% CPU, 200 MB of memory and 64 tasks. A misconfigured agent refuses to start and names the variable at fault rather than running and reporting nowhere.

Signature rules7 · evaluated per pass

T1059 · Reverse shell High A shell or interpreter holding a non-loopback connection, or an argument list containing a reverse-shell construct. The alert names the remote address and port. Loopback is excluded, so a shell talking to a local service does not fire.
T1036 · Masquerading High A binary running from /tmp, /dev/shm, /run/shm, /var/tmp or /dev/mqueue, or a process wearing a system binary's name from a non-standard path.
T1574.006 · LD_PRELOAD High An execution-hijack library outside /usr/lib, /lib or /usr/local/lib.
T1496 · Resource hijacking High A mining command line — xmrig, minerd, cpuminer, ethminer, --donate-level, or a stratum+tcp address in the arguments. The rule carries a second path that pairs high CPU with a mining-pool lookup; no DNS collector feeds it on a live host, so outside --demo only the command-line match can fire.
T1548 · Privilege escalation High pkexec invoked with GCONV_PATH set, a uid-0 process whose binary sits in a world-writable directory, or sudo carrying a shell payload.
T1566 · Phishing payload Medium A deceptive double extension, or a shell or python3 executing out of a downloads or mail directory.
T1486 · Ransomware Critical A process holding open a file with a ransom extension — .locked, .encrypted, .crypt, .enc, .readme_to_decrypt, .wncry. Read from each process's open-file list on every poll; there is no filesystem watch anywhere in this agent, so the file has to be open at the instant of the poll. The rule also matches a decoy path, and nothing seeds decoys yet. Shadow-copy deletion is reported alongside as a precursor signal.

Rule identifiers, thresholds and severities as implemented. Techniques are cited against MITRE ATT&CK Enterprise v19.1.

Status, stated plainly

Implemented — and stated as implemented, not as validated. The seven signature rules, redaction at the point of collection, the five response guardrails and the decision record they produce, the batching reporter, the fail-closed configuration check, and the hardened .deb and systemd unit. Everything this section says about the agent is read from its source and its packaging, not measured on a host we have watched run.
Demonstration only — the AI-EDR anomaly model. It is exercised by guardian-desktop --demo, which trains it in memory on the built-in benign baseline. No code path, packaging step, command-line flag or pipeline job trains or installs a model file, so on a packaged host the agent loads none and the anomaly path never produces an alert. If someone asks to see the model score a real host, the honest answer today is the demo.
Not built — the decoys the ransomware rule looks for. The rule matches a canary path, and nothing creates canary files: the installer makes the directory and leaves it empty, and there is no seeding command. Until seeding exists, that half of the rule cannot fire and the ransom-extension half is the live one.
Not built — the mining-pool signal. The cryptominer rule's second path wants a DNS lookup to a known pool. Nothing collects DNS on a live host, so that path is populated only by --demo's fixed sample.
Not verified on hardware — what the agent can actually read. The unit runs the agent as an unprivileged service account with CAP_SYS_PTRACE in the bounding set and no ambient capabilities, and a bounding set caps rather than grants. Under ordinary /proc permissions that account should be refused the executable path, environment and open files of processes owned by other users — which the masquerading, LD_PRELOAD, escalation, phishing and ransomware rules all depend on — while command line, name, pid, parent and uid stay readable. This is read from the unit file, not measured: it is a lab-VM check before the showcase, and the fix if it holds is one line of unit configuration.
Known defect — the version an agent reports. The reporter sends a version constant in the agent's source that is behind the version the package is built with, so the inventory will show the older number for a host running the current build. The mechanism is right; the constant needs updating before the inventory is demonstrated.

Its relationship to GEDS. Enrolled once, credentialed once. Every detection files against that device record, deduplicated and grouped; version and check-in are recorded, never trusted for authorisation; three revocation levers are checked on every check-in.

Packages and verification How it is managed

02 / 04 · Owner N.L

Guardian Mobile

Android · Kotlin · the same engine also served as a web version

One scam-detection engine, running where the message is. Senior is the accessibility-first form of that engine for adults 65 and over — plain language, three named signals, and never a score.

Full capability detail — the three signals, Senior, what is and is not built

Two detection paths: The SMS path is written and has never run — read it as the path the code takes, not as behaviour on a phone (see status). It receives incoming messages, reassembles multipart texts by sender, extracts fifteen features and weights nine of them: a shortened link, a revenue-agency or Interac or bank keyword, urgency phrasing, a request for a social insurance number or a password, all-caps shouting, a non-Canadian sender, and a cross-check that a message naming the revenue agency also links to one. Four of the fifteen carry no weight in the shipping scorer — a courier keyword, a money amount, a five-digit short-code sender and the message length — and are named here rather than quietly counted. Above a fixed threshold the code raises a high-priority notification. The Senior path is the opposite shape: a person pastes a message they are already worried about and gets three named signals and a sentence.
The three signals: Every Senior check returns exactly three results, always in the order urgency, payment, link. The order is fixed because a screen-reader user who has heard the result once should know that the third item is always the link finding. Thirteen reason codes, nine of them decisive; a rule is decisive only when a real organisation could not have sent it. Deadlines, wire transfers, link shorteners and plain HTTP are deliberately not decisive, because legitimate messages contain all four.
Two suppressions: The credential check requires an asking verb, so a genuine two-factor message — "your verification code is 481920" — does not fire it. And a bank's own safety notice, "we will never ask you for your PIN", drops the credential finding rather than demoting it: an explanation the reader can see is wrong does more damage than no explanation at all.
No score: There is no number in the Senior engine — not displayed, not internal, not summed and thresholded. The reader gets a sentence selected from a fixed, versioned table, so the same message produces the same words every time. Nothing is composed, paraphrased or randomised.
What stays on the phone: The Senior check makes no network call. Before a message could be sent anywhere, every web address in it is replaced by the literal token [link] and described separately as a set of booleans plus a SHA-256 digest of the host — the wire format has no field an address could travel in. On the web version the sending page re-checks its own redaction and refuses to send if an address survived, and the server checks again and refuses the request outright if one arrives. On Android the redaction and hashing functions are written and nothing calls them, because the app has no network client and therefore no send path to guard. Stated honestly: a digest of a host is not a secret from someone holding a list of domains. What it guarantees is that the address itself is never transmitted, logged or stored.
The family alert: On the web version. There is no such button on the phone — Android has no Senior screen and no network client, so nothing is pressed there today. One press sends four things: the verdict, which signals fired, optionally which contact, and which surface it came from. No message text, no note, no destination, no screenshot — there is no field to carry them, which is what closes the alert button as a route for arbitrary text to a relative's phone. Recipients are resolved on the server from verified contacts only, and the outgoing wording is written by the server from its own fixed table. Destinations are stored encrypted; no endpoint returns one, and the interface shows a masked hint. Up to five contacts.
Impersonation list: Twenty-five organisations, weighted towards the ones this audience is actually targeted with: the Canada Revenue Agency, Interac, Canada Post, Service Canada, RBC, TD, Scotiabank, BMO, CIBC, Desjardins, Bell, Rogers and Telus, alongside the global names. A brand token has to sit on a label boundary, so pineapples.example does not match "apple".
Accessibility: The specification, not a finish — and on Android literally so: these values are declared as constants in the module and no Android code reads them, because there is no theme and no screen to apply them to. 20sp body text on a 16sp hard floor, 1.6× line height, 58dp minimum touch targets with 16dp between them — because a mis-tap on the family-alert button sends a message the person did not mean to send — and a 3dp focus ring. Ink measures 16.8:1 against the surface and the accent 12.5:1. What is rendered today is the web version, which carries the same 58-pixel targets and the same line height in its stylesheet, and where the no-colour-alone rule is implemented: each verdict has a distinct icon shape as well as a word, drawn in the current text colour so a forced-colours mode keeps it.

Verdictsfixed wording · no score

Two strong signals Looks like a scam Or one strong signal alongside one possible signal.
One strong signal Take a moment Or any possible signal on its own. A single decisive finding is intentionally not enough for the hardest verdict.
Nothing found Nothing here looks like a scam The engine has to get this one right too. A checker that flags everything is not a checker.

Signals: urgency — a deadline, a threatened consequence, a request for secrecy. payment — gift cards, wire transfers, cryptocurrency, or a request for a code, PIN or card number. link — visible text contradicting its destination, a borrowed name, a bare IP, a mixed-script host, a shortener, or a scheme that is not HTTPS.

Status, stated plainly

Built and running on the web. The detection engine, the Senior web version served by the Dashboard at dashboard-geds.neuralciberguard.org/senior, the check, contacts and alert endpoints, and the Senior settings surface.
Built, not yet run. The Android port of the engine. It is a line-for-line port of the same source the web version uses, and its test class carries 33 test methods and 75 assertions, none of which has ever executed — the module declares no test dependency and has never produced a build. Its continuous-integration job is advisory for that reason. Everything above about the Android engine is read from the code, not measured on a device.
Not built. The Senior screen on Android, and the app's network client — and therefore, from the phone, enrolment, the second opinion and the family alert. The engine, the wording table and the accessibility values exist; the interface that would show them does not.
Not built — the SMS permission flow. The receiver is declared correctly in the manifest, and nothing in the module ever asks the user for the SMS permission it needs. On the module's minimum Android version that permission can only be granted by a runtime request, so even with a build in hand the receiver could not fire until that screen is written.
The SMS detector is the rule engine, not a model. A TensorFlow Lite classifier is wired in with a fallback, and no model file is committed, so the fallback is the only path the code can take.
SIM-swap alerting does not exist and has been removed from this page. There is no code, no schema field and no permission request for it anywhere in the product.

Its relationship to GEDS. Android is an enrolable endpoint type — the server accepts and issues for it; the app does not yet present a token. Settings → Senior lets a family member steer the family alert and verified contacts on someone's behalf. With no network client yet, the phone cannot enrol or report.

Try the check in the demonstration Packages and availability

03 / 04 · Owner C.M

Guardian Sentry

Linux host + Pico W gateway + Pico 2 W field node · the network segment

The sensor for the segment that cannot run an agent. Detection runs on the Linux host. The Pico 2 W field unit shows the alert, beeps by severity, and takes a physical acknowledgement. Its signed liveness beacon transmits every sixty seconds — received by nothing yet; the relay gateway is unbuilt.

Full capability detail — honeypots, Wi-Fi/RF sensing, the LoRa offline path

Deception tripwires: Five decoy TCP services accept a connection, capture up to 512 bytes and close; three of the five — SSH, MySQL and the router admin page — answer first with a plausible banner, and the SMB and RDP decoys are silent. Nothing real is served. Any connection is an alert, carrying the source address, the decoy touched, and a 120-character preview of what the client sent — often the credentials being guessed. A decoy whose port is already taken by a real service is skipped and logged rather than fought over.
Wi-Fi: On a monitor-mode interface, 802.11 beacons are checked against a configured list of protected network names and trusted radios. A beacon advertising one of your networks from a radio that is not on the trusted list raises an evil-twin alert, once per radio, with the network name and signal strength. More than twenty deauthentication frames inside a ten-second window raises a deauth-flood alert — once for the lifetime of the sensor process, not once per flood. That suppression has no expiry today, so a second flood after the first is silent until the daemon restarts; giving it a window is a small fix and is not made yet.
Radio spectrum: Not a sweep, and the difference matters to anyone reading the band list: the software-defined radio tunes once to the centre of each reachable band and samples a slice about 2.4 MHz wide there, every two seconds. It learns a power baseline per band over its first thousand samples, then alerts when mean power exceeds the baseline by three standard deviations for ten sustained seconds. A band wider than that slice — the 915 MHz ISM entry is 26 MHz wide — is watched at its centre and not across its range. Sentry measures energy as a single figure per pass; it does not demodulate, and it never records content.
How an alert travels: Every request carries four signed fields — the hardware serial, a timestamp, a 128-bit random nonce and the identifier of the key that signed it — under one HMAC-SHA256 header computed over the method, the route path and the exact body bytes. Binding the path is what stops a heartbeat body being replayed at the alert endpoint. The server re-derives the per-device key on every request from a master that lives in the Dashboard's own environment — and, for the minutes a sensor is being provisioned, in the bench operator's shell. It never reaches a sensor, and a sensor that finds it refuses to start, so a stolen sensor yields one device key and not the fleet. The server refuses a timestamp more than five minutes out, refuses a nonce it has seen, refuses a revoked sensor, and compares in constant time. Every failure path fails closed, including an unreachable replay store.
Liveness: The host beacons every sixty seconds under the same signature rules. The Dashboard records the signed instant rather than the arrival time, and shows the sensor healthy within a minute, degraded up to ten minutes, and offline beyond that. A failed beacon is logged and never takes the alert pipeline down.
When the uplink fails: The uplink probes the Dashboard's health endpoint every thirty seconds. On a rejection or a transport failure the dispatcher routes the alert to the LoRa path instead of dropping it. Exactly how far that path goes today: the host writes a compact, unsigned line to the field node over USB serial, and the step that would frame, sign and transmit it is not written — the firmware listens on its radio, not on that serial line, so the two halves are not joined. The frame format they are being built towards is real firmware code, and carries the node's own heartbeats today rather than failed-over alerts: a version byte, a message type, a source address, a sequence number, a compact payload and eight bytes of truncated HMAC-SHA256, verified in constant time. Severity crosses that boundary as an integer from 0 to 3, and "high" is promoted to 3 rather than silently downgraded — on the one channel left when the connection is gone, an extra notification is cheaper than a missed intrusion.
Keys: Provisioned at the bench, never over the air. A sensor holds only its own key, refuses to start if it cannot find it, and refuses to start if the fleet master key is found on it at all. On the host the key file is root-owned and mode 0600, and the daemon refuses to run if it is not.

What the sensor watches3 sensors · one queue

Decoy · SMB backup Critical Port 445. The share that does not exist and has nothing in it.
Decoy · SSH, RDP, MySQL, router admin High Ports 22, 3389, 3306 and 8080. SSH, MySQL and the router admin page answer with a banner; the RDP decoy accepts silently. All four capture and record the attempt.
Wi-Fi · evil twin High Your network name, advertised by a radio you did not authorise.
Wi-Fi · deauthentication flood High More than 20 frames in 10 seconds — the noise made by forcing devices off a network.
RF · 915 MHz ISM High The band the sensor's own backup radio lives in.
RF · 462 MHz FRS/GMRS Medium Handheld radio traffic close to the site.

Decoy ports, thresholds and bands exactly as configured in the sensor. Bands above 1.766 GHz — including 2.4 and 5 GHz — are beyond the reach of the specified tuner and are skipped at start-up with a warning rather than silently dropped.

Current limits — the section that makes the rest credible

The Pico does not sense the network. It displays, beeps, acknowledges and beacons. All detection is on the Linux host. Earlier versions of this page said the opposite; that was wrong.
Sentry observes the segment, not the devices on it. It can tell you an untrusted access point is advertising your network name. It cannot tell you which camera. Naming and grouping devices is a data-model addition, not a new transport.
Sentry's own configuration lives on the sensor — protected network names, trusted radios, scan bands and decoy ports. Pushing them down the signed channel that already carries alerts is designed and not yet built.
The LoRa link ships as a capstone build against a stub radio driver. Both halves of the alert path are implemented and the link between them is not yet joined: on failover the Pi writes an unsigned line to the field node over serial, and the framing-and-transmit step is not written. End-to-end delivery over real radio hardware is not something we claim as validated.
The field node's liveness beacon has no receiver. The Pico signs and transmits one every sixty seconds; nothing on the host listens on the radio and nothing relays it onward, so the Dashboard's LoRa-liveness indicator has no producer today. The host's own heartbeat over HTTPS is the liveness that actually reaches the Dashboard.
Sentry is not packaged, and there is nothing to verify. The Linux host is installed from a source checkout and the field-node firmware is copied to the board; no build script, checksum manifest or signature exists for either, and no pipeline job produces one. The verification commands under Downloads & verification are the Desktop package's and apply to nothing else.
Sentry sensors are not enrolled from the Dashboard. Their keys are set at the bench, deliberately. Once present they appear in the same inventory and answer to the same revocation.

Its relationship to GEDS. A device row like any other — same inventory, same feed, bound to account and site with the boundary enforced by the database. One sensor revokes alone, and a revoked sensor stops refreshing its liveness tile rather than reading healthy forever.

Sensor packages How it is managed

04 / 04 · Owner A.A

Securing Web

Your site's Cloudflare zone · a capability of the Dashboard

Edge protection for your own website. It is not a browser add-on and a visitor installs nothing — it operates in front of the site, so it applies to every request that reaches it.

Full capability detail — edge rules, event flow, property registration

Rules as code: The ruleset is Terraform, not a vendor console, so it is reviewed in a merge request, diffed and rolled back like any other change. It blocks requests for .git, .env, .svn, wp-config and .DS_Store paths; virtual-patches union select, ../ and <script> in the query string; blocks known attack tooling by user agent; issues a managed challenge on API requests above a threat score of 30; refuses TRACE, TRACK and CONNECT, and PUT outside the API path; and turns on bot fight mode.
Off unless you turn it on: Four further controls default to disabled: geo-blocking, an administrative-path IP allowlist, the vendor's managed OWASP ruleset, and edge rate limiting at 20 requests per 60 seconds on the sign-in and enrolment paths, counted per address at each edge location rather than globally — a client reaching two of them gets two buckets. The last two need a plan that exposes them. Every rule is annotated free or paid.
Edge events: A registered site is a row holding its account, its site, its hostname, its zone and a site key. Events are posted signed with a per-site key derived server-side; the master key never leaves the server and the sender holds only the derived key. The endpoint checks header shape, server configuration, the body against the shared schema, timestamp freshness, and then compares the signature in constant time over the method, a constant route path and the exact bytes received — a constant, so a proxy that rewrites the path cannot invalidate a signature.
Replay: The signature is itself the single-use ticket. Presenting the same signed request twice is refused. The ticket is retained for at least twice the acceptance window, computed from the configured clock skew rather than a constant, so widening the window cannot silently reopen the replay hole. The site is resolved only after the comparison succeeds, through a function that takes one exact key and returns at most one row — so the endpoint cannot be used to probe for valid keys.
Where events land: Accepted events become alert rows in the same account-scoped store as endpoint detections, under the same site, isolated by row-level security rather than by application discipline. The edge action sets severity, across the five actions the contract accepts: a block is high; a managed challenge and an interactive challenge are medium; a JavaScript challenge and a log entry are low. The category carries a display technique label for correlation and reading — it is not a claim of host-side detection. A redelivered event is deduplicated rather than doubled.

Ingest gates8 · all fail closed

1 · Header shapeA signature that is not 64 hex characters never reaches the comparison.
2 · Server configurationNo master key configured means every request is refused, not accepted unverified.
3 · SchemaErrors are reported as field paths, so an attacker-supplied value is never echoed back.
4 · FreshnessOutside the configured clock skew, refused.
5 · Constant-time compareOver method, the route constant, and the exact bytes received.
6 · Site resolutionOne exact key in, at most one row out. A valid signature for a missing site raises a security event.
7 · Replay ticketThe signature is claimed once. A repeat is refused; an unreachable store refuses too.
8 · Scoped writeInside the account boundary, enforced by the database.

The order is deliberate: nothing that could be used to enumerate sites or burn replay tickets happens before the signature is verified.

What is not built yet

Stated because a security product that overstates itself is not a security product.

No live emitter. The edge worker or log-push job that signs and sends events is not written. The ingest path is built, contracted and registered; nothing is feeding it.
No self-serve site registration. There is no screen and no endpoint that issues a site key. Today that is a database operation.
Web attacks do not yet join a device's incident. Web events are site-scoped and endpoint detections are device-scoped, and the grouping rule does not bridge the two. They share an account, a site, an alert feed, a severity vocabulary and one incident model — not one incident row.
Website monitoring is not implemented. No DNS, TLS-expiry, security-header, uptime or page-integrity checking exists. Do not plan around it.
One module targets one zone. Applying it to a customer's zone is an operator action, not a Dashboard action.

Its relationship to GEDS. A Dashboard capability, not a fifth deployable: a registered property is a row under your account; an accepted edge event is an alert in the same feed, same severity vocabulary.

What is and is not deployed

How the pieces fit

Four vantage points, one place to look

Each Guardian sees one part of one event. On its own, each part is ambiguous. GEDS is the record that holds them together: one account, one list of your endpoints, one feed, one incident model.

GEDS — the record everything is filed against

One account owns its sites, users, endpoints, alerts and incidents — the database refuses another account's rows regardless of what the application asks. Every endpoint is a row in one inventory.

It holds one alert feed, one incident model, one entitlement per product, and a hash-chained audit log the application can add to and read but can never edit or erase. Opening the administration panel is itself an audited event.

Guardian Desktop — the host's point of view

Sees processes: what is running, what it was started with, and what it is connected to. Reports batches over HTTPS with a signed device token, and asserts nothing about who it belongs to — the server reads that from the token.

It is the only surface whose reports currently trigger the grouping pass, because grouping runs when endpoint alerts are stored.

Guardian Mobile — the person's point of view

Sees a message someone was about to act on, and answers on the device: three named signals and a sentence, with no network call. Senior is the same engine in plain language for adults 65 and over, and also runs as a web version served by the Dashboard.

Stated plainly: the Android app has no network client, so nothing from the phone reaches the feed today. The server side that would receive it is built and Android is a first-class endpoint type there.

Guardian Sentry — the segment's point of view

Sees the things that never touch an endpoint: a connection to a service that exists only to be touched, a radio advertising your network name, a burst of frames knocking devices offline, sustained energy in a band that is normally quiet.

Every report is signed, time-bound and single-use, and the account, site and device are resolved from the hardware serial on the server, never from the message.

Securing Web — the front door's point of view

Sees the requests that never make it to your site: path probing, injection strings, known attack tooling, bot volume. The block happens at the edge; the record of it is what travels to GEDS.

Stated plainly: these events are site-scoped, and the component that would send them is not written yet.

What happened, and how the answer was reached

Four steps. Nothing moves on its own — step through it.

Four vantage points notice four different things

A laptop starts a shell talking to an address outside the building. A decoy service — one that exists only to be touched — is touched. The website's sign-in page is hit hard enough for the edge to start challenging it. A phone receives a text naming a bank and asking for a code.

No one of those is proof of anything. That is the point of having four.
Each report is filed where it belongs

Laptop and sensor reports file against the device; the edge event, having none, files against the site. The tenant comes from the signed credential, server-side — a compromised agent cannot write into another account.

The phone's answer stays on the phone. It is the one surface that does not report today.
Reports that belong together are grouped

A new report joins the most recent open incident for the same device — or site — seen within the hour; otherwise it opens one. The incident takes the highest severity of its parts.

Stated plainly: a device-scoped report and a site-scoped report do not currently join the same incident row. They share the account, the site, the feed and the model.
A person chooses the response

The endpoint agent has already recorded what it would have done and why, for every alert, including under the default posture where it does nothing. That is deliberate: the reasoning is auditable before anyone is allowed to enable it.

An administrator can revoke a product account-wide. Two finer levers — one host, one leaked credential — are honoured at every check-in but set in the database; their panel control is designed, not built. Every refusal lands in an append-only log.

Lifecycle

From a new Guardian to a managed one

Add the Guardian

An owner enters hostname, type and site; the account comes from their signed-in record, never the request. Enrolment writes the device row, activates the entitlement, mints a once-shown credential, and appends an audit entry.
Connect it to GEDS

Every report presents that credential. Linux agents carry a signed token; Android is accepted server-side but presents nothing yet; Sentry sensors sign each request with a bench-set per-device key over method, route and exact bytes.
It appears in the inventory

One table: hostname, type, site, status, last check-in. Version is recorded, never trusted. A check-in can never promote a disabled host back to active — and disabling one is a database operation today, not a button.
Manage it from the Admin panel

Enrolment, inventory, kill switch and audit live in one owner-gated panel that logs even being opened. Settings → Senior is the one remote-configuration surface — the family alert's recipients, interval and verified contacts. Everything else is read, not steered.
Monitor, and respond

Watch the feed, group alerts into incidents, revoke account-wide when something is wrong. The finer levers stay database-set until the panel gains a control.

The boundary

The assistant summarises and recommends. It does not act, and the agent it is describing cannot act either: containment on an endpoint is decided, recorded and left for a person. The controls an administrator actually holds are enrolment and revocation, and both are audited.

Every administrative action, every revocation and every read of the panel is appended to a hash-chained log. The chain can be re-verified from the Dashboard, and a break is reported with the exact record where it occurs.

The threat surface

The standards and frameworks, item by item

What this work is built against

Six exposures a small business actually carries, and the thing in this suite that meets each one.

Exposure, and the capability that answers it

Endpoint compromise A reverse shell to an outside address, a binary staged in /tmp wearing a system name, an execution-hijack library, a PwnKit-shaped escalation, a miner, a phishing payload run out of a downloads folder, or a process holding open a file with a ransomware extension. Seven signature rules run over the process table on every pass — see Guardian Desktop.
Mobile social engineering The messages that work: a deadline, a threatened consequence, a demand for gift cards or a wire transfer, an address that borrows a bank's name and does not own it. Three named signals and thirteen reason codes, evaluated on the device with no network call — see Guardian Mobile.
Network anomalies An access point advertising your network name from a radio you did not authorise; a burst of deauthentication frames knocking devices off; sustained radio energy above a learned baseline. Detected on the segment, where no host can see them — see Guardian Sentry.
Connected-device exposure Cameras, printers and controllers that will never run an agent still sit on your network and still get scanned. Five decoy services turn an intruder's first move into your first alert. Honest scope: Sentry sees the segment, not the identity of the device on it.
Web exposure Automated probing for .env and .git, injection strings in query parameters, known attack tooling by user agent, and the bot volume underneath all of it — refused at the edge before your origin sees the request — see Securing Web.
Slow or unverifiable response Knowing is not answering. Three independent revocation levers are checked on every single endpoint check-in — though only the product-level one has a control in the Dashboard today — and every administrative act — including opening the panel — is appended to a log that can be added to but never edited or erased.

Every claim above is traceable to the implementation it describes. Capabilities that are designed and not built are listed in designed, not built rather than softened into this list.

The control plane

The control plane in detail — enrolment, inventory, kill switch, audit

How Guardians connect, and how they are managed

One account boundary, enforced in the database. One inventory. One panel. This section states what is built and what is not, in that order and by name.

Tenancy: One account owns its users, sites, endpoints, alerts, incidents, entitlements, audit log and web properties. Every endpoint row carries both the account and the site, and row-level security scopes every read and write at the database — not in application code. The ingest routes then re-check the account independently, because a control that depends on a single layer is not defence in depth.
Enrolment: One authenticated endpoint creates the device record, activates the entitlement and mints the agent's only credential. It requires a signed-in owner or administrator; any lesser role is refused and the refusal is audited. Tokens are asymmetric and individually identifiable, so no signing secret ever ships inside an agent and one token can be revoked by name.
Inventory: Hostname, type, site, status and last check-in for every enrolled endpoint, with the agent version recorded from each report.
Entitlements: One per product, per account, in three states: active, suspended, revoked. A missing entitlement is activated on first authenticated check-in; one an administrator revoked is never silently restored — it refuses enrolment until an administrator restores it deliberately.
Revocation: Three levers are enforced, checked on every check-in in one round trip, coarsest first: a product revoked for the whole account, one host disabled, or one leaked credential revoked by its identifier while the hosts that legitimately still run keep running. Each refusal is answered at the next check-in and written to the audit log. One of the three has a control: the product kill switch in the Admin panel. Disabling a host and denying a token identifier are database operations today — the check is written and the button is not.
Audit: Append-only and hash-chained: each row carries the hash of the one before it, no two rows in an account can share a link, and the database itself withdraws the right to update or delete — an administrator may add a revocation and may never quietly withdraw one. The chain can be re-verified from the Dashboard and a break names the exact record.
Grouping: An ungrouped alert joins the most recent open incident for the same device — or the same site when there is no device — whose last activity falls inside a sixty-minute window; otherwise it opens a new incident. Severity is the maximum of the members. The rule is deliberately simple and is sized for a ceiling of 25 devices per account — a limit enforced in code, which refuses enrolment past it with a waitlist message. Enforced, not measured: nothing here has been load-tested, and the ceiling is a stated design bound rather than a benchmarked one.
Remote configuration: Settings → Senior, and only that. Three of its controls reach a running surface: whether an alert goes to one contact or all of them, the interval between alerts, and the trusted contacts with their one-time verification codes — all three are read by the family-alert endpoint. Four more are stored and not yet consumed anywhere: the Senior switch, the text scale, the contrast mode, and whether to follow the operating system's reduced-motion setting. The panel writes them and reads them back; the web Senior surface hard-codes its own appearance and Android has no way to fetch them at all, because no wire type or endpoint exposes the profile. Any member of the account may read the panel; only owners and administrators may change it, so the interface never offers a control the server would refuse.

Not built — stated here rather than discovered later

Enrolment covers two endpoint types — the Linux agent and the Android app. Sentry sensors are provisioned at the bench by design, and a web property is a database row today. Revocation, by contrast, covers every product.
Detection rules are not distributed from the Dashboard. They ship with the agent, so the Dashboard reads an endpoint's findings without steering its rule set. Serving a signed rule bundle over the existing enrolment channel is the missing piece, not a new transport.
Alerts cannot be acknowledged or triaged from the Dashboard. The fields exist in the schema; nothing writes them.
Remote isolation of a host is not available. The decision path is real and audited; the enforcement is not built, and it stays off by default and a human decision.
Host and token revocation have no control in the panel. Both levers are enforced on every check-in, and neither has a screen, a server action or an API route behind it — setting either is a database operation. This is the widest gap on this page between what the Dashboard checks and what it lets an administrator do, and it is named here rather than left for a demonstration to find.
Interactive sign-in is not mounted. The multi-factor gate is written and enforced in middleware, and the identity provider is configured — but the route handler that completes a sign-in does not exist, so the address the middleware sends a browser to answers 404. The DNS record below is not the only thing standing between this page and a working Dashboard.
The navigation does not reach the panels. Six panels exist and are served: the fleet view, the alert feed, the assistant, the Sentry view, Admin, and Settings → Senior. Every sidebar link points at a /dashboard/… prefix that is not part of any of their real addresses, so the links answer 404 while the pages behind them are fine. Four of the nine sidebar entries have no page at all — sites, billing, the settings index and the training module. The prefix is a one-line fix and it has not been made.

Before that sign-in link works — two things. The dashboard-geds DNS record must exist, and the sign-in route handler — the one piece of the multi-factor flow still to write — must be mounted. Everything on this page works today regardless.

Working out where your risk sits? SAIP scores 22 risk domains from a short profile and produces a threat model and a copyable decision record — entirely in your browser. Nothing is sent to us.

Deployment

Per-product availability — what installs today, what is pending, and how

How you get each product

One codebase per product, packaged for what small businesses actually run. Nothing below is a loose binary: what ships will ship as a signed, verifiable release — and nothing has been published yet, on any channel, for any product.

Capstone build shipping for the August 2026 showcase Phase 2 designed, built after the showcase Roadmap honest future work — not claimed

Guardian Desktop

Linux endpoint agent · Owner N.A

One agent, one rule set. There is no second "web-server profile": earlier versions of this page described one, and no such mechanism exists — the agent loads the same seven rules on every host.

Guardian Desktop delivery formats by target platform
Target	Package	Status
Ubuntu · Debian (amd64)	`guardian-desktop_<ver>_amd64.deb` — built by the pipeline on a version tag, with a checksum manifest that is detach-signed and verified in the same job. Both are expiring build artifacts: no Release has been published and the signing key is not cut.	Capstone build
ARM64 servers · Raspberry Pi	`guardian-desktop_<ver>_arm64.deb` — the build script is currently amd64-only	Phase 2
RHEL · Fedora · Rocky	An `.rpm`. No packaging configuration exists for it yet.	Roadmap
Windows	Not started. The agent's collectors and every rule are written against Linux process semantics.	Roadmap

Guardian Mobile

Android · one engine, two surfaces · Owner N.L

The engine is built and the web version is live. The Android package is not: without a keystore the release build is unsigned by design — good engineering, not a shipping package.

Guardian Mobile delivery formats by target
Target	How it reaches you	Status
Senior, on the web	Served by the Dashboard at `dashboard-geds.neuralciberguard.org/senior` — nothing to install, no account needed for a check (DNS record still required)	Capstone build
Try it right now	The demonstration on this page — no account, no install, nothing sent	Live now
Android 11+	Google Play, internal-testing track first. No package has been produced or published.	Phase 2
Showcase sideload	A signed `.apk` via GitLab Release. Requires a release keystore, which does not exist yet.	Phase 2
iOS	—	Roadmap

Guardian Sentry

Network sensor · bench-provisioned · Owner C.M

Sentry is provisioned rather than installed: keys are written to the boards on the bench, deliberately and never over the air. There is no flashable image and no enrolment code — earlier versions of this page listed both, and neither build exists.

Guardian Sentry delivery formats by target
Target	How it reaches you	Status
Linux host (Ubuntu 24.04)	The host package, installed and provisioned at the bench: hardware serial, per-device key and key identifier	Capstone build
Pico 2 W field node	Firmware and a per-device key written at the bench; the radio driver is a stub pending the community driver	Capstone build
No hardware at all	`guardian-sentry --mock` runs with no configuration, no sockets and no hardware, printing three representative alerts through the real severity mapping — including the case where "high" is promoted upward rather than downgraded. Precisely: it exercises the severity code, not the envelope builder; the alerts it prints are written in envelope shape to begin with.	Capstone build
A sensor on hardware you own	A virtual sensor that actually detects needs a monitor-mode adapter and a radio dongle; a container alone removes neither requirement	Roadmap
Firewalls · switches · access points	A syslog / CEF connector so appliances that cannot run an agent still feed the incident model. Not written.	Phase 2

Guardian Dashboard + Securing Web

Hosted · nothing to download · Owner A.A

The command centre needs no installer: sign in, and optionally install the portal as an app. Securing Web is applied to a Cloudflare zone by an operator — not deployed from the Dashboard.

Guardian Dashboard delivery by target
Target	How it reaches you	Status
Any modern browser	Hosted — sign in with multi-factor at `dashboard-geds.neuralciberguard.org` (DNS record still required)	Phase 2
Install as an app	Progressive web app — add to home screen, offline-tolerant shell	Live now
Securing Web edge rules	An infrastructure module applied by an operator to one Cloudflare zone. Reviewed as code, not clicked in a console.	Capstone build
Securing Web edge events	The receiving endpoint is built, contracted and registered. The component that signs and sends events from the edge is not written.	Phase 2

Verify before you install

Downloads & verification

There is nothing to download yet. No Release exists and the signing key is not cut — if you are offered a build before this page carries a fingerprint, that is the warning. From Release 1: a verifiable channel, never a loose binary. The pipeline half already runs.

The promise we keep: no client agent is "unbreachable" — it runs on your machine and can be inspected. The guarantee is narrower and the one that matters: the package you install is provably the one we built, and installing it cannot hand an attacker a foothold (non-root account, hardened unit, outbound-only).

1 · Get the release

When a release exists, three files come with it: the package, the checksum manifest, and its detached signature.

guardian-desktop_<version>_amd64.deb SHA256SUMS SHA256SUMS.asc

2 · Import the release signing key

One time. Confirm the fingerprint matches the key you import.

gpg --import guardian-release-pubkey.asc gpg --fingerprint security@neuralciberguard.org

The fingerprint publishes with Release 1, here and in SECURITY.md at once. Until then there is no build to verify — and being offered one is itself the warning.

This is the release key. It is distinct from the key that signs per-device enrolment tokens, which never leaves the server.

3 · Verify, then install

gpg --verify SHA256SUMS.asc SHA256SUMS # must print: Good signature sha256sum -c SHA256SUMS # must print: OK sudo dpkg -i guardian-desktop_*.deb # only if BOTH checks pass

If either check fails, do not install — the file was altered in transit or on a mirror. Report it to security@neuralciberguard.org.

The verification procedure, step by step

Built today: a version tag builds the .deb, writes the checksum manifest, signs the manifest, and verifies that signature in the same job — a bad signature fails the build. Not built: publication. Artifacts expire; no Release is created.

What gets installed (Desktop)

The agent runs as a dedicated non-login guardian-desktop account.
A hardened systemd unit: no new privileges, strict system protection, private /tmp and /dev, syscall filtering, a capability bounding set of CAP_SYS_PTRACE alone, and ceilings of 10% CPU, 200 MB and 64 tasks.
Configuration at /etc/guardian-desktop/agent.env, root-owned and readable only by the service account — your dashboard URL and enrolment token.
Run guardian-desktop --check-config to validate a change without restarting the service.
Containment is decision-only in this release: the agent records what it would do and never modifies host firewall state.

The full install guide ships in the package. This covers Desktop only — Sentry runs from a source checkout (nothing to flash or verify) and no Android package exists. When either gains a build, it gains this procedure.

Security model

The full technical foundation — stack, contracts, isolation, CI gates

The technical foundation

Trust direction: Endpoints are outbound-only and assert nothing about who they are. Identity, account and site come from a signed credential the server issued, read on the server, on every request. An agent that is lying about its own account cannot write into another one.
Credentials: Endpoint tokens are asymmetric — the private half never leaves the server and the public half is published for verification — and individually identifiable, so a single leaked token can be revoked by name. Sentry uses per-device symmetric keys, re-derived on every request from a master that lives in the Dashboard's environment and — for the minutes a sensor is being provisioned — in the bench operator's shell. What matters is where it never goes: a sensor. One that finds the master refuses to start, so a stolen sensor yields one key and not the fleet.
Isolation: Row-level security at the database scopes every table to the current account, and the ingest routes re-check independently. Both layers, deliberately.
Data minimisation: Redaction happens where data is collected, not where it is sent. The Senior engine has no field an address could travel in. The anonymous second-opinion endpoint stores no message text, no verdict and no address, and rate-limits on a keyed digest of the client address in a table the application cannot read back.
Contracts: One shared wire contract is the source for every surface, and the client-side types are generated from it in continuous integration, so a route and an agent cannot drift apart quietly.
Failure posture: Every authentication path fails closed, including an unreachable replay store. A misconfigured agent refuses to start and names the variable at fault. A partially accepted batch is never reported as success.
Hosting: Hosted in Canada. Multi-factor is required by the session gate, which is written and enforced on every request — the sign-in route that would satisfy it is not mounted yet. The demonstration environment runs at no cost.

Aligned and mapped to

MITRE ATT&CK Enterprise v19.1 Guardian Desktop's detection rules are mapped to Enterprise techniques, so an alert names the behaviour rather than a product-specific label. The version is the one the shipped rules cite.
OWASP Securing Web's signature and virtual-patching rules are written against the OWASP Top 10, and the optional managed ruleset is the vendor's OWASP set.
NIST SP 800-61 The incident model follows the detection, analysis, containment and recovery phases rather than inventing its own vocabulary.
PIPEDA Canada's private-sector privacy law sets the data-handling rules this suite is designed to: consent, minimisation, and no secondary use. The agent's environment-minimisation default cites it directly.
WCAG 2.2 level AA The accessibility floor for every page here and for Senior, where it is the product rather than a finish.
RFC 9116 A published security.txt, so anyone who finds a problem in this software knows exactly where to report it.

Integrations

Cloudflare — the edge ruleset is an infrastructure module applied to a zone, and the same zone is the intended source of edge events.
Auth0 — the intended identity provider for the Dashboard. The multi-factor gate is written and enforced in middleware, and every administrative action re-checks role on the server; the route handler that completes a sign-in is not mounted.
GitLab — the intended publication channel for packages, and today the build channel: on a version tag the pipeline produces the package, a checksum manifest, and a detached signature over that manifest which it verifies in the same job. Those are build artifacts. No Release has been published and the release key is not cut.
Google Play — the intended route for the Android app. Nothing has been published.
Syslog / CEF — designed for appliances that cannot run an agent. Not written; Phase 2.

Honest future work

Designed, not built — every named gap, and the corrections record

Designed, not built

Most need no new architecture — the signed channel, per-device keys and audit trail already carry them; they need endpoints and handlers. Until they land, the Dashboard reads these surfaces without steering them.

The Android app's network client — and with it, from the phone: enrolment, the second opinion, and the family alert. The server half of all three is built.
The Senior interface on Android — the engine, the wording table and the accessibility constants exist; the screen that would show them does not.
The edge-event emitter — the component that signs and sends Securing Web events. Until it exists, edge blocking happens and nothing about it reaches GEDS.
Self-serve website registration — issuing a site key from the Dashboard instead of by hand.
Website monitoring — certificate expiry, security headers, DNS drift, uptime and page integrity. None of it is implemented; do not plan around it.
Pushing detection rules to endpoints — serving a signed rule bundle over the existing enrolment channel.
Sentry configuration from the Dashboard — protected network names, trusted radios, scan bands and decoy ports, sent down the channel that already carries alerts.
Device identity for Sentry — naming and grouping the things on a segment so an alert can say which camera. A data-model addition, not a new transport.
Alert acknowledgement and triage — the schema has the fields; nothing writes them.
Remote isolation of a host — the decision path is real and audited; the enforcement is not built and stays off by default and a human decision.
A syslog / CEF connector — for firewalls, switches and access points that will never run an agent.
A trained AI-EDR model for a live host — the classifier, its ten inputs and its thresholds are written, and --demo trains one in memory. Learning a baseline on a real host and persisting it where the installed agent looks is the missing piece; until it exists, a packaged agent runs signature rules only.
Seeding the ransomware decoys — the rule matches a canary path and the installer creates the directory. The step that writes decoy files into it is not written, so that half of the rule cannot fire.
A DNS collector for the Desktop agent — the cryptominer rule's mining-pool path is written and nothing feeds it on a live host.
Dashboard controls for the two finer revocation levers — disabling one host, and denying one leaked token by its identifier. Both are already enforced at every check-in; neither has a button.
The Dashboard's sign-in route — the multi-factor gate is enforced and the identity provider configured; the handler that completes a sign-in is not mounted, and the sidebar's link prefix does not match the addresses the panels are served at.
The first signed Release — cutting the release key, publishing its fingerprint here and in the security policy, and adding the step that turns today's build artifacts into a published Release.
Packaging Sentry — a host package and a firmware bundle, given the same checksum-manifest and detached-signature treatment the Desktop package already gets in the pipeline. Today both are copied from a source checkout.
Joining the two halves of the LoRa path — framing, signing and transmitting the failover line the Pi already writes, and a receiver on the Pi for the field node's liveness beacons, which nothing currently hears.

Removed from this page in this revision

Each of these appeared here as a shipping capability and was not one. They are named, not quietly deleted — a reader of the earlier page deserves to know which claims changed (second group corrected 2026-08-09).

SIM-swap alerting on Android — no code, no schema field, not even the permission such a feature would need.
A second "web-server profile" for the Desktop agent, with web-root integrity, upload watching and service-health checks — there is no profile mechanism and none of those checks exist.
A ransomware canary mesh with seeded decoys and entropy scoring. What ships is process-level detection: a process found holding open a file whose path is a canary path or whose extension is a ransom extension. Nothing seeds decoys, so the extension half is the half that can fire.
An .rpm, an installation script, a container image, a flashable Pi image, a drag-and-drop firmware file, and an enrolment-code flow — no build produces any of them.
The Pico described as the Wi-Fi anomaly detector; distance figures for the backup radio link; chassis-tamper detection; 2.4 and 5 GHz spectrum sensing; and identification of individual cameras, printers or thermostats.
Website monitoring described as a shipping capability, and "web attacks land in the same incident as your endpoints" — they land in the same feed, under the same site, in the same model.
A hardware purchase path for Sentry. There is none.

Corrected on 2026-08-09, after a second read of the source:

The anomaly model described as running on every polling pass. It runs in --demo and nowhere else, because nothing trains or ships a model file.
Three revocation levers described as controls in the Admin panel. The panel has one; the other two are enforced at ingest and set in the database.
A published, signed GitLab Release for the Desktop package — and Sentry packages "published the same way". No Release exists, the release key is not cut, and Sentry has no package at all.
A navigation entry described as "certificate transparency". No such feature exists anywhere in the product; the entry in question is the training module.
A radio sweep across each band. The receiver tunes once to a band's centre and samples a slice there.
A DNS-based mining-pool signal, and decoy files for the ransomware rule, described as live detection paths. Neither is fed on an installed host.
Four Senior settings — the switch, text scale, contrast and reduced motion — described as remote configuration. They are stored and read by no surface yet.
Assertion and feature counts that did not match the source: the Android port's test count, the anomaly model's feature list, and the number of SMS features the scorer actually weights.
Sign-in described as available behind a missing DNS record. The sign-in route handler is also not mounted.

The second venture

Arcadian, by Arcadia~Verve

Cook well. Stay organised. Think clearly. Live anywhere. A daily-life iOS app with its own progression, built by the same team to the same security architecture: a private cookbook, the rooms and rituals of a home, quiet places within an hour, a household ledger. No security function, no shared code with Guardian — the other thing we are building.

A separate product with the same security posture

A.V PLC — Arcadian Verve

Six surfaces and a vault

Today, Recipes, Space, Trails, Notes and Ledger, plus an encrypted Vault. Six things people actually do in a week, and one place for what should not be casually readable.

Three anchors, one ring

No dashboard. Three anchors for the day and a single ring showing how it is going. A productivity app that opens onto a wall of metrics has already cost you the attention it promised to protect.

Cognition modes

Short exercises for attention and recall — and one of them is a consumer security-awareness mode, which is the only place A.V PLC and the Suite touch.

Ten rungs, and you can fall

Its own ladder of ten, separate from the games' eight rungs. Progress that can only go up is a scoreboard, not a habit.

What stays here, and what leaves. Everything is local-first. The Vault is encrypted on the device, and nothing syncs unless you turn it on.

The demonstration below is one Tuesday, end to end. Press play and watch one choice move through four modules — the meal sets the leftovers, the leftovers fill Wednesday and Friday, the cost lands on the envelope, Saturday's trail meal packs from what is left. Or take the tabs yourself.

What this is: a faithful mock, checkable against the Arcadia~Verve design documents it is drawn from. What it is not: the shipping app — no backend, no bank connection, no account. The Vault line describes the intended design and is not a claim that it is built.

Documentation & contact

Where to go next

Install guide — ships inside the Desktop package at /usr/share/doc/guardian-desktop/INSTALL.md.
Verification — the two commands, and what to do when one fails: Downloads & verification.
Security reporting — security.txt, published under RFC 9116.
Assessment tool — SAIP scores 22 risk domains locally in your browser and produces a threat model and a decision record.
Support and account — the front door, or security@neuralciberguard.org.

Architecture documents, decision records and the capability matrix live with the product source rather than on this page, so that they are versioned alongside the thing they describe.