Security

This tab provides an audit trail of all API activity on the system and manages bearer tokens for programmatic access.

Overview

The Security tab has two independent sections:

• The API Security Audit Log gives visibility into every HTTP request the backend has received. It shows who made the request, what they did, and whether it succeeded.
• API Token Management lets you create long-lived bearer tokens for automation scripts, CI/CD pipelines, or copy agents that need to call the API without an interactive session.

API Access Log

The API Access Log is a paginated table of every API call made to the console backend. Use it to investigate configuration changes, detect unexpected access, and confirm that automation is behaving as intended.

A counter at the top shows total entries and unique source IPs. An amber (rolling — oldest trimmed at 1M) indicator appears once the table approaches the 1,000,000-row cap.

Table controls

Control	Description
Auto-refresh	A toggle in the header. When on, the table re-fetches the current page every few seconds so new requests appear without a manual refresh.
Filter bar	A text box above the table. It filters the visible rows by IP, route, user, or method as you type. The count next to it (N of M shown) reports how many rows match.

Table columns

Column	Description
Timestamp	The date and time the backend received the request, in your local browser time zone.
Source IP	The source IP of the caller. Behind a load balancer, this can be the cluster-internal IP instead of the originating client IP. Configure X-Forwarded-For forwarding on the load balancer to expose the true client.
Method	The HTTP method of the request, such as GET, POST, PUT, or DELETE, with a colored badge per method.
Route	The request path, for example /api/settings/clusters or /api/audit-data/wipe-ecs. Hover over the cell to see the full path when it is truncated.
Status	The HTTP response code returned to the caller. It is green below 400, amber for 4xx, and red for 5xx.
User	The authenticated user or token name associated with the request. Unauthenticated requests show as —.
Auth	The authentication mechanism used. See the values below.
ms	The time in milliseconds the backend took to process the request, from receipt to response.

The Auth column shows one of three values:

Value	Meaning
token (purple)	Authenticated with an API token. It has a key icon, and the token name appears on hover.
session (blue)	Authenticated with a browser session cookie.
anon (gray)	Unauthenticated.

Export to CSV

Export to CSV downloads the audit log as a comma-separated values file. Use it for compliance reporting, offline analysis, or archiving before you clear the log.

The export contains the most recent entries. It does not necessarily include all records if the log has been trimmed.

info

The audit log retains up to 1,000,000 entries. Once that limit is reached, the oldest records are automatically trimmed to make room for new ones.

The CSV export reflects the current contents of the log at the time of download.

Clear Log

Clear Log permanently deletes all API audit log entries. A confirmation dialog is shown before the deletion proceeds.

danger

This action cannot be undone. Export the log first if you need to retain a history.

API Token Management

API tokens are long-lived bearer tokens for programmatic access to the console API. They are an alternative to session-cookie authentication for non-interactive callers.

Field or action	Description
Token Name	A human-readable label for the token. Use names that identify the caller, such as ci-pipeline or mcp-client.
Scope	All tokens created from this dialog are issued with the api scope. See below.
Expiry	An optional expiry date and time. Leave it blank to issue a non-expiring token.
Create Token	Generates a new api-scope token with the given name and optional expiry.
Revoke Token	Permanently invalidates a token.

Token scope

The api scope grants the same authorization an authenticated admin session has on /api/** endpoints, except that it cannot trigger vault operations such as switching to Vault Mode.

• Vault agent keys are provisioned from Vault Operations > Vault Agents > Install and never appear in this UI.
• The MCP server gates which api-scope tokens it accepts through the Allowed Token IDs list on the MCP Server tab. To narrow MCP access, add only the dedicated token ID to that list rather than changing scope.

Create and revoke tokens

The full token value is shown exactly once in the creation dialog. Copy it immediately. It cannot be retrieved after you close the dialog.

Any caller that uses a revoked token receives a 401 response on subsequent requests. Revoke tokens that are no longer needed or that may have been compromised.

Workflows

Investigate a suspicious configuration change

1. Open the API Access Log.
2. Filter or search by the path of the endpoint that was called, for example /api/settings.
3. Check the Timestamp, User, and Source IP columns to identify who made the change and when.
4. If the IP or username is unexpected, revoke any API tokens that may have been compromised.

Create a token for an MCP client or automation script

1. Scroll to the API Token Management section.
2. Click Create Token.
3. Enter a descriptive Token Name, for example mcp-claude-desktop or ci-pipeline.
4. Optionally set an expiry date. Leave it blank for a non-expiring token.
5. Click Create Token in the dialog.
6. Copy the token value from the dialog immediately.
7. Paste the token into the calling tool's configuration, such as an MCP client config or a CI secret.
8. Close the dialog. The token value is not shown again.
9. For MCP only, copy the token's ID into Setup & Settings > MCP Server > Allowed Token IDs to restrict MCP access to that token.

Issue a vault agent install key

Vault agent registration keys are not created here. Open Vault Operations > Vault Agents > Install and follow the on-page instructions. That flow issues a single-use install token bound to a specific agent record.

Export the audit log for compliance review

1. Click Export to CSV.
2. The browser downloads a CSV file with the most recent audit log entries.
3. Open the file in a spreadsheet application, or import it into your compliance tool.

Clear the audit log after archiving

1. Click Export to CSV and confirm the download is complete.
2. Click Clear Log.
3. Confirm the deletion in the dialog.

Quantum Signed Keys

This section provides visibility into the post-quantum cryptographic keys used for Quantum Trust Signed (QTS) software delivery.

Trusted Signing Keys (ML-DSA-87)

The table lists every Superna-issued signing key loaded by this console. QTS packages must be signed with one of these keys to be accepted for installation.

Column	Description
Key ID	The unique identifier embedded in the .qtspkg package manifest. The console uses it to look up the correct public key during validation.
Algorithm	Always ML-DSA-87 (CRYSTALS-Dilithium Level 5, NIST FIPS 204). This is a post-quantum digital signature algorithm designed to resist both classical and quantum computer attacks.
Standard	The NIST standard the key implements, for example NIST FIPS 204.
Status	ACTIVE for production keys. A yellow DEV badge marks the DEV signing key. The console generates it when no keys exist, and loads it on every boot. It is not temporary: it stays trusted after production keys are added. Only packages signed by that console's own key install with it. Shipped consoles run on the DEV key unless support places production keys. Contact support to obtain production keys.

If no signing keys are shown, contact Superna to obtain the current public key set. Place the keys in /data/superna-signing-keys/ on the server. Without a trusted key, QTS uploads fail with UNKNOWN_SIGNING_KEY.

If the console cannot return the signing keys at all, for example because of a server error, the table area shows Signing keys could not be loaded with the reason. Reload the page to retry.

The message "No signing keys loaded" means only that the console genuinely has no trusted keys.

System Public Key (ML-KEM-1024)

This is the console's post-quantum delivery identity keypair. It is generated once per installation and stored encrypted on the console's data disk.

It is used for Quantum Customer Encrypted (QCE) deliveries. In a QCE delivery, Superna encrypts a package exclusively for this installation so that no other system can install it.

Item	Description
Fingerprint	A short identifier derived from the SHA-256 hash of the public key. Share it with Superna to confirm you have the right key.
Algorithm	Always ML-KEM-1024 (CRYSTALS-Kyber Level 5, NIST FIPS 203).
Copy Public Key	Copies the Base64-encoded public key to the clipboard. Share it with Superna when you request a customer-encrypted delivery.
Download PEM	Downloads the public key as a PEM file. Use it for secure out-of-band transmission, for example by email or a ticket to Superna support.

The private half of this keypair never leaves the server. Even Superna cannot decrypt a QCE delivery intended for a different installation.

Ordinary signed (non-QCE) packages are not affected by this key at all.

When the System Public Key is unavailable

The key is stored encrypted at rest on the console and is bound to this appliance's identity. If the console cannot load it, the panel shows System Public Key unavailable with the exact reason in place of the fingerprint.

When this happens:

• Copy Public Key and Download PEM are not offered.
• Alarm SY-005 is raised.
• The console retries automatically every 5 minutes, and immediately whenever you load this panel.
• The Trusted Signing Keys table above is not affected and stays visible.

The most common reason is that the hostname changed after the key was created, for example by re-running cybervault-setup-network --hostname …. The file can then no longer be decrypted.

The console never replaces this key automatically. Its public key is registered with Superna, and customer-encrypted (QCE) packages are built for it.

To recover:

1. Restore the original hostname, which is the one the console had when the key was created. Alternatively, restore the key file from a backup. Then reload this page. The key is picked up immediately, or otherwise within 5 minutes.
2. Only as a last resort, delete the file and restart the console. A new key is generated. Send its public key to Superna, because QCE packages built for the old key can no longer be installed.

If the panel says the key was not created because the machine identity "looks like a temporary placeholder", for example localhost, set the appliance's real hostname. A delivery key is never created under a placeholder name, because it could not be used again once the real name is set.

Tips

• Export the audit log before you clear it. There is no recycle bin or recovery path.
• Every token created on this tab has the API scope, which is full access to the console API. It cannot trigger vault operations. Treat each token as an admin credential. Create one per caller, set an expiry where possible, and revoke it when it is no longer needed.
• Token values are shown only once, at creation time. If a token value is lost, revoke the old token and create a new one.
• The audit log records all requests, including health checks and read-only polling. High-volume sources, such as agents that send frequent heartbeats, add many rows. Filter by path to reduce noise when you investigate specific events.
• If a load balancer sits in front of the console, configure it to forward the X-Forwarded-For header. The recorded IP address then reflects the true client IP rather than the load balancer.