Security Overview

Our platform is designed around a simple principle: customer environments should be isolated, access should be explicit, and the operational surface area should stay as small as practical. We focus on hardened defaults, managed infrastructure, and role-based access instead of expecting customers to assemble those controls themselves.

Each customer deployment is intended to run on dedicated VPS infrastructure rather than inside a shared customer runtime. That architecture reduces the risk of cross-customer data exposure and gives each organization a distinct operational boundary for its configured channels, integrations, and agent environment.

Our provisioning and hardening scripts are designed to apply a consistent baseline to customer environments, including:

• SSH key-based access instead of password authentication,
• a dedicated `caas` system user with controlled administrative access,
• root SSH login disabled,
• UFW firewall rules with inbound traffic limited to required ports,
• fail2ban for SSH brute-force protection, and
• automatic Ubuntu security updates through unattended-upgrades.

The customer portal uses Clerk for authentication and organization-aware access control. Protected routes require authenticated access, and the application sends security headers such as HSTS, Content Security Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy.

Billing flows are handled through Stripe-hosted checkout and billing portal sessions. We also use server-side API routes and service credentials where elevated privileges are required for operational tasks.

We use encrypted transport for the website, portal, and provider integrations. Customer and operational data stored by our managed providers is protected by the security controls offered by those providers, including encryption and access control mechanisms in their managed platforms.

Within the product, customer organizations define role-based access rules so users only see the connected systems and data their organization has approved for them.

We maintain health-checking and deployment status workflows for customer environments and use error-monitoring tooling to investigate failures. This helps us detect service issues, provision failures, and regressions earlier and respond faster.

CaaS is intended to keep customer deployments and connected business context under customer control. We do not position customer-connected data as training fuel for our own models. Any model provider involved in serving prompts or completions acts as part of the delivery chain for the customer-selected configuration.

We describe our controls as SOC 2-aligned where appropriate, but unless we explicitly say otherwise in writing, that should not be read as a statement that CaaS has completed a formal SOC 2 certification audit.

Security is a shared responsibility. Customers remain responsible for choosing appropriate connected systems, managing internal permissions, validating AI outputs, and protecting credentials on their side of the deployment.

If you believe you found a security issue affecting CaaS, please report it to support@wherk.com. Include the affected URL or component, the steps to reproduce, the impact, and any supporting screenshots or logs you can safely share.