Dealer data security, built into the platform

At the database level. Every tenant table is governed by Postgres row-level security, and the application connects under a database role that cannot bypass those policies. Each query runs inside a transaction scoped to your dealer ID, so a query that isn’t correctly scoped to your dealership returns nothing rather than another dealer’s records. It’s a hard boundary, not a convention.

The most sensitive identifiers — your dealership’s EIN and each customer’s date of birth and driver’s-license number — are encrypted at rest with AES-256-GCM (authenticated encryption) at the data-access boundary, so they’re stored as ciphertext. Note this is targeted field-level encryption for those fields plus MFA secrets; we don’t claim blanket encryption of every column in the database.

Not today — and we’d rather be straight about it. There are four fixed roles (owner, manager, sales, accounting) that gate what staff and the AI can do. There is no custom permission builder or per-field permission editor yet. If your team needs finer-grained control than four roles provide, this may be a current limitation for you.

No. We do not currently offer single sign-on (SSO/SAML), SCIM user provisioning, or a surfaced SOC 2 attestation. Sign-in security is email/password plus optional TOTP multi-factor authentication. If your procurement process strictly requires SSO or a SOC 2 report, we’re not there yet — independent and BHPH dealers are our core ICP, and we’ve prioritized accordingly.

Yes. Every meaningful change is recorded in an append-only audit log so you can see who changed what and when. For data requests, there’s a per-dealer data-subject (DSAR) export. We are not a law firm and don’t provide legal or compliance advice — you remain responsible for how you handle and respond to data requests under applicable law.