Security & architecture
Trust is the architecture, not a feature.
A platform that can read your topology and push configuration to live gear has to be trustworthy in its bones — not just at the login screen. This page is the honest, technical version of how Witina AI is built, and why you can hand it a network without handing over the keys. Every claim here is something you can confirm by running the whole platform yourself.
The shape of the system
Two pieces. A lightweight gateway runs inside your network and does all the privileged, local work — discovery, polling, holding credentials, applying changes. The cloud is the brain: topology, alerting, change management, reporting. Sensitive access never has to leave home, and the gateway only ever dials out.
No inbound ports. You never expose a management plane to the internet — the gateway makes an outbound connection and everything rides over that.
Credentials
Your secrets stay on your side
This is the part most tools get wrong: they collect your device passwords into their cloud and ask you to trust their vault. We don't have that vault. When you add a credential in the console, it's passed through to your gateway over TLS and stored — encrypted — only there. Our database that tracks credentials records a name and a type; it has no field for the secret itself, so there is nothing in our cloud to leak, subpoena, or breach.
In the cloud
A credential's name, type, and which devices may use it. Never the secret.
In transit
Relayed to your gateway over TLS, held in memory, then written only to the gateway — encrypted.
At rest
On a gateway you run, on infrastructure you own. Self-host and even the transit stays on your LAN.
Encryption at rest
Encrypted on the gateway, with keys you control
Credential material on the gateway is encrypted at rest. If you've used LUKS or FileVault, the model will feel familiar: one key encrypts the data, and that key is never stored in the clear — it's wrapped in a keyslot, and you choose what holds the key that unwraps it:
TPM-sealed
The key is sealed to a TPM 2.0 chip and never touches disk. A copied disk image or backup is useless without the physical hardware.
SaaS-assisted
The key is split between the gateway and the cloud, so neither a stolen gateway nor a breach of our cloud can decrypt on its own — you need both halves.
Local key file
A key file on the gateway, for fully offline and self-hosted deployments that never depend on anything outside your own hardware.
You set the policy per gateway — require TPM, SaaS-assisted, or local file — and the gateway reconciles its key storage to match. And because the SaaS-assisted mode needs the cloud's share to unlock, de-authorizing a gateway is a crypto-shred: withhold the share and the data on a lost or decommissioned device is cryptographically unrecoverable, whether or not the box is ever recovered.
The gateway
Least privilege, by construction
It isn't root
The gateway runs as an unprivileged user with a handful of narrow Linux capabilities — enough to sniff packets for discovery and serve firmware on one port, nothing more. Reboots and image upgrades go through a separate, API-mediated path. A compromise of the gateway process is not a root shell on your router.
It only dials out
The gateway opens an outbound connection to the platform and proves its identity with a signed token; it's provisioned once with a pairing token and renews itself after. You open no inbound ports and publish nothing to the internet.
Scoped credentials
You decide which credentials are allowed to touch which devices. Access isn't a global admin blob — it's a scoped mapping you control and can audit.
Runs where you want
Appliance, VM, or container — including a fully self-hosted, single container with everything inside. Same code, same guarantees, your choice of blast radius.
Discovery
Quiet by default
Bringing a network online shouldn't set off your own alarms. Discovery starts passive — it listens to what devices already broadcast (DHCP, LLDP/CDP, mDNS) rather than scanning. Active probing and auto-connect are opt-in decisions you make per network, so onboarding doesn't light up your IDS or hammer gear that isn't yours to touch.
Change management
Nothing changes without a paper trail
Configuration changes don't happen as anonymous, irreversible edits. Each one can be routed through approvals, snapshots the device's current state before it touches anything, verifies the result, and can be rolled back to the snapshot if it misbehaves — with a complete audit log of who did what, when, and why. Review before, prove after, undo when you're wrong.
Tenancy & access
Isolation and identity
Multi-tenant isolation
An Organization / Division / Region hierarchy scopes every record, so an MSP can manage many customers from one console without their data mixing. Access is checked per request against the scope you're acting in.
Bring your own identity
Sign in with your own identity provider over standard OIDC / OAuth (Authorization Code + PKCE), configured globally or per organization — so account lifecycle stays where your IT already manages it.
Don't take our word for any of this
The strongest security claim we can make isn't a badge — it's that you can run the entire platform yourself, on your own hardware, and watch exactly what it does and doesn't send. No account, no credentials, nothing to us. The self-hosted edition is the same code; the trust properties on this page are yours to verify, not to believe.
We're an early, pre-audit company and we won't pretend otherwise — there's no third-party certification to wave yet. What there is: an architecture that keeps your secrets on your side by design, and a copy you can inspect end to end.