A tenant is one protected application — a site. It is the level most configuration is actually made at, and the thing every event, rule and report is filtered by.
Global → Group → Tenant (site) → Path rule
A site inherits from its group, or from Global if it has none, and overrides what it needs. Everything else in the console hangs off it: events carry a tenant, rules can be scoped to one, reports are generated for one, and the filter bar at the top of the console selects one.
Each card carries the site's name, its domain, its group, when it was created and whether it is active.
Page actions: Add Tenant · search · filter by group · Edit · delete.
¶ How a request finds its site
This is the part worth being precise about, because it is not what most people assume.
The site is decided by nginx, not by the Host header EdgeGuard sees. Each server block names its site:
server {
server_name shop.example.com;
security_check on;
security_tenant_id 7; # ← this is what makes it site 7
...
}
The engine receives that number with every request. The Domain and Domain Aliases fields on the site are how the console names, groups and reports on it — they are not a lookup table. If security_tenant_id is missing or names a site that does not exist, the request is handled with the default configuration rather than that site's.
So: creating a site in the console and not setting security_tenant_id in nginx protects nothing, and the symptom is a site that shows no events at all. The Getting Started page has the full sequence.
¶ Adding one
Click Add Tenant.
- Name — what you will recognise in every list and filter. The domain is the usual choice.
- Domain — the site's primary hostname.
- Group — optional; leave it empty to inherit straight from Global.
- Create.
Then note the site's Tenant ID and put it in the nginx server block. The ID is shown on the site's own page.
¶ The site's own page
Overview → Basic Settings — name, domain, domain aliases (comma-separated; additional hostnames pointing at the same application), description and group. Beside it, Tenant Info: the tenant ID, the group, and a link to the site's path rules.
Security Settings — the same panel as Global, at site level.
The banner says where inheritance comes from — the group if it has one, Global if not — and every field shows whether it is inherited, overridden here, or cleared back to inheriting. Only overridden values are stored on the site.
This tab is where most real work happens: a site in learning mode while it settles, a threshold raised for an application that legitimately posts odd payloads, a category switched off for an API that is nothing but JSON.
¶ Observed software, and what its vendors say about it
Observed software is its own tab rather than a panel in Overview, because what it holds is of a different kind from everything else on the page: inferences drawn from traffic, not configuration and not measurement.
The engine reads version numbers out of the URLs this site's visitors request — WordPress writes its own version into its asset URLs, Drupal does the same, and a library's version is part of the filename its author published. Each row carries how many requests it was seen in, from how many distinct addresses, and one example URL, because the difference between "847 requests from 61 addresses over six days" and "one request from one address" is the difference between evidence and noise, and only the second is what a forged version looks like.
For a site this appliance hosts, the agent's package inventory is a reading and should be preferred over this. This tab is for the applications behind the proxy, which the appliance does not install.
Below the observations sits what each vendor says about them.
This is not a CVE database queried with a guessed version. Each finding is a vendor's own published answer to a question that can actually be asked with the key that is actually available:
| what is known | who is asked | what they answer |
|---|---|---|
| the exact core version | WordPress.org's release list | this release is published as insecure |
| the core branch | drupal.org's supported branches | this branch receives no fixes |
| a library name and version | Retire.js | these CVE identifiers, this version range |
| a plugin or theme slug alone | the WordPress.org directory | closed, or no release in years |
The last row is why a slug with no version is worth having. A count of CVEs for a slug cannot say whether this site is affected by any of them, and would be a frightening number with no decision behind it. "The directory has closed this plugin" and "its last release was in 2014" need no version at all, and both are findings somebody can act on. Asking wordpress.org about a slug also touches nobody's site.
Where traffic cannot give a version honestly, none is invented. A plugin's ?ver= is usually the WordPress core version, because plugins omit the version when they register an asset — so plugins and themes are recorded as present and without a version rather than with the core's number attached to their name.
Each row names its source and links to where that source said it. A finding nobody can check is an assertion.
An empty list has three possible meanings and the page distinguishes them: no correlation pass has covered this site yet; nothing has been observed on it often enough to correlate; or the vendors were asked and report nothing. Only the last is a clean site, and a vendor source that could not be read is said in a banner, because findings it would have produced are simply absent.
¶ Disabling versus deleting
Disabling a site is a real decision at the edge, not a cosmetic one: the engine allows every request for that site and answers with X-Security-Bypass: waf-disabled. The site is still there, still configured, and completely unprotected. It is the right tool for an emergency — a false positive is breaking production at nine in the morning and you need the site working while you find out why — and the wrong tool for anything left overnight.
Deleting removes the site and its configuration. Its events remain, because they are a record of what happened, and they keep the tenant ID they were recorded with.
Neither changes nginx. A deleted site whose server block still carries security_tenant_id 7 keeps sending requests for site 7, which no longer exists, and they are handled with the default configuration.
¶ Verifying
1. The site sees traffic at all. Filter Security Events to it. Nothing at all, on a site with visitors, almost always means security_tenant_id is missing or wrong.
2. It resolves the settings you expect. Open Security Settings and read the inheritance labels rather than the values: "inherited from EU Production" tells you the group is in play; a plain value means this site overrides it.
3. A change reached the edge. Agents pull roughly every 30 seconds.
# A request that should be refused on a protected site
curl -s -o /dev/null -w '%{http_code}\n' \
-H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/140.0.0.0' \
"https://shop.example.com/?id=1' OR '1'='1"
A 403 and a matching event under that site is the whole chain proved: nginx named the site, the engine resolved its settings, the decision was recorded against it.
4. The bypass header is not there. If a site answers 200 to the request above and the response carries X-Security-Bypass: waf-disabled, the site is disabled — not misconfigured.
¶ Where the site level is the wrong tool
- Every site the same → Global Settings.
- Several sites the same → a group.
- One URL inside the site → a path rule.
- One rule on one field → a false-positive exclusion.
- Which agent serves it → Agents, where each agent's site list is set.