Security & architecture
You can hand us your network and keep the keys.
A platform that can read your topology and push configuration to live gear is asking for a lot of access. This page explains, in technical detail, how Witina AI is built and where your secrets live. You can confirm how it handles credentials by running it 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. We don't store your device passwords in our cloud, so there's nothing there to leak, subpoena, or breach.
In the cloud
We don't store your device passwords here.
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
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, and you can audit that mapping.
Runs where you want
Appliance, VM, or container, including a fully self-hosted single container. Credentials are handled the same way in every option.
Discovery
Quiet by default
Bringing a network online shouldn't set off your own alarms. Discovery starts passive. It listens to what devices already announce on the wire (DHCP, LLDP/CDP, mDNS) instead of 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. A complete audit log records who did what, when, and why.
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 is that you can run it yourself, on your own hardware, and watch exactly what it does and doesn't send. You don't need an account, and nothing comes to us. The self-hosted edition stores and relays credentials exactly as the cloud does, so you can check that for yourself.
We're an early, pre-audit company and we won't pretend otherwise. There's no third-party certification to wave yet. What we do have is an architecture that keeps your secrets on your side, and a copy you can inspect end to end.