Security Architecture
Most platforms start with convenience and add security later. We started with a question: what's the minimum attack surface that supports full business operations? The answer: one port. One encrypted tunnel. Everything else is behind the firewall.
🔒 Nothing leaves the network unless it's encrypted
Every byte of data — at rest, in transit, and in backup — is encrypted. No exceptions. Data on disk is encrypted with AES-256 full-disk encryption. Data over the network travels through an encrypted VPN tunnel with AES-256-GCM. Backups are encrypted with AES-256 before transfer to our secure secondary location. A stolen drive contains encrypted noise. A compromised backup contains encrypted noise. Nothing is readable without keys that exist only on our controlled infrastructure.
Attack surface comparison
The entire platform is reachable from the internet through a single encrypted VPN endpoint. Port scanners see one listener. No web server. No database port. No API endpoint. Nothing.
| Platform | Public-facing ports | Attack surface |
|---|---|---|
| Typical cloud SaaS | HTTPS + CDN + API gateway + webhooks | Large - multiple TLS terminations, multiple codebases |
| Self-hosted with database | SSH + HTTPS + PostgreSQL + others | Medium - multiple services exposed |
| Help Wizards Platform | 1 (Encrypted VPN) | Minimal - single encrypted tunnel |
Encryption at every layer
At Rest — Full-Disk Encryption
Every drive encrypted with AES-256. If a drive is physically stolen, the data is unreadable. If hardware is decommissioned, the drives contain encrypted noise. Our system uses fault-tolerant, constantly monitored storage so data is always safe, secure, and available. The system requires authentication at boot; an unattended reboot cannot expose data.
In Transit — Encrypted VPN
All remote access uses an encrypted VPN tunnel with AES-256-GCM encryption, TLS 1.3 with RSA-4096 certificates, and perfect forward secrecy via ECDHE key exchange. Every user gets an individual certificate — compromising one doesn't expose anyone else. Certificates can be revoked instantly without affecting other users.
Fault Tolerance & Disaster Recovery
Our system operates continuously in fault-tolerant mode — monitored storage, redundant components, and real-time integrity checking. Our disaster recovery plan is reserved for true natural disasters where the primary datacenter is compromised — our cold site is ready to go. We do not rely on disaster recovery to fix mistakes or recover corrupted data. The system is robust enough to make that unnecessary. Data is always encrypted before transfer to our secure secondary location. No external provider ever sees unencrypted data.
Encrypted Security Vaults
Our system features encrypted security vaults to store sensitive information with privilege-separated access. This information is severely limited and audited on a strict need-to-know basis. Even the AI assistant cannot see, decrypt, or retrieve vault contents — OS-level isolation, not software policy. No third-party vault dependencies. Any client system we deploy can also have this feature.
Your data never leaves without you knowing
Customer data lives on dedicated hardware we control. Nothing leaves the server without explicit, auditable action.
Data Security
All business data - work orders, customers, invoices, equipment records. All uploaded documents and their OCR extractions. All secrets vault data. All audit logs. All session transcripts. All AI memory files. Everything that matters stays on hardware you can walk up and touch.
What leaves (and how)
AI prompts go to the AI provider via TLS 1.3 — minimum context necessary, never full records. Email goes via encrypted API. Fault-tolerant data and disaster recovery components are encrypted before transfer to our secure secondary location. AI providers don't train on API data. No external service ever sees unencrypted data. That's the complete list.
🤖 AI isolation by design
The AI assistant has broad access to business data — it needs that to be useful. But vault contents are the one category where no AI should have decryption capability. Our vault uses OS-level separation: the AI can tell a technician "the information is in the Secrets panel" but it literally cannot decrypt it. A compromised AI session, a prompt injection attack, or even a well-intentioned request cannot extract secrets from a system the AI cannot reach.
What it takes to breach this system
An attacker would need to penetrate three independent barriers - each individually sufficient to protect the data.
Penetrate the VPN
Requires a valid per-user RSA-4096 certificate. No certificate, no handshake, no connection. The server doesn't even respond to unauthorized packets.
Authenticate to the portal
Requires valid user credentials with JWT token authentication. Role-based access controls limit what each user can see and do. Every access is logged.
Decrypt the data
Requires the LUKS passphrase. Even with physical access to the hardware, disk contents are AES-256 encrypted noise without the key.
Access control
Per-user everything
Individual VPN certificates. Individual portal accounts. Role-based access (admin, technician, dispatcher, invoicing). Individual certificate revocation without affecting other users. The system knows exactly who connected, when, and from where.
Full audit trail
Every access, every change, every operation is logged with user identity, timestamp, and IP address. Secrets vault access logs who accessed sensitive information. Portal actions log who viewed, edited, or created records. Audit trail satisfies SOC 2 access logging requirements.
SOC 2 alignment
The platform architecture follows SOC 2 Type II principles including access controls, audit logging, encryption, and change management. Ohio SB 220 recognizes organizations implementing cybersecurity frameworks aligned with industry standards.
| SOC 2 Criteria | How we address it |
|---|---|
| CC6.1 Logical access | Per-user VPN certificates + JWT authentication + role-based portal access |
| CC6.2 Access provisioning | Individual certificate issuance, revocable per user |
| CC6.3 Access removal | CRL-based certificate revocation, portal account deactivation |
| CC6.6 Operations monitoring | Automated health checks, email alerts on anomaly |
| CC6.7 Change management | Version-tracked changes, approval-required workflow, staging-to-production deployment |
| CC6.8 Threat detection | Minimal attack surface, VPN auth logging, full audit trail |
| CC7.2 Incident response | Automated alerts, remote hardware management, documented restore procedures |
| A1.1 Availability | Fault-tolerant storage, UPS-protected power, redundant systems |
| A1.2 Recovery | Local + encrypted offsite backup, verified restores |
| C1.1 Confidentiality | AES-256 at rest, encrypted VPN in transit, encrypted offsite backups, encrypted security vaults |
| PI1.1 Data integrity | File locking, atomic writes, audit trail, version tracking |
How we compare
| Security feature | Help Wizards | Microsoft 365 | Google Workspace | Typical SaaS |
|---|---|---|---|---|
| Encryption at rest | ✓ AES-256 full disk | ✓ BitLocker/service-level | ✓ AES-256 | Varies |
| You control the encryption keys | ✓ Your keys, our managed infrastructure | Microsoft holds keys | Google holds keys | Vendor holds keys |
| Dedicated infrastructure | ✓ Dedicated managed infrastructure | Multi-tenant shared | Multi-tenant shared | Multi-tenant shared |
| Public attack surface | 1 encrypted tunnel | Hundreds of endpoints | Hundreds of endpoints | Multiple endpoints |
| Per-user certificate auth | ✓ Individual certificates | Password + MFA | Password + MFA | Password + MFA |
| No third-party data access | ✓ Zero third parties | Microsoft + partners | Google + partners | Vendor + integrations |
| AI vault isolation | ✓ OS-level separation | N/A | N/A | N/A |
| Physical server access | ✓ Tour our Columbus datacenter | Datacenter you can't visit | Datacenter you can't visit | Unknown location |
| Encrypted offsite backups | ✓ Encrypted before upload | Vendor-managed | Vendor-managed | Varies |
| Verified backup restores | ✓ Regularly tested | Not user-verifiable | Not user-verifiable | Varies |
📍 Our datacenter - Columbus, Ohio
All infrastructure is managed in-house at our Columbus datacenter. Our systems are fault-tolerant and continuously backed up. UPS-protected power, remote hardware management, redundant storage arrays, and backup systems in secure offline storage.
Access to our infrastructure is excruciatingly restricted - limited to key personnel only. Clients are welcome to tour the facility and physically see where their data lives. That's something no multi-tenant platform can offer.
Questions about security?
We'll walk you through the architecture in detail and answer anything your compliance team needs to know.
Get in Touch