Skip to content

The v1 docs follow nauthera-server's main branch and its 0.x releases on the way to 1.0, so fields and APIs can still change.

v1

NautheraThreatSignalCritical

Docs version v1 (main)Nauthera is pre-1.0, in a design-partner program

A threat signal for one organization is at or above its critical rate.

Meaning

For one organization (the organization label, its ID; empty for the platform's own records), the hourly rate of a threat signal over the last hour (window) reached the critical rate the server's threat catalog publishes in nauthera_threat_threshold_per_hour, for five minutes. The signal is named in signal and grouped in category: credentials, second_factor, tokens, clients, admin or edge. The counts are audit records the signal counts, so the alert sees what audit.level records. At the critical rate this is an attack in progress, or a broken integration failing at attack scale.

Impact

Depends on the signal. credentials and second_factor: user accounts are being attacked and may be locked or taken over. tokens: stolen or guessed tokens, codes or client secrets are being tried, or a relying party is broken and its users cannot sign in. clients: dynamic registration is being abused. admin: someone is probing the admin API without the rights to it. edge: malformed or hostile requests at volume.

Diagnosis

  1. Which signal and organization: the alert's labels; find the organization's slug with the database owner (SELECT slug FROM organizations WHERE id = '<organization>';).
  2. The admin dashboard's Threats page for that organization (/admin/orgs/<slug>/threats) shows the same signal, its thresholds, and links to the audit records it counted.
  3. The rate across the fleet: sum by (organization, signal) (rate(nauthera_threat_signals_total\{job="&lt;name&gt;",signal="&lt;signal&gt;"\}[1h])) * 3600.
  4. In the records: is it one client, one address, one account, or many? A single client after its own deploy or a secret rotation is usually a broken integration.

Mitigation

  • Credential signals: follow NautheraSignInFailureSpike and NautheraAccountLockoutSpike.
  • Second-factor failures or locks: users whose password is known to an attacker; require a password change for the targeted accounts and review their sessions.
  • Token and client signals: identify the client; if it is broken, contact its owner; if its secret may be compromised, rotate it.
  • Admin access denials: check the actor in admin.access.denied records and revoke the credential if it is not one of yours.
  • Edge refusals: block the source at the ingress or WAF.

Escalation

Page the security team now, with the signal, organization, rate and the source the records point to. Tell the organization's administrators when their tenant is the target. If the attack exploits a weakness in the server, report it as Hardening describes, not as a public issue.

Alert runbooks · Generated from internal/runbook/alerts.yaml and operator/internal/runbook/alerts.yaml in nauthera-server.