What Nyxus is

People in your organisation are using AI tools. Some of them you bought. Some
of them they signed up for with a work email, or a personal one, on a laptop
you manage. You can probably name three of the tools. The question Nyxus
answers is which ones are actually in use, on whose machines, under which
account, and what you have decided about each of them.

It is software you run yourself. Two containers in your own cluster or on your
own host, writing to your own log store. Nothing leaves your network except
the check that confirms your subscription.

What it answers

What AI is in use. Every tool a collector, your MDM, your tenant, your
network product or the browser extension has seen, in one register, with the
device and account behind each one.

Who is using a personal account. The single biggest number on most
estates, and the one nobody can produce from an MDM. A laptop with Claude Code
signed into a Gmail address looks identical to one signed into your tenant,
unless something reads the config file and tells you.

What runs without a person. Scheduled jobs and service credentials that
start an AI tool on their own - the agent nobody owns, the key that survives
the person who created it being offboarded.

What you decided, and whether it still holds. Every tool carries a
recorded decision, with an owner and a review date. An approval can carry
conditions, and Nyxus tells you when the estate stops meeting them.

What you can hand an auditor. A signed export of the register, the
evidence behind it, and a mapping to the EU AI Act, ISO/IEC 42001, NIST AI RMF,
ISO/IEC 27001 and SOC 2 for them to confirm.

How it sees anything

Eighteen detection sources across six groups: the collectors on machines, the
browser extension, your Entra tenant, your MDM inventory, your network
product, and the MCP configurations the collectors find. Each answers a
different question, and none answers all of it.

That is the design rather than a gap. An MDM knows what is installed and not
whether anyone opened it. A sign-in log knows somebody authenticated and not
what they did next. A collector knows one machine thoroughly and nothing about
the rest. Putting them beside each other is what makes the picture, and Nyxus
is honest throughout about which source knew which fact.

See How Nyxus is put together and
Detection sources.

What it needs from you

Somewhere to run two containers - Kubernetes or a single host with Docker
Compose. A log store, which is almost always one you already have. A way to
run a script as root on your machines, which is almost always an MDM or RMM
you already have. And an afternoon to pack and push the browser extension.

No agent to install. No proxy in the path of anybody's traffic. No traffic
inspection. See What Nyxus needs to run.

What it costs to run

Less than it looks. The two containers ask for 50m of CPU and 96Mi of memory
each. The volume goes into your log store, and how much depends on the size of
your estate rather than on anything Nyxus decides - findings are throttled at
the collector so a frequently scheduled policy does not flood it.

Where to go next

If you are evaluating it, What Nyxus does not do
is the more useful page, because the limits tell you more than the features.

If you are deploying it, start at
What Nyxus needs to run, then
Kubernetes or Compose.

If it is already running and you want to know what to do first, read
Getting started.