Formerly Shadow AI Guard.Enterprise Compare editionsYour estate data
never reaches us.
Nyxus runs in your own infrastructure. Findings, devices, people and tool names stay there. The subscription check is separate from estate data.
SCROLL TO EXPLORE ↓What leaves your deployment
The receiver makes one HTTPS GET to the registry every six hours. It carries exactly three parameters, plus a random per-install deployment ID.
| Field | What is sent |
|---|---|
| 01Subscription reference | For example, NYX-0007 |
| 02Licence-key fingerprint | Twelve hexadecimal characters of the key’s SHA-256 |
| 03Nonce | 24 random bytes, fresh for each request |
| 04Deployment ID | A random identifier for this installation |
No findings, device names, user names, tool names or counts are sent. Nothing derived from the estate.
The answer is signed and bound to the nonce. An endpoint impersonating the registry cannot claim a licence is active.
What the product collects
- Findings contain usernames, device serials, tool names, account domains and evidence paths.
- Findings deliberately exclude message content, file content and credentials.
The portal joins observations into a more sensitive picture: “this person uses these six tools across these three machines, two on personal accounts”. That picture is more sensitive than any single finding, which is why the portal authenticates.
The identity map associates named people with machines. It is supplied by the deployer, rather than derived, and deserves the same care as the log store.
Licensing, verified offline
Licence keys are claims signed with Ed25519. The private key is held on one machine outside every repository and CI system. The receiver holds only the public half, compiled into the image, and checks the signature arithmetically.
No network call decides whether a key is genuine. An air-gapped deployment reads its own key correctly. The public key is deliberately not configurable through the environment: a deployment that could choose its verifying key could mint itself a licence.
Offline signature verification is distinct from the six-hourly subscription check and its grace period.
If the registry is unreachable
New collection pauses.
New findings and new enrolments pause after fourteen days.
Existing evidence stays accessible.
Everything already collected stays readable. The portal keeps working.
A licence question should not take your estate offline before somebody has had a chance to answer it.
Supply chain
Every image and the chart are signed with cosign and carry an SBOM. The chart pins both images by digest for its release, so moving a tag cannot swap the bytes underneath an install.
Signing does not use a public transparency log. The signature is still verified against the key. Obtain the published image-signing public key, save it as nyxus-images.pub, and sign in to the registry as for an installation.
cosign verify --key nyxus-images.pub --insecure-ignore-tlog=true \
registry.nyxus.co.uk/nyxus-enterprise/receiver:RELEASE
cosign verify --key nyxus-images.pub --insecure-ignore-tlog=true \
registry.nyxus.co.uk/nyxus-enterprise/charts/nyxus:RELEASEReplace RELEASE with the release you are verifying. The flag skips the transparency-log lookup; it does not skip verification of the signature against the key.
Backups
Backups are sealed with a key only you hold and written to storage you own.
Supported releases
The current release and the one before it are supported. Security fixes are backported to the supported previous release, not only the current one.
Reporting a vulnerability
Report through a private GitHub security advisory, not a public issue.
Report a vulnerability privately ↗Further reading
Nyxus maps controls for EU AI Act, ISO/IEC 42001, NIST AI RMF, ISO/IEC 27001 and SOC 2. Nyxus does not hold certification against these frameworks.
Formerly Shadow AI Guard.Enterprise Compare editionsYour estate data
never reaches us.
Nyxus runs in your own infrastructure. Findings, devices, people and tool names stay there. The subscription check is separate from estate data.
SCROLL TO EXPLORE ↓What leaves your deployment
The receiver makes one HTTPS GET to the registry every six hours. It carries exactly three parameters, plus a random per-install deployment ID.
| Field | What is sent |
|---|---|
| 01Subscription reference | For example, NYX-0007 |
| 02Licence-key fingerprint | Twelve hexadecimal characters of the key’s SHA-256 |
| 03Nonce | 24 random bytes, fresh for each request |
| 04Deployment ID | A random identifier for this installation |
No findings, device names, user names, tool names or counts are sent. Nothing derived from the estate.
The answer is signed and bound to the nonce. An endpoint impersonating the registry cannot claim a licence is active.
What the product collects
- Findings contain usernames, device serials, tool names, account domains and evidence paths.
- Findings deliberately exclude message content, file content and credentials.
The portal joins observations into a more sensitive picture: “this person uses these six tools across these three machines, two on personal accounts”. That picture is more sensitive than any single finding, which is why the portal authenticates.
The identity map associates named people with machines. It is supplied by the deployer, rather than derived, and deserves the same care as the log store.
Licensing, verified offline
Licence keys are claims signed with Ed25519. The private key is held on one machine outside every repository and CI system. The receiver holds only the public half, compiled into the image, and checks the signature arithmetically.
No network call decides whether a key is genuine. An air-gapped deployment reads its own key correctly. The public key is deliberately not configurable through the environment: a deployment that could choose its verifying key could mint itself a licence.
Offline signature verification is distinct from the six-hourly subscription check and its grace period.
If the registry is unreachable
New collection pauses.
New findings and new enrolments pause after fourteen days.
Existing evidence stays accessible.
Everything already collected stays readable. The portal keeps working.
A licence question should not take your estate offline before somebody has had a chance to answer it.
Supply chain
Every image and the chart are signed with cosign and carry an SBOM. The chart pins both images by digest for its release, so moving a tag cannot swap the bytes underneath an install.
Signing does not use a public transparency log. The signature is still verified against the key. Obtain the published image-signing public key, save it as nyxus-images.pub, and sign in to the registry as for an installation.
cosign verify --key nyxus-images.pub --insecure-ignore-tlog=true \
registry.nyxus.co.uk/nyxus-enterprise/receiver:RELEASE
cosign verify --key nyxus-images.pub --insecure-ignore-tlog=true \
registry.nyxus.co.uk/nyxus-enterprise/charts/nyxus:RELEASEReplace RELEASE with the release you are verifying. The flag skips the transparency-log lookup; it does not skip verification of the signature against the key.
Backups
Backups are sealed with a key only you hold and written to storage you own.
Supported releases
The current release and the one before it are supported. Security fixes are backported to the supported previous release, not only the current one.
Reporting a vulnerability
Report through a private GitHub security advisory, not a public issue.
Report a vulnerability privately ↗Further reading
Nyxus maps controls for EU AI Act, ISO/IEC 42001, NIST AI RMF, ISO/IEC 27001 and SOC 2. Nyxus does not hold certification against these frameworks.
Formerly Shadow AI Guard.Enterprise Compare editionsYour estate data
never reaches us.
Nyxus runs in your own infrastructure. Findings, devices, people and tool names stay there. The subscription check is separate from estate data.
SCROLL TO EXPLORE ↓What leaves your deployment
The receiver makes one HTTPS GET to the registry every six hours. It carries exactly three parameters, plus a random per-install deployment ID.
| Field | What is sent |
|---|---|
| 01Subscription reference | For example, NYX-0007 |
| 02Licence-key fingerprint | Twelve hexadecimal characters of the key’s SHA-256 |
| 03Nonce | 24 random bytes, fresh for each request |
| 04Deployment ID | A random identifier for this installation |
No findings, device names, user names, tool names or counts are sent. Nothing derived from the estate.
The answer is signed and bound to the nonce. An endpoint impersonating the registry cannot claim a licence is active.
What the product collects
- Findings contain usernames, device serials, tool names, account domains and evidence paths.
- Findings deliberately exclude message content, file content and credentials.
The portal joins observations into a more sensitive picture: “this person uses these six tools across these three machines, two on personal accounts”. That picture is more sensitive than any single finding, which is why the portal authenticates.
The identity map associates named people with machines. It is supplied by the deployer, rather than derived, and deserves the same care as the log store.
Licensing, verified offline
Licence keys are claims signed with Ed25519. The private key is held on one machine outside every repository and CI system. The receiver holds only the public half, compiled into the image, and checks the signature arithmetically.
No network call decides whether a key is genuine. An air-gapped deployment reads its own key correctly. The public key is deliberately not configurable through the environment: a deployment that could choose its verifying key could mint itself a licence.
Offline signature verification is distinct from the six-hourly subscription check and its grace period.
If the registry is unreachable
New collection pauses.
New findings and new enrolments pause after fourteen days.
Existing evidence stays accessible.
Everything already collected stays readable. The portal keeps working.
A licence question should not take your estate offline before somebody has had a chance to answer it.
Supply chain
Every image and the chart are signed with cosign and carry an SBOM. The chart pins both images by digest for its release, so moving a tag cannot swap the bytes underneath an install.
Signing does not use a public transparency log. The signature is still verified against the key. Obtain the published image-signing public key, save it as nyxus-images.pub, and sign in to the registry as for an installation.
cosign verify --key nyxus-images.pub --insecure-ignore-tlog=true \
registry.nyxus.co.uk/nyxus-enterprise/receiver:RELEASE
cosign verify --key nyxus-images.pub --insecure-ignore-tlog=true \
registry.nyxus.co.uk/nyxus-enterprise/charts/nyxus:RELEASEReplace RELEASE with the release you are verifying. The flag skips the transparency-log lookup; it does not skip verification of the signature against the key.
Backups
Backups are sealed with a key only you hold and written to storage you own.
Supported releases
The current release and the one before it are supported. Security fixes are backported to the supported previous release, not only the current one.
Reporting a vulnerability
Report through a private GitHub security advisory, not a public issue.
Report a vulnerability privately ↗Further reading
Nyxus maps controls for EU AI Act, ISO/IEC 42001, NIST AI RMF, ISO/IEC 27001 and SOC 2. Nyxus does not hold certification against these frameworks.