Security
Roles and tenant isolation
Workspace roles, responder access, support boundaries, and tenant isolation.
WarnFire separates three kinds of authority:
- Tenant console access controls who may view or administer one customer workspace.
- Responder access controls who may be paged and who may act through the responder app or responder API.
- Service operations access is reserved for authorized WarnFire personnel who operate the service.
These authorities are intentionally independent. Making someone page-able does not grant console access, and issuing a responder token does not grant tenant administration rights.
Tenant console roles
| Role | Intended use | Access |
|---|---|---|
| Viewer | Read-only operational visibility | May read tenant console data. Cannot change tenant state. |
| Admin | Day-to-day tenant administration | May manage operational configuration, integrations, services, schedules, and escalation policies. Cannot manage tenant membership credentials or billing. |
| Owner | Account ownership and recovery | Includes administrator access, plus tenant membership, member credentials and tokens, and billing controls. |
The API role names are tenant_viewer, tenant_admin, and tenant_owner.
WarnFire prevents the last enabled tenant owner from being disabled or demoted. Create and verify a replacement owner before removing the existing one.
Console identity is not on-call identity
The Can be paged setting controls responder participation. The console role controls administrative access. A person may have either capability or both, but one never implies the other.
Either enabled capability makes a distinct person count as a seat. If the responder and console identities use the same normalized email address, WarnFire counts that person once. See What counts as a seat for plan and billing behavior.
Responder access tokens are for an individual responder identity. Do not use them as general-purpose tenant reader tokens. For an automation that needs tenant-level data, create a dedicated console identity with the narrowest supported tenant role and rotate its credential according to the automation’s operating procedure.
WarnFire support access
Service operations access is separate from every customer workspace role. Authorized support personnel use dedicated identities and controlled support paths; customer credentials do not grant service-wide access. Support activity retains the acting identity and selected workspace in the audit trail.
How tenant isolation works
WarnFire applies tenant boundaries in more than one layer:
- Authentication resolves the tenant and role from the credential. A client cannot select another tenant by supplying a different organization identifier.
- Tenant API routes enforce viewer, administrator, and owner permissions before reaching mutating operations.
- Tenant-owned operational tables use PostgreSQL row-level security, and those policies are forced for application access.
- Service operations and tenant access use separate authenticated roles and data-access paths.
- Support actions retain the acting identity and selected tenant in the audit trail.
An integration key is also bound to one tenant and one integration. Use separate keys for separate monitoring sources so access can be revoked without affecting unrelated senders.
Billing restrictions and suspension
A billing restriction preserves read access while rejecting tenant writes with a payment-required response. This lets an owner inspect the account and recover billing without allowing configuration drift during the restriction.
If a tenant is suspended, ordinary tenant sessions are rejected. An enabled tenant owner may still authenticate to reach identity and billing-recovery functions. Restoring billing clears the restriction through the billing recovery path; do not attempt to work around it by changing roles or integration keys.
Operational guidance
- Give people individual accounts; do not share owner credentials.
- Keep the number of tenant owners small, but maintain at least two verified owners where practical.
- Use viewer accounts for dashboards, audits, and read-only automation when the required endpoint supports them.
- Use a dedicated automation identity instead of a human’s long-lived credential.
- Revoke tokens and disable accounts promptly when a person, device, or automation leaves service.
- Review the audit log after support access, role changes, token rotation, and billing recovery.
Follow Add your team to create a person, assign the narrowest console role, and keep sign-in access separate from paging eligibility.