Security

The strongest control we have is structural. What we run is the web app: accounts, licences and downloads. What runs your work is the software on your own infrastructure, and your code, specifications, prompts, artifacts and run history never leave it. There is no shared tenancy to escape and no central store of customer source code to breach, because neither exists.

Once installed, the software does not call home. It has no channel back to us and reports no usage, so a compromise of our systems cannot reach your work, and our systems being unreachable cannot stop it. The desktop application ships with no remote dependencies either. Our build fails if the shipped app would fetch anything off the machine, so a dependency cannot quietly reintroduce a remote call. Air-gapped deployment is documented and supported.

The outbound calls that do happen are yours to make: the AI model providers and third-party services you connect, reached from your environment under your own accounts. None of them route through us.

Our controls are designed against the SOC 2 Trust Services Criteria. We are aligned with that framework. We have not completed a SOC 2 audit and do not hold a report, and we say so directly rather than let a procurement process assume otherwise.

In practice that means:

• Least-privilege access to systems and data, reviewed as people join and leave.
• Encryption in transit for all traffic to our services and this website.
• A deliberately short list of third-party providers, reviewed before we adopt them.
• Separation between our public website and anything that touches customer workloads.
• Security work treated as part of building the product, not a gate at the end of it.

• The local API is protected by a bearer capability token, on by default.
• That token can be rotated in place, so a credential that leaks into a screen share or a shell history can be revoked immediately rather than at the next restart.
• A new token is shown exactly once, when it is created. No route serves it back to anyone already holding it.
• Token file permissions are checked, and overly readable permissions are surfaced to the operator.
• Runs execute under a policy engine, against enforced budgets, on a tamper-evident audit trail.
• Generated output passes vulnerability scanning and quality gates before it reaches a reviewer.

Because the deployment is yours, so is its operation: the infrastructure, its patching, its backups, and who you grant access to.

• Served over HTTPS.
• Authentication and session handling use Better Auth in our account service at account.crowdbuilder.ai, hosted on Cloudflare Workers.
• Accounts are scoped to an organisation and its approved email domains, so one customer's users cannot see another's.
• The demo form can create a request but cannot read any request back, including its own. Submissions are readable only by our administrators.
• Licences are invoiced, so no payment card data is collected or stored anywhere in our systems.
• No advertising, remarketing or cross-site tracking code.

If you have found a security issue in CrowdBuilder or in this website, tell us at legal@waybound.ai. Include enough detail to reproduce it: the affected component, the steps, and what you were able to achieve.

We will acknowledge your report, keep you updated while we work on it, and credit you if you would like to be credited. Please give us a reasonable opportunity to fix an issue before disclosing it publicly, and do not access, modify or delete data that is not yours while investigating.

Our breach notification commitments, including the 72-hour notification to the Norwegian Data Protection Authority and notification to you where we act as your processor, are set out in the GDPR section.

Security reviews, questionnaires and architecture questions: legal@waybound.ai. A data processing agreement, including the current sub-processor list, is available from privacy@waybound.ai.