Security

Security model

How WarnFire protects tenant boundaries, credentials, provider callbacks, and sensitive incident data.

WarnFire separates customer workspaces, authenticates administrative access, and preserves an audit trail for operational changes. Security also depends on how each organization manages its integration keys, responder credentials, and incident payloads.

Protect credentials

• Give each monitoring source its own integration key so it can be rotated or revoked independently.
• Store integration keys, provider credentials, and automation tokens in a secret manager.
• Never put an active credential in a screenshot, support ticket, chat message, source repository, or event body. Use a revoked or purpose-made non-active value when a complete example is needed.
• Do not place an integration key in a URL unless a documented provider adapter requires the dedicated URL-key exception. Treat the entire adapter URL as a secret and follow that provider page’s rotation guidance.
• Rotate a credential immediately if it may have been exposed.
• Use HTTPS for every integration and callback endpoint.
• Grant the narrowest console role that lets a person complete their work.

Create service credentials with Services and integration keys , then rotate or revoke a key when needed. Manage responder tokens from Add your team .

Responder access tokens are responder-scoped credentials for the mobile API and responder automations. They are not tenant-wide administrative or reporting tokens. Revoke a token when a device or automation is retired or may have been compromised.

Limit sensitive event data

Monitoring payloads can contain hostnames, internal addresses, customer identifiers, log excerpts, and other operationally sensitive values. Send only the context responders need to make a decision. Keep large records and highly sensitive evidence in the protected source system, and provide an authenticated link when appropriate.

Avoid placing secrets in event titles, summaries, deduplication keys, labels, or URLs. These values may appear in notifications, incident timelines, war rooms, audit records, and delivery diagnostics.

Tenant isolation and access control

WarnFire derives the workspace context from the authenticated identity instead of accepting an arbitrary workspace identifier from the client. Tenant-owned operational data is isolated at the application and database layers. WarnFire support uses separate service identities and controlled access paths.

Workspace roles, responder access, support boundaries, and isolation controls are described in Roles and tenant isolation .

Verify provider callbacks

Delivery callbacks are accepted only through their provider-specific verification path. WarnFire validates supported signatures or signed envelopes, correlates callbacks to durable delivery attempts, and processes repeated provider events idempotently.

Provider acceptance is not proof that a notification reached a person or device. See Delivery evidence for the evidence available from email, SMS, voice, and push channels.

Use Find a delivery attempt to inspect the evidence retained for a specific page without exposing full destinations or message bodies.

Report a vulnerability

Report suspected vulnerabilities to support@simonsayssystems.com . Include the affected feature, observed behavior, and safe reproduction details. Do not include active credentials or access data belonging to another customer.