Security
Your shop's data stays yours.
Every shop runs in its own isolated tenant. Sign-in uses MFA and hashed sessions. Integration credentials are encrypted at rest. Access follows role permissions, and every named action lands in the shop's audit log.
What is in place
Five controls, in production today.
Tenant isolation, MFA and secure sessions, encrypted credentials, permission-based access, and audit logging. The sections below show how each one works.
Access
Every request runs as one shop.
Session, principal, and capability gate are the same path for owner, advisor, and read-only work. Authorization is checked on the server before any lookup, write, or provider call.
Authorization rule
Authorization is server-side. Every request carries one shop and one set of permissions.
Tenant isolation
Shop-scopedEvery verified session becomes a principal bound to one shop. Queries bind that shop ID last, so nothing in a request body or URL changes which shop a caller sees.
Roles and capabilities
Capability-gatedOwner, Admin Advisor, and read-only map to explicit capability families. Routes and APIs both check the capability for the method. Read permission and write permission are granted separately.
Sessions and MFA
Hashed secretsSession secrets are random and stored only as hashes, with idle and absolute expiry, privilege-version checks, and revocation. Authenticator apps, recovery codes, and passkeys are in place. Security-sensitive actions require authenticator or passkey assurance.
- 01
Authenticate the session
The browser holds an HttpOnly session cookie. The API stores only the hashed secret and rejects expired, revoked, or privilege-changed sessions.
- 02
Build a shop-scoped principal
The session becomes a principal bound to one shop, one account, and the capabilities of that membership.
- 03
Gate the route
The route checks the capability for the HTTP method before any lookup, write, provider call, or audit write.
- 04
Record named actions
Named staff writes, support-console views, and portal issuance land in the shop audit log. Incident-control and provider events write as security events from an allowlisted catalogue with integrity metadata.
Data
VehicleDesk runs the day. Shopmonkey stays the system of record.
The sync brings supported Shopmonkey records into the shop's own tenant. Integration credentials are encrypted before storage and stay on the server.
What VehicleDesk holds and what stays in Shopmonkey
Shopmonkey
System of record
Repair orders, invoices, payments, and the source customer and vehicle records live in Shopmonkey and sync into VehicleDesk.
- Repair and financial records
- Provider-owned Shopmonkey credentials
- Source history, synced continuously
VehicleDesk
The shop's day
Staff workflow, sessions, encrypted integration secrets, and the shop audit log live here.
- Follow-ups, workflow state, and messaging
- Encrypted, server-side integration secrets
- Shop-scoped audit records and security events
Controls
The security surface, control by control.
Each row is a control in production. Ask us for the current security summary during your demo.
VehicleDesk security controls and what each one protects
| Capability | Mechanism | What it protects |
|---|---|---|
| Tenant isolation | Authenticated work runs as a shop-scoped principal. Object lookups include both identity and shop ID. | Shop data, credentials, and audit history stay inside the tenant that owns them. |
| Role capabilities | Owner, Admin Advisor, and read-only map to named capability families. Method-aware gates separate read from manage. | Protected data stays out of values, counts, and errors for anyone without the capability. |
| Sessions | Random session secrets are stored only as SHA-256 hashes. Idle expiry, absolute expiry, privilege-version checks, and staff-visible revocation apply. | A password, privilege, or membership change invalidates every open session for that account. |
| MFA | Authenticator apps, recovery codes, and passkeys. Enrolled members complete an MFA challenge at sign-in. Workspace administrators see per-member enrollment. | Security-sensitive actions require authenticator or passkey assurance in the current session. |
| Provider credentials | Integration secrets are encrypted with AES-256-GCM under a tenant-bound context before storage. Rotation is shop-scoped and records conflicts instead of overwriting. | Secrets stay server-side. They never reach the browser. |
| Rate limiting | Public, staff, admin, messaging, and finance routes use Postgres-backed limiters. Login and MFA have dedicated IP and challenge limits. AI requests have per-user, per-shop, and global budgets. | A limited request returns an explicit rate-limit state and writes a security event. |
| Edge and browser policy | The public site and the app publish content-security, frame-denial, and referrer policies. API mutations check origin, Fetch Metadata, and CSRF. | Cross-site requests and embedded framing are stopped before they reach shop data. |
| Audit logging | The shop audit log records named staff writes, support-console views, and portal issuance. Incident-control and provider events write to an allowlisted security-event catalogue with integrity metadata. | Every named action carries who, what, and when for the shop that owns it. |
| Backups | Backup runs write encrypted, immutable evidence records. | Every backup run is recorded and verifiable. |
| Incident containment | Preapproved switches block messaging, AI, sync, webhooks, exports, support access, public booking, and portal issuance on demand. | A blocked operation returns an explicit unavailable state and records a security event. Shop data stays as it was. |
Sharing
People send. AI drafts. Support access is timed and logged.
Customer contact, support diagnostics, and portal sharing are explicit staff actions with recorded bounds.
Temporary support access
Owner-approvedA shop owner approves a support operator for a set window, 15 minutes to 8 hours, limited to readiness, health, audit, and job evidence. Every view carries a case reason, is read-only, and lands in the shop's audit history.
See support accessCustomer portal links
Expiring, revocableOwners and Admin Advisors issue scoped, expiring, revocable read-only links for customer-safe records. Internal notes, margins, payment handling, communications, reviews, and other customers stay private.
AI drafts. People send.
AdvisoryAI receives only the context it needs, treats synced text as untrusted, validates its output, and runs under request budgets. It drafts talk tracks and guidance. Consent, eligibility, approval, and customer contact stay deterministic application decisions.
Incident containment
Explicit blockIncident switches stop a named operation and return an explicit state. The block is recorded as a security event, and shop data stays as it was.
What AI drafts and what a person decides
AI
Advisory drafts
The model receives only the context it needs, treats synced text as untrusted, and returns drafts under request and cost budgets.
- Talk tracks and call guidance
- Validated structured output
- Drafts only, sent by a person
Staff and application
Contact authority
Consent, suppression, eligibility, approval, and delivery evidence are deterministic application checks outside the model.
- Consent and suppression checks on every send
- Shop, channel, and provider gates
- A person approves every customer contact
Vulnerability disclosure
A clear path for good-faith security research.
Report VehicleDesk-owned surfaces using accounts and data you are authorized to use. Stop after demonstrating the issue and report it promptly.
Research scope for VehicleDesk-owned surfaces
In scope
VehicleDesk-owned product surfaces
Public VehicleDesk properties and the authenticated CRM and API, using only your own authorized account and data.
- Tenant isolation and authorization defects
- Authentication, export, portal, and booking issues
- Webhook, integration, messaging, and AI-boundary defects
Out of scope
Third-party and disruptive testing
Shopmonkey, Google, OpenAI, Twilio, Resend, Cloudflare, Railway, GitHub, customer sites, and other third parties are out of scope.
- Denial of service, credential stuffing, or high-volume scanning
- Social engineering, spam, or persistence
- Destructive changes or data exfiltration
Good-faith research bounds and response targets
Good-faith safe harbor
Research must stay bounded and confidential.
Good-faith research that stays in scope, uses authorized accounts and data, avoids harm, stops after demonstrating the issue, and is reported promptly is treated as authorized under the draft policy. It does not authorize unlawful activity or third-party testing, and the legal language still requires counsel review.
- Use only accounts and data you own or are authorized to test
- Stop after demonstrating the issue and report it promptly
- Do not test third-party systems or cause customer harm
Response targets
Operating targets, not a bounty or deadline.
Acknowledgement within three staffed business days, initial triage within seven, and an update at least every 14 staffed business days for accepted reports. These are not guarantees, a bounty, or a remediation deadline.
- Acknowledgement within three staffed business days
- Initial triage within seven staffed business days
- Updates at least every 14 staffed business days while open
How to report
Send a short, non-sensitive email.
Email security@vehicledesk.io with the affected surface, the impact, minimal steps using your own data, and UTC times. Leave credentials, active secrets, customer data, exploit archives, and provider payloads out of the email.
Book a demo
Bring your security questions to the demo.
We walk through tenant isolation, sign-in, credentials, and audit on the live product and share the current security summary.