Security · Access control

Role-Based Access Control

SecurityAlert.ai uses a category-based permission model. Each user is granted a level (none / view / manage) for each of 11 product categories. Five built-in role presets cover most cases; admins can also build custom permission blocks per user. Enforcement runs server-side on every API call via Permissions::require(); client-side hidden controls are a courtesy, not a security boundary.

Permission categories

Granted independently per user. The category list is the source of truth for what an admin sees in the user-edit drawer.

Service Alerts

Service status monitoring, alert preferences, alert rules

service_alerts

Monitors

HTTP, ping, TCP, SSL, domain, DNS, and heartbeat monitors

monitors

Certificate Inventory

Certificate list, ownership assignments, OCSP/CRL configuration

cert_inventory

Certificate Posture & Compliance

Cryptographic posture score, policies, compliance reports (PCI/SOC2/NIST)

cert_posture

Brand Protection

Typosquats, dark web, phishing, finding triage

brand_protection

Takedowns

Submit, update status, add notes, delete cases

takedowns

Status Pages

Public status pages, branding, subscriber lists

status_pages

Integrations

Slack, Teams, PagerDuty, Opsgenie, webhooks, API keys, STIX/TAXII

integrations

Team Management

Invite/remove members, assign roles, manage teams

team_management

Audit Logs

View and export audit trail (Enterprise tier)

audit_logs

Billing

Plan changes, payment method, invoices

billing

Built-in role presets

Apply a preset to set a sensible permissions block, then tweak individual categories if needed. Editing any category flips the user's role label to "Custom" but keeps the underlying permission block intact.

Category	Owner	Editor	Certificate Manager	Brand Manager	Auditor (read-only)
Service Alerts	manage	manage	view	view	view
Monitors	manage	manage	view	view	view
Certificate Inventory	manage	manage	manage	view	view
Certificate Posture & Compliance	manage	manage	manage	view	view
Brand Protection	manage	manage	view	manage	view
Takedowns	manage	manage	view	manage	view
Status Pages	manage	manage	view	view	view
Integrations	manage	view	view	view	view
Team Management	manage	none	none	none	none
Audit Logs	view	none	view	view	view
Billing	manage	none	none	none	none

How it shows up

Server-side enforcement on every mutating endpoint. Calls go through Permissions::require($userId, 'category.level'); lacking the permission returns HTTP 403 with a JSON error.
Client-side filtering as a courtesy. Sidebar items and action buttons disappear for users without the matching permission, but the server is the trust boundary.
API keys inherit user permissions. A key minted by an Editor cannot escalate to Owner-only endpoints, even with the admin scope.
Audit log of permission changes. Every preset switch and per-category toggle on the user-edit drawer writes an event to the audit log (Enterprise tier).
SSO + SAML/OIDC on the May-September roadmap. Until shipped, the only authentication source is Auth0 (which already supports federated identity providers via the standard OIDC flow).

Need this for an RFP or SIG questionnaire?

This page is the canonical reference. Quote it when answering access-control rows on SOC 2, ISO 27001, SIG/CAIQ, or your customer's vendor-risk questionnaire. The model has been live since launch and is enforced on every mutating endpoint.

Get a vendor-risk packet