# Witina AI — Capabilities

> What the product actually does, feature by feature: discovery and topology, monitoring
> and incidents, change management, and multi-site/multi-tenant organization.

Source: https://witinaai.com/ai/capabilities.md
Part of the Witina AI machine-readable corpus — index: https://witinaai.com/llms.txt
Last updated: 2026-10-21

Witina AI is a multi-vendor network management platform. A gateway inside your network
does the local work; the cloud console is the brain. See
https://witinaai.com/ai/overview.md for the summary.

## Discovery and live topology

- Point a gateway at a subnet and devices and links populate automatically — no
  spreadsheet, no hand-drawn diagram.
- **Passive-first.** Discovery begins by listening to what devices already broadcast:
  DHCP, LLDP/CDP, mDNS. It does not start by scanning. This means bringing a network
  online does not light up your own IDS or hammer gear that isn't yours to touch.
- **Active probing and auto-connect are opt-in**, decided per network.
- You control which credentials are allowed to touch which devices — access is a scoped
  mapping you can audit, not one global admin blob.
- Works across mixed-vendor estates using standards (LLDP/CDP, SNMP, SSH) rather than a
  single vendor's API. See https://witinaai.com/ai/vendors.md

## Monitoring, alerting and incidents

- Metrics and configuration are collected from devices on a polling cycle.
- Thresholds and state changes roll up into **incidents tied to the devices they affect**,
  rather than a flat stream of alerts.
- For the faults it knows, an **expert system names the problem and the fix** — an
  unexpected spanning-tree root, a duplex mismatch, a guard violation, a rogue DHCP server
  and the switch port it is plugged into — instead of showing
  a red dot and leaving diagnosis to you.
- This is deliberately **deterministic**: named rules you can read and reason about. Witina
  does not use an LLM to guess at diagnoses.
- **When the fix is a config change, the incident offers it ready-made**, for example
  turning spanning tree on, adding a missing BPDU guard, or shutting a locked-down port an
  unknown device turned up on. Picking the suggested fix creates a change with the steps filled in, which is then
  sent for approval and can be rolled back like any other. Each step names the device,
  the operation and its variables, which is also what lets an AI agent turn an incident
  into a concrete draft change. See https://witinaai.com/ai/mcp.md

### Device state that is collected

The platform collects and exposes, per device: running configuration and its history,
interfaces, VLANs, the MAC/forwarding table, routes, spanning tree, LLDP neighbours,
wireless state, and the health of the collectors themselves — so you can distinguish
"this device has no VLANs" from "the VLAN collector has been failing for two days".

## Change management

Configuration changes do not happen as anonymous, irreversible edits. A change:

1. Is **planned** as a change management containing device operations.
2. Can be routed through **approvals**.
3. Can be **scheduled**.
4. **Snapshots the device's current state** before touching anything.
5. Applies, then **verifies** the result.
6. Can be **rolled back** to the snapshot if it misbehaves.
7. Leaves a **complete audit log** of who did what, when and why.

Rollback is a whole-configuration restore rather than an attempt to invert individual
commands. Any config in a device's history can also be restored on its own, outside a
change, after a preview of what it changes.

## Organization, scale and tenancy

- An **Organization / Division / Region hierarchy** scopes every record.
- **Overlapping IP spaces** are supported, so two customers or two sites using the same
  RFC1918 ranges do not collide.
- **Gateway failover.** Add gateways to a network and its devices are spread across the
  healthy ones; if one fails, its devices move to the others automatically.
- **Multi-tenancy** so an MSP can manage many customers from one console without their
  data mixing. Access is checked per request against the scope you are acting in. See
  https://witinaai.com/ai/msp.md
- **Bring your own identity**: sign in with your own IdP over standard OIDC / OAuth
  (Authorization Code + PKCE), configured globally or per organization.
- **Activity logging** of user actions, separate from device audits.

## Remote access to devices

From the console, in the browser:

- An **in-browser SSH or telnet terminal** to a device.
- A device's **web UI (HTTP or HTTPS) in the browser**.
- A device's **serial console**, through a console server (SSH or telnet to the server's
  per-device port) or through another host's serial port.
- **Chained SSH bastions**, plus HTTP CONNECT and SOCKS5 proxies, to reach devices the
  gateway can't reach directly.
- **Recorded sessions**, so remote access leaves an audit trail too.

## Technician VPN

The Witina VPN puts a technician's computer on a site's network, through the gateway
already at that site, so they can use their own tools there.

- **WireGuard, with no port to forward.** The gateway and the app each learn their public
  address from STUN servers and punch through their own NAT. The tunnel runs directly
  between the technician's computer and the gateway; VPN traffic does not pass through
  Witina's cloud. Witina's relay, for networks where no direct path can be made, is not
  available yet.
- **Access by policy, default deny.** Nobody connects until a policy names their team. A
  policy covers every site, a division's (for an MSP, a client's) sites, or chosen sites,
  and caps a session at up to 8 hours. Policies add up; there are no deny rules. Roles
  control who can see and change policies, not who connects.
- **Enforced at the gateway.** Each session has its own allow set on the gateway (the
  site's networks and an end time). The gateway holds the end time itself.
- **Split DNS.** Names in a site's DNS domains resolve at the site's DNS servers through
  the tunnel; every other lookup uses the technician's own DNS.
- **Overlapping address ranges.** Each site's networks also get an alias in 100.96.0.0/12
  for the session, so a range that clashes with the technician's own network, or with
  another site that is on at the same time, is still reachable. Names resolve to the alias.
- **Flow records.** Every connection through the VPN is recorded (when, destination, bytes
  each way, and the gateway's address and port as the site saw it), kept per organization
  for 90 days by default. "Who was it" finds the session, user and computer behind a
  connection a site logged. The traffic itself is not recorded.
- **Apps** for Windows 10 and later, Ubuntu 24.04 and later, and Fedora 40 and later or
  RHEL 10, which keep themselves up to date; macOS is coming soon. Sites are turned on and
  off in the browser, several at once.
- Runs on gateways installed from the Witina image (Hyper-V, OVA or ISO), and on gateways
  run with Docker on a Linux host with WireGuard in its kernel; not yet on Kubernetes,
  Docker Desktop, rootless Docker or Podman. Managed cloud only.

## Notifications

Incidents and their resolutions can be routed to destinations — in-app, email, web push to
enrolled browsers, Slack, Microsoft Teams, and generic webhooks — through rules that match
on severity, category and scope. Web push, Slack and Teams are managed-cloud only; the
self-hosted build keeps in-app, email and webhooks.
Rules support grouped conditions, so "Ashburn or Dallas" is expressible rather than
silently matching nothing. There is no SMS delivery.

## AI and agent access

Witina runs a **Model Context Protocol (MCP) server** in the product. Any MCP client —
Claude, ChatGPT, or an agent you wrote — can connect over OAuth 2.1 and read real network
state, then draft a change management. It cannot execute one unless explicitly granted a
separate execute permission, and its permissions can never exceed those of the person who
authorized it. Nine tools are exposed. Full detail and the complete JSON schemas:
https://witinaai.com/ai/mcp.md and https://witinaai.com/mcp/tools.json

## Scope notes

- **Change management support varies by platform.** Discovery and monitoring are broad;
  the set of configuration operations available depends on the device's vendor profile.
  The quickest way to check specific gear is to start free in the cloud and point a
  gateway at it.
- **The expert system covers the faults listed above**, not every possible network
  problem.
- There is **no third-party security certification yet**.

## Related

- Architecture: https://witinaai.com/ai/architecture.md
- Security: https://witinaai.com/ai/security.md
- Vendors and protocols: https://witinaai.com/ai/vendors.md
- Deployment options: https://witinaai.com/ai/deployment.md
- Comparisons: https://witinaai.com/ai/compare-auvik.md,
  https://witinaai.com/ai/compare-prtg.md, https://witinaai.com/ai/compare-domotz.md