Vault Agents — Dashboard

Overview

The Dashboard shows a status card for every vault agent registered with this console. Each card reflects the most recent heartbeat received from the agent. It also provides actions to manage the agent's key and registration.

Agent status

Status	Meaning
ONLINE	The agent is running and heartbeating normally.
DEGRADED	Reserved. The agent can report reduced capacity, but current builds do not raise this status on their own.
OFFLINE	No heartbeat was received within the expected interval. The agent may be down or unreachable.

Card information

Each card shows:

• Agent name: the display name set during registration, taken from the key name used at install time.
• Vault Agent label and the current status badge (ONLINE, DEGRADED, or OFFLINE).
• Version: the JAR version the agent is running, for example v1.0.590.
• IP, hostname, and short Agent ID: a line below the badges.
• Health pills (ONLINE agents only): CPU%, JVM CPU%, Heap%, Disk free, and Thread count.
• Heartbeat every Nmin and Next Heartbeat countdown. The countdown turns red when the heartbeat is overdue.
• Last seen: a relative timestamp of the agent's last contact. This is its last heartbeat or, while it runs a sync, its last sync-status check (every minute). A long sync therefore never looks like a missed heartbeat.

The card can also show these badges:

Badge	Meaning
Version Mismatch (amber, warning icon)	The agent's running version differs from the hosted JAR. This triggers alarm VA-004.
Upgrading… (blue, spinner)	A self-upgrade is in progress.
PQ-Encrypted ✓ (blue, shield icon)	Post-quantum encryption is active for this agent. See Post-Quantum Encryption.
Agent→Console ✗ (amber, shield icon)	Shown on every card while the console's own identity key is unavailable. This agent cannot encrypt what it sends to the console. See Console identity key.

Heartbeat interval

Each agent card has an inline heartbeat interval editor at the bottom.

Control	Description
Input	The interval in minutes. The default is 120 min (2 hours), and a newly registered agent gets it. An interval you set here is never changed by an upgrade or by the agent re-registering. The minimum is 1 minute, enforced server-side.
Set	Saves the interval. It is delivered to the agent in its next heartbeat response. The agent then sleeps for the new duration between check-ins.

Use small values, such as 1–5 minutes, for troubleshooting only. Every interval change is recorded as a HEARTBEAT_CONFIG message in the Quantum Trust Protocol Audit Log tab, which creates a full audit trail.

The Next Heartbeat countdown pill on the card reflects the configured interval.

Offline detection

The console marks the agent Offline (alarm VA-001) when it has not checked in for 1.5 × its heartbeat interval. That is 3 hours at the 2-hour default, or 90 minutes at 60 minutes.

After you shorten an interval, the agent keeps sleeping its previous interval until its next check-in, because that is when it receives the new one. Until then, the console allows for the previous, longer interval instead of flagging the agent.

info

Each heartbeat opens the vault network briefly. A shorter interval also means more airgap openings per day.

Card actions

Each agent card has up to four action buttons in the top-right corner.

info

Per-device credential delivery (switch and ObjectScale passwords) is managed on the Vault Device Management tab, not here. Use the Send button on individual device rows to push ML-KEM-1024 encrypted credentials to the vault agent for each device.

Configure (chevron icon, blue)

This button expands an inline config panel below the card. The panel has these sections:

• Airgap Switches
• Console Topology
• Key Rotation Schedule

Airgap Switches

This section is read-only. It lists the switches this agent shuts and re-opens to close and open the airgap, one box per switch. Each box shows:

• Name
• Protocol (RESTCONF or SSH CLI)
• Address and port
• Interfaces
• Username
• Password status: not set, waiting for agent, or delivered to agent
• Mode: Enforce, or Log only — airgap NOT enforced
• Trust: pinned certificate, CA certificate, pinned host key, or not set

Switches are added and changed only on the Vault Device Management tab. Manage switches takes you there. If no switch is listed, this agent has no airgap switch yet.

If the agent reports that it could not confirm an airgap close (alarm VA-007), a red Airgap close NOT confirmed box appears here. It shows the agent's last message and a Retry close now button.

• The agent retries every 60 seconds on its own.
• Retry close now makes it retry at its next check-in. This is useful right after you fix the cause.
• The box goes away once the close is confirmed.

Console Topology

This setting (consoleInVault, default Out-of-vault) defines whether the console shares the vault-side network with this agent's copy agents. The console sits outside the vault, on the production management network. Choose In-vault only after you consult support.

Option	Behavior
Out-of-vault (default)	The link between the copy agents and the console is severed during a closed-airgap period. Copy agents buffer heartbeats locally and replay them after the vault agent's next open cycle restores reachability.
In-vault	Copy agents heartbeat the console directly and continuously, as in normal (non-vault) operation. Heartbeat buffering, spool, and replay are never used. Use only after you consult support.

warning

Console Topology is locked while Vault Mode is active. If this vault agent has any protection group in Vault Mode, the checkbox is disabled and the console rejects the change server-side.

To change it:

1. Go to the Vault Data Sync Dashboard tab and deactivate Vault Mode for this agent.
2. Change the setting here.
3. Reactivate Vault Mode.

The Switch to Vault Mode screen shows this setting as a read-only confirmation, with a Change link that jumps straight here.

Key Rotation Schedule

This section holds:

• The automatic S3 access key rotation interval, drain window, and auto-delete-on-drain behavior.
• The S3 Key Status panel, with the Provision, Rotate, and Delete Drained Key buttons.
• An optional ObjectScale username and password override for key provisioning.

Revoke & Regenerate Key (key icon)

This button revokes the agent's current X-Agent-Key and generates a new one. Use it if a key is compromised.

The agent is offline until its /opt/argus-agent/.argus-vault/config.json is updated with the new key. The new key is shown once in an alert dialog, so copy it immediately.

Trigger Self-Upgrade (up-arrow icon, amber)

This button is shown only when there is a Version Mismatch and the upgrade state is Idle.

It opens an inline amber confirmation bar inside the card. Click Upgrade to start, or Cancel to dismiss. The agent downloads the hosted JAR, verifies its SHA-256, applies it, and restarts.

Remove Agent (trash icon, red)

This button opens an inline red confirmation bar inside the card. Click Remove to delete the registration and revoke the key, or Cancel to dismiss. The agent daemon stops authenticating.

Use this to clean up agents that have been decommissioned.

Post-Quantum Encryption

When a PQ-Encrypted ✓ badge (blue, shield icon) appears on an agent card, post-quantum encryption is fully active for that agent. This means:

• The agent completed the two-phase registration process and uploaded its ML-KEM-1024 post-quantum public key to the console.
• Every credential bundle pushed to that agent is encrypted using ML-KEM-1024 key encapsulation, a NIST-standardized post-quantum algorithm (FIPS 203). Only the agent's private key, stored on the vault host, can decrypt the bundle.
• For air-gap switch passwords, the console never stores plaintext. It stores only the encrypted ciphertext, and only the vault agent can decrypt it. Other credentials are not sealed for the vault agent: the console can decrypt them. See Credential storage on the console.

The badge covers the console-to-agent direction. Traffic in the other direction, which is QTD log uploads and device health reports from the agent, is encrypted with the console's own ML-KEM-1024 public key. Each agent receives that key at registration and again with every heartbeat response. That direction depends on the console identity key described next.

Console identity key

The console holds its own ML-KEM-1024 keypair. The key is stored encrypted at rest on the console and is bound to this appliance's identity.

Warning banner: Agent > console encryption unavailable

This amber banner appears above the Vault Agents sub-tabs when the console could not load or create its key. While it is shown:

• Vault agents cannot send encrypted log uploads (Logs tab) or device health reports. The console rejects them and records them as FAILED on the Quantum Trust Protocol Audit Log tab.
• Every agent card shows Agent→Console ✗ next to PQ-Encrypted ✓.
• Console-to-agent traffic (credentials, settings, commands) is not affected.
• Alarm SY-004 is raised. It clears itself once the key is available.

The console retries every 5 minutes, and immediately when you click Refresh. The banner shows the exact reason.

A file the console cannot read, or one written by a newer console version, is left untouched. Fix the cause and the console picks it up on its next retry.

Notice: Console identity key regenerated

This blue notice is shown for 24 hours. It means the key file existed but could not be used. Typical causes are a console hostname that changed after the key was created, or a damaged file.

The console keeps the old key file as a timestamped backup next to it and creates a new key. Alarm SY-006 (informational) records the event.

No action is needed. Agents pick up the new key on their next heartbeat. A log upload or device health report sent before that is rejected once.

info

The console's software delivery key is never replaced this way. See Setup & Settings > Security > System Public Key.

Why ML-KEM-1024?

ML-KEM-1024 (Module Lattice Key Encapsulation Mechanism, security level 5) is the highest-security variant of the CRYSTALS-Kyber algorithm, standardized by NIST in FIPS 203 (2024).

It resists attacks from large-scale quantum computers. Classical algorithms such as RSA or ECDH become vulnerable once sufficiently powerful quantum hardware exists.

Property	Value
Standard	NIST FIPS 203 (ML-KEM)
Security level	Category 5 (AES-256 equivalent quantum security)
Public key size	~1,568 bytes
Encapsulation size	~1,568 bytes
Implementation	Java 25 JEP 496, native JCA, no external libraries
Symmetric cipher	AES-256-GCM (authenticated encryption, 128-bit tag)
Key derivation	Standard SHA-256 based key-derivation function

How it works

1. At registration, the agent generates an ML-KEM-1024 keypair on the vault host. The private key is stored locally on the vault host, encrypted at rest and bound to that host. The public key is registered with the console.
2. When you push credentials, the console performs an ML-KEM encapsulation against the agent's public key. This produces a 32-byte shared secret and a 1568-byte encapsulation value. The console derives an AES-256-GCM key from the shared secret and encrypts the credential payload with it.
3. The encrypted bundle is stored in the console database and delivered to the agent on its next heartbeat.
4. The agent decapsulates using its private key to recover the shared secret, re-derives the same AES-256-GCM key, and decrypts the payload.

Credential storage on the console

The claim that only the vault agent can decrypt a credential is true for air-gap switch passwords only. The console cannot decrypt those.

All other credentials are AES-256 encrypted in settings.json, with a key kept in a plain file on the console (.keystore). The console can decrypt them. These credentials include ObjectScale management credentials, vault service-account keys, SSH credentials, ClickHouse credentials, and SMTP credentials.

If the badge is absent

If a registered agent does not show the PQ-Encrypted ✓ badge, the agent has not yet registered its post-quantum public key. Credential push is not available for that agent until it does.

The agent generates its keypair and uploads the public key when it registers. It does this again at start-up if its key file is missing or unreadable.

1. Restart the agent service on the vault host with systemctl restart argus-vault-agent.
2. Check the agent log.
3. If the badge is still missing after the restart, the agent log shows that it could not create its key. Register the agent again by installing it again with a vault key from the Install tab.

Refresh

Click Refresh to reload the latest agent list from the server. The dashboard does not auto-refresh. Click Refresh after installing a new agent to see it appear.

No agents registered

If no vault agents appear, use the Install tab to generate a vault key. Then run the one-liner install command on your vault host. Once the agent starts and registers, it appears here.

Related tabs

• Vault Device Management: per-device credentials and health.
• Target Auth Service Accounts: service account ownership (console or agent) and key rotation.
• Quantum Trust Protocol Audit Log: the full encrypted message history for the agent.
• Logs sub-tab: log level, upload interval, retention, and archive history.