Security
Security at Sovereign
Policy administration holds the most sensitive records an insurance operation has: personal information, premium, cash, and the filings you answer to a regulator for. Here is how the engine protects them.
Security program
Security is handled as an engineering practice, not an annual checkbox. Any change that touches authentication, tenant data, payments, or personal information is reviewed for its access-control impact before it ships, and the enforcement point is always the server and the database — never the screen.
Tenant isolation
The licensee is the tenancy boundary. Every request derives its identity and scope from the authenticated session, never from a value supplied by the browser, and tenant tables are protected by database row-level security policies in addition to server-side checks. Hiding a button or filtering a list in the interface is not treated as access control.
Access control
Access is granted by role, scoped to the licensee, carrier, program, or agency the user is entitled to, and issued on a least-privilege basis. Staff, agency, and policyholder channels are separate surfaces with separate rules. Sessions expire on idle and again on an absolute ceiling, so an unattended browser does not stay signed in.
Data protection
All traffic runs over TLS. Sensitive policyholder identifiers — VIN, driver license number, and date of birth — are encrypted at rest with authenticated encryption and are masked when displayed in portals. Credentials and processor keys live in a managed secret store; they are never placed in the application bundle, in configuration rows, or in source control.
Payments
Sovereign does not store card numbers or CVV. Payment instruments are handled by the payment processor, and the platform retains only the processor's token or customer reference. Amounts owed are always computed on the server from the policy's own schedule, never from a value posted by the client.
Auditability
Every premium-bearing transaction is stamped at booking with its full dimension set — coverage, carrier, program, state, filing, filing version, producer, treaty, effective date, and equity position. Published filing versions are immutable, in-force policies stay pinned to the version that rated them, and ledger records are never edited in place. Corrections are booked as new entries so history reconciles.
Infrastructure and monitoring
The platform runs on managed cloud infrastructure with automated database backups and point-in-time recovery. Automated dependency and configuration scanning runs against the deployed application, and findings are triaged as engineering work rather than deferred to a report.
Responsible disclosure
If you believe you have found a vulnerability, email support@sovereignautoengine.com with enough detail to reproduce it. We acknowledge reports and will keep you updated while we investigate. Please do not test against production data belonging to a live customer.
Certifications and evidence
We state only what is true today. Sovereign Auto Engine has not completed a SOC 2, ISO 27001, or comparable third-party attestation, and we do not claim one. The practices described on this page are the controls we operate; where a formal audit is required for your program, tell us during discovery and we will scope it with you.
Platform-generated observations about the current published deployment are available on the hosting provider's trust center.
Security questions or a vendor review questionnaire? Email support@sovereignautoengine.com.