How WorkSecure Works
WorkSecure creates a per-platform alias layer between your employees and every SaaS tool they use. Real identities never leave your Identity Vault — SaaS platforms only ever see relay addresses.
Email Relay Architecture
SaaS Platform
Slack, GitHub, Notion…
Alias Inbox
*@relayworksecure.com
CF Email Worker
MIME parse + QP decode
Supabase Lookup
alias → real email
Resend API
Outbound delivery
Real Inbox
Employee receives
Admin creates a per-platform alias in WorkSecure dashboard. Employee registers this alias on the SaaS tool instead of their real email.
SaaS sends to the alias (e.g. login code, notification). Cloudflare Email Routing catches all @relayworksecure.com mail and routes it to the Worker.
Worker decodes the raw email — extracts HTML body, decodes quoted-printable encoding, injects UTF-8 charset meta tag.
Worker queries Supabase: alias_email → worker_id → real_email. If alias is revoked or unknown, email is rejected.
Worker posts decoded email to Resend API with the real employee email as recipient. No attachment forwarding currently.
Resend delivers from relay@relayworksecure.com to real inbox. Total latency ~2–5 seconds.
ws_workers table
worker_id TEXT PRIMARY KEY -- WD-2026-0001 name TEXT -- Sarah Chen email TEXT ENCRYPTED -- sarah@company.com role TEXT -- Engineer status ENUM -- active | offboarded risk_level ENUM -- low | medium | high
ws_aliases table
worker_id TEXT → ws_workers app_id TEXT -- slack | github | notion alias_email TEXT UNIQUE -- wd-2026-0001-slack@ status ENUM -- active | revoked created_at TIMESTAMPTZ revoked_at TIMESTAMPTZ NULL
What This Architecture Protects Against
OAuth lateral movement
Attacker compromises Slack account → gets only the alias identity → can't use it as OAuth identity on Notion, GitHub, etc. Each SaaS is a separate compartment.
Attrition / stale access
Employee leaves → one-click revoke all aliases → email relay stops immediately across all SaaS tools. No manual deprovisioning tickets per platform.
Attribution gaps
Every alias email is logged at the relay layer. 'Which account was used to reset the GitHub password at 3am?' → instant answer from the alias audit trail.
Phishing blast radius
Employee is phished via their Slack alias → attacker has one alias, not their real corporate email. Can't trigger password resets or login codes on other platforms.
SaaS data breach exposure
If a SaaS vendor is breached and email addresses leak, attackers get alias addresses — not real corporate emails. Alias addresses don't link to anything outside WorkSecure.
Shadow SaaS inventory
Every alias that receives email from an unknown sender appears in the audit log. IT gains passive visibility into which SaaS tools employees are actually using.
Integrations & Compatibility
How WorkSecure connects to on-premises systems, HR databases, and existing identity infrastructure.
On-Premises & Self-Hosted SaaS
The email relay works with any system that can send outbound SMTP to internet domains — including self-hosted apps behind a corporate firewall, as long as outbound port 25/587/465 is open.
Configure SMTP notification server → alias domain. All Jira email events relay normally.
Set System Hooks → SMTP config to deliver to alias. Org invites route through relay.
Email notifications use standard SMTP. Point outbound mail at alias domain.
SMTP settings under Mail Servers. Alias receives space invites + notifications.
Apps that only send to @company.internal addresses can't reach the relay directly. Use an SMTP bridge/relay to forward to the internet relay domain.
SAP can send outbound email via SCOT/SAPConnect. Configure to route alerts to alias domain. SCIM provisioning not supported without custom BAdI.
HR System Sync (Auto-Provisioning)
WorkSecure exposes a REST API so your HR system or identity provider can automatically provision and deprovision workers on hire/terminate events — eliminating manual onboarding in the dashboard.
Workday
Webhook / Calculated Field
BambooHR
Webhooks API
ADP Workforce Now
API Connector
SAP SuccessFactors
Integration Center
Rippling
REST API + Triggers
HiBob
Webhooks
Gusto
Payroll events
Custom HRIS
REST API
On Hire → Provision
POST /api/worksecure/workers
Authorization: Bearer <service-key>
{
"name": "Jane Smith",
"email": "jane@company.com",
"role": "Engineer",
"department": "Platform",
"mfa_enabled": true,
"start_date": "2026-06-01"
}
// Returns worker_id: WD-2026-0042On Terminate → Offboard
PATCH /api/worksecure/workers/{worker_id}
Authorization: Bearer <service-key>
{
"status": "offboarded"
}
// Revokes all active aliases instantly
// Logs WORKER_OFFBOARDED audit event
// Email relay stops for all SaaS toolsImport workers from an HR export via CSV. Required columns: name, email, role, department. Optional: mfa_enabled, start_date. Each row creates a worker and auto-generates a Worker ID.
name,email,role,department,mfa_enabled,start_date Jane Smith,jane@company.com,Engineer,Platform,true,2026-06-01 Ali Hassan,ali@company.com,Analyst,Security,false,2026-06-15
SCIM & IdP Integration (Roadmap)
SCIM 2.0 provisioning support (Okta, Azure AD, JumpCloud) is on the roadmap. This would enable automatic worker sync directly from your IdP directory, replacing manual API calls with a standard SCIM endpoint.
Okta SCIM 2.0
Planned
Azure AD Provisioning
Planned
JumpCloud SCIM
Planned
On-Premises Deployment
Run WorkSecure entirely within your own infrastructure — no cloud dependency, no data leaving your network.
Next.js App Server
- 1.
npm run build - 2.
PORT=3000 npm start - 3.
Or: Docker — node:20-alpine, COPY .next . - 4.
Runs standalone Node.js — no Vercel needed
Supabase (self-hosted)
- 1.
git clone github.com/supabase/supabase - 2.
cd docker && cp .env.example .env - 3.
docker compose up -d - 4.
Update NEXT_PUBLIC_SUPABASE_URL=http://localhost:8000
Email Relay (SMTP)
- 1.
Replace Cloudflare Worker with Node.js forwarder - 2.
Use Nodemailer + IMAP polling or Postfix - 3.
Point alias domain MX records at your server - 4.
Set SMTP_HOST / SMTP_USER / SMTP_PASS env vars
AI / LLM — Replace Cloud APIs with Local Models
WorkSecure uses Anthropic (Claude) and Google Gemini for analysis features. In a fully air-gapped on-prem setup, run a local model via Ollama and proxy it through LiteLLM to present a compatible API surface.
1. Run Ollama locally
# Install Ollama curl -fsSL https://ollama.com/install.sh | sh # Pull a model (e.g. Llama 3 70B) ollama pull llama3:70b # Starts at http://localhost:11434
2. Proxy with LiteLLM
pip install litellm[proxy] litellm --model ollama/llama3 --api_base http://localhost:11434 # Then in .env: ANTHROPIC_API_KEY=sk-anything ANTHROPIC_BASE_URL=http://localhost:4000
On-Prem Environment Variables
# Next.js app NEXT_PUBLIC_APP_URL=https://worksecure.internal # Self-hosted Supabase NEXT_PUBLIC_SUPABASE_URL=http://supabase.internal:8000 NEXT_PUBLIC_SUPABASE_ANON_KEY=<your-anon-key> SUPABASE_SERVICE_ROLE_KEY=<your-service-role-key> # Local LLM via LiteLLM proxy ANTHROPIC_API_KEY=sk-local # any non-empty string ANTHROPIC_BASE_URL=http://litellm.internal:4000 # HRIS webhook auth (you define this) WORKSECURE_HRIS_API_KEY=<strong-random-secret> # SMTP relay (replaces Resend) SMTP_HOST=mail.internal SMTP_PORT=587 SMTP_USER=relay@worksecure.internal SMTP_PASS=<password>
HRIS Webhook Integration
Connect Workday, BambooHR, or any HRIS to automatically provision and deprovision workers on hire and termination events.
Setup: API Key Authentication
Set WORKSECURE_HRIS_API_KEY in your environment to any strong secret. Your HRIS sends this in the Authorization header.
# .env (on-prem) or Vercel environment variables WORKSECURE_HRIS_API_KEY=hris_live_<your-64-char-secret>
New hire → provision worker
Request body
{
"event": "hire",
"employee": {
"name": "Jane Smith",
"email": "jane@company.com",
"role": "Engineer",
"department": "Platform",
"mfa_enabled": true,
"start_date": "2026-06-01",
"hris_id": "WD-EMP-9823"
}
}Response
{ "event": "hire",
"worker_id": "WD-2026-0042",
"worker": { ... } }Termination → offboard + revoke aliases
Request body
{
"event": "terminate",
"employee": {
"email": "jane@company.com",
"hris_id": "WD-EMP-9823"
}
}Response
{ "event": "terminate",
"worker_id": "WD-2026-0042",
"aliases_revoked": 4 }Role/dept change → sync record
Request body
{
"event": "update",
"employee": {
"email": "jane@company.com",
"role": "Senior Engineer",
"department": "Security",
"mfa_enabled": true
}
}Response
{ "event": "update",
"worker_id": "WD-2026-0042",
"worker": { ... } }Full Example — curl
# Hire
curl -X POST https://worksecure.internal/api/worksecure/hris-webhook \
-H "Authorization: Bearer hris_live_<your-secret>" \
-H "Content-Type: application/json" \
-d '{"event":"hire","employee":{"name":"Jane Smith","email":"jane@company.com","role":"Engineer","department":"Platform","mfa_enabled":true}}'
# Terminate
curl -X POST https://worksecure.internal/api/worksecure/hris-webhook \
-H "Authorization: Bearer hris_live_<your-secret>" \
-H "Content-Type: application/json" \
-d '{"event":"terminate","employee":{"email":"jane@company.com"}}'Configuring Your HRIS
Workday
Integration > Calculated Fields + REST Worklet. Trigger on Worker Status change (hire/terminate). Map employee.email from Work_Email, employee.name from Full_Name.
BambooHR
Settings > Webhooks. Add webhook on 'Employee Hire' and 'Employee Termination' events. Map fields in the webhook payload to the WorkSecure format.
Rippling
Automation > Triggers. Use 'Employee hired' / 'Employee terminated' triggers. Set webhook URL to your WorkSecure endpoint, add Authorization header.
HiBob / Bob
Settings > Integrations > Webhooks. Trigger on lifecycle events (hire, terminate). Include work email and full name in payload fields.
ADP Workforce Now
API Connector > Custom Integration. Use Event Notification Service (ENS) to subscribe to worker lifecycle events. Requires ADP API credentials.
Custom HRIS / ERP
Any system that can POST HTTP. Add a job/script that fires on employee status changes. Include Authorization header with WORKSECURE_HRIS_API_KEY.
Deployment Challenges & Mitigations
The three most common objections from enterprise security and IT teams evaluating WorkSecure — and how to address them.
Adoption Friction — Getting middleware into existing IAM flows
Large orgs with mature Okta/Azure AD setups worry about inserting a new identity layer mid-flight. WorkSecure is designed to be additive, not a replacement — it operates at the email relay layer, independent of your IdP.
Phased rollout
Start with high-risk SaaS (Slack, GitHub, Notion) for a pilot team. No SSO changes required — just update the account email to the alias. Expand gradually.
SSO-gated tools
For SSO-only apps (enforced SAML), WorkSecure is complementary: alias protects the account email field while SSO handles login. Both layers coexist.
SCIM readiness
For large orgs needing IdP-native provisioning, the Workers API is SCIM-compatible by design. Okta/Azure AD SCIM 2.0 endpoint is on the roadmap.
No agent / no proxy
WorkSecure requires zero client-side installation. No browser proxy, no VPN integration, no network-layer changes. Pure email-relay middleware.
Relay Performance — Every authentication hop must be rock-solid
An extra hop in the auth flow is only acceptable if it's imperceptibly fast and reliably available. WorkSecure uses infrastructure with 99.99% uptime SLAs at each layer.
~0ms
Cloudflare receives
Anycast — email hits nearest CF PoP worldwide
~50ms
Worker + Supabase
Alias lookup on indexed column
~2–5s
Resend delivery
End-to-end to real inbox
Trust — Routing employee identities through a third-party broker
You're asking companies to make WorkSecure a privileged layer in their identity stack. This requires transparency about data handling, audit capability, and a self-hosted escape hatch.
🏠 Full self-hosting
Deploy your own Cloudflare Worker, Supabase instance, and Resend account. WorkSecure becomes infrastructure you own and control — no data leaves your stack.
🔒 Real email encryption
Real email addresses in ws_workers can be encrypted at rest using Supabase's pgsodium extension. Even a DB breach doesn't expose real identities without the encryption key.
📋 SOC 2-style audit trail
Every action — alias creation, revocation, offboarding — is logged to ws_audit_events with worker_id, timestamp, and outcome. Full attributable trail for compliance reviews.
🔍 Transparent relay code
The Cloudflare Worker source is fully auditable. Security teams can review exactly what data is read, what is forwarded, and confirm no email content is persisted.
Known Risks & Limitations
WorkSecure reduces several attack surfaces but introduces its own. These are the risks you should understand before deploying.
WorkSecure is a single point of failure for email relay
If the Cloudflare Worker, Supabase, or Resend goes down, employees stop receiving SaaS emails (login codes, notifications, resets). Cloudflare Workers have a 99.99% uptime SLA, but this is still a dependency. Mitigation: implement alias health checks and alerting.
The alias → real email mapping is a high-value target
The Supabase ws_workers table maps each worker ID to a real email address. If this database is breached, attackers get the real identity behind every alias. Mitigation: encrypt real email addresses at rest, use row-level security, and restrict service role key access.
Email content passes through the relay
The Cloudflare Worker reads the raw email MIME content to forward it. This means WorkSecure (or whoever controls the worker) can technically see the content of all forwarded emails. Mitigation: deploy your own Cloudflare Worker and Supabase instance so you control the relay infrastructure.
SSO logins bypass alias protection
If an employee uses 'Sign in with Google' or 'Sign in with Microsoft' on a SaaS tool, the alias email is irrelevant — the SaaS receives their real Google/Microsoft identity. WorkSecure only protects email-based accounts. Mitigation: enforce SAML/OIDC through your IdP (Azure AD, Okta) with Conditional Access for SSO-gated SaaS tools.
Alias format may be guessable
The current alias format is `{worker-id}-{app}@relayworksecure.com`. If an attacker knows a worker's ID (e.g. from a data leak), they can guess valid aliases and target them with phishing. Mitigation: add a random token to alias format, e.g. `{worker-id}-{app}-{random6}@relayworksecure.com`.
Email attachments are not forwarded
The current relay only forwards the email body (HTML/text). Attachments are silently dropped. This could cause issues if a SaaS sends important documents (invoices, contracts) to the alias. Mitigation: warn users in the UI and consider using Resend's attachment API for forwarding.
Relay domain reputation depends on Resend
Forwarded emails are sent from relay@relayworksecure.com via Resend. If the Resend sending IP pool gets listed on spam blacklists, forwarded emails may go to spam. Mitigation: use Resend's dedicated IP option, monitor deliverability, and set up DMARC/DKIM properly.
SMS/TOTP-based MFA is not covered
WorkSecure intercepts email-based verification codes. Apps that use SMS or authenticator apps for MFA send codes directly to the employee's phone — WorkSecure has no visibility into or control over those channels.
Frequently Asked Questions
Common questions from security teams evaluating WorkSecure.