Built for a regulated industry, from day one.
iBrokerOS handles sensitive client and health-insurance data on behalf of independent agencies. Here's how we protect it.
Last updated: draft — pending legal review. Questions? security@masonlink.io
Infrastructure & encryption
iBrokerOS runs on Supabase (database, authentication, file storage) and Vercel (application hosting) — established infrastructure providers, not something we operate ourselves. Data is encrypted at rest (AES-256) and in transit (TLS on every connection, including webhooks). Credentials your agency connects to third-party carriers or systems are encrypted individually, per agency, using a key that never leaves our server environment.
Tenant isolation & access control
iBrokerOS is multi-tenant: every agency's data is logically isolated from every other agency's. This isolation is enforced at two layers — in our application code, where every database query is scoped to the requesting agency, and again at the database level through row-level security policies, so a defect in one layer doesn't expose data through the other.
Within an agency, access follows role-based permissions — a producer sees their own book of business; a service team member can service a client but not bind a policy; only an owner or administrator reaches billing and integration settings. We support multi-factor authentication, and accounts with the broadest access are prompted to enable it.
Every action is staged for human approval
iBrokerOS's AI agents draft work — extracting a document, drafting an email, preparing a quote comparison — but nothing is sent, bound, or changed without a person reviewing and approving it first. This is a deliberate design constraint, not a feature toggle.
Data minimization & AI processing
Before any content is sent to our AI provider, sensitive identifiers — Social Security numbers, email addresses, phone numbers, and dates of birth — are automatically stripped from the request. We are working toward a data-processing agreement with our AI provider that would allow this minimization to be relaxed in favor of a fuller privacy guarantee; until that's in place, minimization stays on.
Compliance status
We want to be direct about where we stand rather than imply more than is true.
HIPAA
iBrokerOS is built to handle Protected Health Information (PHI) — the technical safeguards described on this page (encryption, access control, tenant isolation, audit logging) reflect that from the ground up. Business Associate Agreements with our infrastructure providers are in progress; a signed BAA will be available for agencies handling real member health data as part of onboarding. If your agency needs a BAA in place before go-live, tell us and we'll prioritize it.
SOC 2
We have not yet engaged a formal SOC 2 audit. We are actively building toward SOC 2 Type II readiness — the controls a SOC 2 audit would examine (access control, change management, monitoring, incident response, vendor management) are already documented and largely in place; what remains is engaging an independent auditor to formally attest to them. We'll update this page with real dates once an audit is underway.
Audit logging
Every sensitive action in iBrokerOS — who viewed a client's health information, who changed a record, who approved an AI-drafted action — is written to an audit log that cannot be edited or deleted, by anyone, including us. This gives your agency (and, if needed, an auditor or regulator) a reliable record independent of anything that happens in the application layer above it.
Sub-processors
These are the third-party services involved in operating iBrokerOS, and what each one has access to.
| Provider | What it accesses | Note |
|---|---|---|
| Vercel | Application hosting — all traffic passes through it | HIPAA-eligible hosting is available on our plan |
| Supabase | Database, authentication, and file storage — all tenant data | HIPAA-eligible database hosting is available on our plan |
| Anthropic | AI processing — prompts sent to our AI agents | Sensitive fields are stripped from prompts before they're sent (see Data Minimization below) |
| Stripe | Payment and billing information | No health information is ever sent to Stripe |
| Resend | Transactional email (invites, notifications, alerts) | No health information is included in email content |
| Twilio | SMS and voice, only for agencies that connect their own account | Each agency uses its own Twilio account, not a shared iBrokerOS account — that agency's own Twilio plan and BAA status governs, not iBrokerOS's |
| Finch | HR/census data sync, only for agencies that connect it | Used for employer-group benefits census data |
| Stedi | Real-time insurance eligibility checks | Used only when a producer runs an eligibility check |
| Sentry | Application error reports (technical details only) | Configured to exclude cookies, headers, and personal data from error reports |
Incident response
We maintain a written incident-response process covering detection, containment, and notification. If we ever become aware of unauthorized access to your data, we will notify affected agencies without undue delay, consistent with our contractual and, where PHI is involved, HIPAA breach-notification obligations.
Request our security documentation
If your agency's own compliance review requires more detail — our current gap analysis, policy documents, or a live call with our team — reach out at security@masonlink.io and we'll get you what you need.
Questions
See also our Privacy Policy and Terms of Service. For anything not covered here, email security@masonlink.io.