The AI firewall is a security layer built into Hermetry. It collects security signals from every part of the platform (sign-ins, API keys, members, devices, settings changes and more), scores what each actor does, groups suspicious activity into incidents and explains every one. This page explains what you see and what you can set.
You need the Admin role. The pages are AI firewall (address /admin/ai-firewall), Security incidents (address /admin/ai-firewall/incidents) and Settings > AI firewall (address /admin/settings/ai-firewall).
What it watches
The firewall listens to signals that modules register, for example: failed and unusual sign-ins, account locks, refused permissions, API key failures and anomalies, membership and role changes, settings changes, device credential changes, refused device logins and touched decoys. Each signal has a severity and a starting weight. Signals on the AI firewall page lists every kind your organisation produces, with its severity, the kinds of actor it is about, and which personal data its attributes carry.
Detectors and rules score each actor (a person, an API key, a device, an address) against its own normal behaviour. When a score is high enough, an incident opens.
Security incidents
Open Security incidents: “What the AI firewall noticed, actor by actor. It only observes: nothing here is acted on until a person decides.”
Each row is one actor’s incident, with its severity, status, detectors, actor kind and last activity. Filter by status, severity, detector, actor and traffic; search; choose columns.
| Severity | Peak score |
|---|---|
| Low | under 40 |
| Medium | 40 to 59 |
| High | 60 to 79 |
| Critical | 80 and over |
The severity is that of the peak score and never drops while the incident lives.
Open a row to see:
- Why it was flagged: the detectors that held, with their description, strength and evidence, and the largest contributions as plain sentences with their points.
- The score timeline.
- The actor’s events. Actor history shows the actor’s other incidents and its events of the last 7 days (with addresses, for members who may read security events).
Work an incident
| Action | Effect |
|---|---|
| Acknowledge | You are on it. If the severity rises later, it opens again. |
| Resolve | “The incident closes and its alert resolves. A later detection of the same actor opens a new incident; you can reopen this one from its row.” |
| False alarm | Closes it and tells the firewall the pattern was harmless here. |
| Reopen | Opens a closed incident again. |
“Was this a real attack?” Your verdict is an example the firewall learns from and tunes its thresholds with for your organisation. An incident that stays quiet for a day, or is older than 7 days, closes as “Went quiet”.
Every status change is written to the audit log (ai_firewall.incident_status_changed).
Decoys
Hermetry keeps decoys in every organisation: a fake API key, fake member and key record ids, and plausible old admin paths. Nobody legitimate uses them, and they appear in no list, count or export. Touching one answers exactly like a missing item and raises a critical signal about the caller. Decoys on the AI firewall page lists them.
Actions and modes
The AI firewall page lists the Actions the firewall could take, such as ending a session, suspending a membership or switching off an API key. “Every action only observes until you choose otherwise.” For each action you choose a mode:
| Mode | Meaning |
|---|---|
| Observe | Records what the action would have done. The default for every action. |
| Suggest | Each run waits for a person to approve it. |
| Auto | Runs on its own, within its time limit and hourly budget, and can be undone. Every switch to Auto asks for confirmation. |
Rules that always hold:
- An action that cannot be undone never runs as Auto: “A person approves every run of this action; it cannot run on its own.”
- Actions on devices start in Suggest. Revoking a device’s credential, ending its connection and revoking its certificate are Suggest-only. Disabling a device (it can be undone) runs on its own only if you set it to Auto.
- Some actions are account-wide (locking an account, banning an address, forgetting trusted devices, forcing a new password). Their mode is chosen by Hermetry for the whole platform, not per organisation.
In development: carrying out actions (the approval queue for Suggest, automatic runs, undo and their notifications). Today the firewall observes and records incidents; choosing a mode prepares how it will act.
Settings
Settings > AI firewall (AI Firewall Settings: “What the firewall may do on its own, and how long it keeps security events”):
| Setting | Default | Meaning |
|---|---|---|
| Stop the firewall’s actions in this workspace | Off | “While on, the firewall only observes here: it proposes nothing and runs nothing on its own.” Security events are still recorded, and the ordinary lockouts and bans still work. |
| Mode of an action you have not set | Observe | Observe or Suggest. Automatic runs are switched on one action at a time, never as a default. |
| Keep security events for (days) | 90 | 7 to 365. “Stored security events, closed incidents and finished actions older than this are deleted every night.” |
| Allow the firewall to block sign-ups from a network | Off | Off: sign-up protection stays soft (e-mail verification, a security check, an administrator’s review). On: the firewall may also refuse sign-ups from a network. |
Changing a mode or a setting is audited; a switch to Auto is a high-severity audit row.
Privacy
The firewall processes security data under legitimate interest. Counters and baselines use keyed hashes, not names. An incident keeps the actor’s id so a person can act on it. Incident timelines and explanations hold feature names and numbers only. Addresses are kept with the events and deleted with the retention. When a person’s data is erased, their incidents lose the actor and close as “The person was erased”, and their baseline is deleted. Incidents are part of the organisation export. See Privacy and data erasure.