OneNetSpace AI PROTECT
Security

Security, in detail.

This page is written for the people whose job is to ask hard questions before a security tool touches an endpoint. It describes exactly how OneNetSpace handles encryption, identity, software integrity, and — above all — where your data goes and where it never does. Everything below reflects how the shipping product actually behaves.

Last reviewed 26 Aug 2026 · reflects the current shipping release

In transit
HTTPS everywhere with full certificate validation; HSTS preload at the edge. The private mesh is encrypted end-to-end.
Passwords & sessions
bcrypt with per-hash salt; short-lived signed sessions with instant, server-side revocation.
Multi-factor
RFC 6238 TOTP; the TOTP secret is encrypted at rest with AES-256-GCM. Mandatory for admin access.
Software integrity
Authenticode-signed; updates are SHA-256-pinned and signature-verified before they run — twice.
On-device AI
The model runs on the device. Detection and inference data are never sent to OneNetSpace by default.
Your rights
The agent honors your Windows permissions and uses real Windows UAC. It never sees your password.
01 · In transit 02 · Accounts & MFA 03 · Device identity 04 · Software integrity 05 · Data boundary 06 · Private mesh 07 · Endpoint privilege 08 · Self-protection 09 · Disclosure

01 · Encryption in transit

Every network path the product uses is encrypted and authenticated. Nothing is sent in the clear across untrusted networks.

  • Agent ↔ cloud is HTTPS only. The agent validates the server's certificate — both chain and hostname — against the operating system's trust store on every connection. Certificate validation is never disabled anywhere in the product.
  • Web & API endpoints are HTTPS-only with HSTS preload (max-age=31536000; includeSubDomains; preload), plus a strict response-header set: X-Content-Type-Options: nosniff, X-Frame-Options: DENY and CSP frame-ancestors 'none', Referrer-Policy: strict-origin-when-cross-origin, and Cross-Origin-Opener-Policy: same-origin.
  • API authentication is bearer-token based with cross-origin credentials disabled and an explicit origin allow-list — which structurally removes classic CSRF exposure.
  • Outbound integrations you configure enforce TLS 1.2 as a floor. SIEM forwarding and email alerting verify the destination's server name and negotiate TLS 1.2 or higher — and they send directly to your destinations (see §05).

02 · Accounts, sessions & multi-factor

Account security is built to resist credential attacks and to give you an instant kill-switch over active sessions.

Passwords

Stored only as bcrypt hashes with a unique per-hash salt — never in plaintext, never written to logs. Login is protected against user-enumeration: an unknown account and a wrong password return an identical error and comparable timing.

Sessions

Signed, short-lived bearer tokens carrying a token version that is checked live on every request. A password reset or a "sign out everywhere" bumps that version and invalidates all existing sessions instantly. The token format is hardened against forgery and downgrade attacks.

Multi-factor (TOTP)

Standard RFC 6238 authenticator-app codes with 160-bit secrets and constant-time verification. The TOTP secret is encrypted at rest with AES-256-GCM (random per-record nonce). MFA is mandatory for administrative and provider access and available to every account.

Recovery codes

Single-use backup codes are issued at enrollment and stored only as SHA-256 hashes; each is consumed atomically so it can never be replayed.

Password & MFA recovery

Reset links are 256-bit random values, stored only as hashes, single-use, and short-lived; using one revokes all sessions. A password reset deliberately does not remove MFA. Lost-MFA recovery carries a mandatory cooling-off delay and can be cancelled from the account email during the window.

Abuse resistance

Rate limiting applies both per source IP and per account across sign-in, MFA, reset and recovery — so rotating IPs doesn't help against a single account's one-time-code step. Every security-relevant action is written to an audit log.

03 · Device enrollment & identity

A device earns its place in your account through a short-lived, hashed credential — and everything the agent is later told to do is cryptographically signed and bound to that specific device.

  • Enrollment codes are 256-bit random and stored only as SHA-256 hashes — the plaintext code exists only in the invitation. Email invitations are short-lived; codes are capped by your license seats and can be revoked at any time.
  • Each device authenticates with a bcrypt-hashed secret, then operates on a signed, expiring device token. Enrollment responses are identical whether a device or secret is wrong — no enumeration.
  • Instructions to the agent are Ed25519-signed and device-bound. Licensing/entitlement state, any administrator-issued protection pause, and uninstall authorizations are signed by the account service and bound to a single device ID and an expiry. The agent verifies every signature and fails closed: a forged, replayed, wrong-device, or expired instruction is ignored, and a pause expires against the device's own clock so cutting the network cannot extend it.

04 · Software integrity & updates

The update channel reaches a process running as the system account, so it is treated as a high-value trust boundary and verified accordingly.

  • Everything we build is Authenticode code-signed — installer, agent, and our bundled components — under the publisher “OneNetSpace, LLC”, with trusted RFC-3161 timestamps so signatures stay valid over time. Two precise exceptions: the bundled network-driver library retains its own publisher's Authenticode signature, and the AI model file is integrity-verified by pinned SHA-256 rather than Authenticode.
  • Updates are pull-initiated by the agent, never pushed onto the device. Before an update is applied the agent verifies (1) the download matches an expected SHA-256 and exact size, and (2) a valid Authenticode signature. If either check fails, the update is discarded and not run.
  • Verification happens twice. The same SHA-256 and signature checks are repeated by the detached updater immediately before it swaps the binary — defense in depth against tampering between download and install.
  • Updates are reversible. They apply out-of-band, keep the previous version as a backup, and pass a health gate after restart; a build that does not come up healthy is designed to be rolled back automatically; the previous version is retained so recovery is possible even if automatic rollback cannot complete.

05 · On-device AI & the data boundary

This is the question we get asked first: where does the data go? The AI assistant runs on the device, and your security telemetry stays on your side.

Never leaves Stays on your device / network

  • The AI model runs locally on the device, bound to loopback only. It's downloaded once on first run and SHA-256-verified.
  • Core detection, response, telemetry and deception are deterministic and don't depend on the model; the on-device AI additionally triages uncertain detections, and its verdicts act only under an enforcement policy you enable.
  • No detection or inference data is sent to OneNetSpace by default. In the standalone product, cloud AI is disabled outright.
  • Deep Scan runs entirely on the device. Its antivirus re-scan uses Windows Defender / AMSI locally, and the process behavior it reports — files created, connections made, credential access, persistence — is drawn from on-device telemetry. No file or activity is uploaded.
  • Mesh defense stays inside your own mesh. When your devices share threat intelligence — immunizing each other, asking a peer for a second opinion, or checking a file's prevalence across your fleet — that reasoning travels device-to-device over your private mesh. It never reaches OneNetSpace, and is never pooled or shared between different accounts.
  • Your local security configuration and mesh keys stay on the machine.

Direct to you Goes only where you send it

  • SIEM forwarding and email alerts go agent → your destination directly — your log platform, your mail server. They do not pass through OneNetSpace, with two opt-in exceptions: if you choose the OneNetSpace email relay, alert summaries transit our relay and are not stored; and if you submit an exclusion request, its metadata (file hash, name, process, rule, signer, and any note you attach) is sent to us.
  • Optional AI-host offload: if you designate one of your own devices as a mesh AI-host, inference can run on that peer over your encrypted private mesh — device-to-peer on your network, still never to us.
  • The account service exchanges only what's needed to manage devices — enrollment, policy, health — over authenticated HTTPS.

06 · Private mesh

The optional device-to-device mesh lets your machines reach each other directly, and OneNetSpace is not in the data path.

  • Keys are generated on the device and stay there. Each device creates its own key pair locally; the private key never leaves the machine. Traffic is authenticated and encrypted end-to-end with modern public-key cryptography and flows peer-to-peer.
  • We distribute keys, we don't carry traffic. The account service acts only as the directory that hands out peers' public keys and endpoints. Your data does not transit OneNetSpace infrastructure.
  • Subnet Relay — reaching a whole remote network — routes through a device you choose, which forwards on your behalf. The relay is one of your machines, not our server.
  • Your fleet defends together, privately. Devices in your mesh can share threat intelligence directly — one machine's confirmed detection can pre-arm the others, and Deep Scan can poll your own devices for a file's prevalence. Each device still re-validates any shared rule against its own history before acting. This reasoning travels only between your devices; it is never combined with other accounts or routed through OneNetSpace.

07 · Endpoint privilege — the agent follows your Windows rights

A security agent runs with high privilege, which is exactly why it must not become a way to do things a user couldn't otherwise do. OneNetSpace mirrors Windows' own permission model.

  • Actions run as you first. When the assistant performs a change, it runs it impersonating your Windows account. If your account already has the right, it just works — no prompt. Only if Windows itself would require elevation does the agent escalate.
  • Elevation is a real Windows UAC prompt. Escalation re-launches through the operating system's UAC — a standard user sees the genuine credential prompt, an administrator sees the genuine consent prompt. The agent never sees, stores, types, or transmits your password; Windows performs the authentication.
  • Consent is action-bound and single-use. Each elevation is authorized by a one-time token bound to the exact action (and its arguments) with a two-minute lifetime, and the elevated helper runs with a normal elevated token — not the system account. Unknown actions fail closed to requiring elevation.
  • Local control channels are locked down. The on-device API listens on loopback only and authenticates with a random token generated per run and held in memory (never written to disk or into any page). Privileged local channels are additionally restricted by operating-system ACLs to the system and administrator accounts.

08 · Self-protection & local data at rest

  • Tamper resistance. OneNetSpace actively defends itself: unauthorized attempts to stop or remove protection are detected, reported to your account, and self-healed, while authorized teardown (upgrade, uninstall, OS shutdown) is gated. Additional kernel-level self-protection tiers are on our hardening roadmap.
  • Uninstall is authorized, not silent. Removing the agent from an enrolled device requires an authorized, signed, device-bound removal token issued from your account — so protection can't be quietly stripped off a managed endpoint. (Devices never enrolled with an account uninstall normally.)
  • Local data at rest. Configuration and mesh keys live in a directory restricted by operating-system ACLs to the system and administrator accounts, with inheritance removed, so ordinary user processes cannot read them.

09 · Responsible disclosure & deeper review

If you're evaluating OneNetSpace and want to go deeper than this page — architecture detail, a threat model, or a specific control — we're glad to walk security teams through it directly, including under NDA.

Found a vulnerability? We welcome coordinated disclosure and will work with you on it. Please email security@onenetspace.com with steps to reproduce and impact. Please don't test against other customers' devices or data.