DATA SECURITY
Your data never leaves your environment.
Every system BuildClub builds runs inside your own cloud tenant, credentialed through your identity provider and logged by your audit infrastructure. How that works, the controls behind it, and the architecture in plain terms.
Request a conversation →Data handling
Your data never leaves your environment. BuildClub systems run inside your own cloud tenant, authenticated through your identity provider and logged by your audit infrastructure. We operate credentialed inside your boundary. We do not hold, copy, or process customer data on infrastructure we control.
- We do NOT use your data to train shared or public models
- Everything we build encrypts in transit (TLS 1.3) and at rest (AES-256)
- Access is gated by your SSO and short-lived tokens, with audit logging
- When an engagement ends, you revoke our credentials in your own IdP. There is no BuildClub-side copy of your data to delete.
Hosting & infrastructure
- Client systems run where you run: your Azure, AWS, or GCP tenant, or your own on-premises environment
- Sovereign requirements are met inside your specified national cloud region, with no cross-border data flow
- buildclub.com and BuildClub's internal tooling run on our own infrastructure and hold no client data
AI model access
- LLM calls through enterprise-grade API tiers (Anthropic, OpenAI, Google) with zero-retention agreements
- For sensitive workloads, we deploy on-premise or private cloud LLMs (Mistral, Llama)
- Model selection per workload — we don't lock you into any single vendor
Operational practices
- Background checks for all team members with credentialed access to client systems
- MFA enforced on all internal systems
- Quarterly access reviews
- Incident response: 4-hour notification commitment for material incidents
Vendor management
- Every tool or service we bring into an engagement is disclosed before it touches your environment
- Model providers and third-party services are named in the engagement scope; nothing enters your tenant without your sign-off
- We review the vendors we rely on annually
Where it runs
Everything runs in your environment. That is the rule, not one option among several. The deployment is shaped in Phase 0, not after — integration points, identity flow, audit logging, and where models actually run.
In-tenant. The full system runs inside your existing Azure, AWS, or GCP tenant. Your data never leaves your environment. Your identity provider stays the source of truth. Your existing audit logging captures every action. This is the standard deployment for every engagement.
Sovereign deployment. The same in-tenant architecture, in an account you own, constrained to your specified national cloud region with no cross-border data flow — for regulated industries in specific jurisdictions, defense-adjacent work, and certain public-sector deployments. European sovereign deployments run on OVHcloud when an EU-headquartered provider is required.
Standard across every deployment
In every engagement, every BuildClub system enforces:
- Identity and access. Customer SSO is the source of truth. We do not maintain a parallel user directory. Every action is attributable to a named identity in the customer's IdP.
- Knowledge partitioning. Access-scoped knowledge partitions enforced at the data layer, not at the UI layer. The same source material can serve multiple teams without any team being able to access another team's scope.
- Audit logging. Every query, every retrieval, every tool invocation logged with timestamp, identity, and content reference. Routed to the customer's existing SIEM or audit trail.
- Sensitive data. Filtered at ingestion when possible, segregated by partition when not.
- Encryption. TLS 1.3 in transit. AES-256 at rest. Customer-managed keys where your platform supports them.
- Model routing. Customers choose which models we use. Production deployments default to Anthropic Claude; we support Azure OpenAI, AWS Bedrock, and Google Vertex AI based on the customer's existing model relationship.
- No training on customer data. We do not use customer content to train models. This is contractual, not aspirational. Applies to every engagement.
The architecture in plain terms
When a user asks a question through BuildClub, the request is authenticated against the customer's IdP, evaluated against the user's partition scope, routed to the model layer with the appropriate retrieved context, and logged before the response returns. The model itself does not have unrestricted access to the customer's data — it sees only the partitioned, retrieval-grounded slice that the user's scope and the query intent justify.
The retrieval layer is what gives the system its operating discipline. We do not pass entire databases or document corpora to the model. We pass the minimum relevant context for the question being asked, drawn from partitions the user is authorized to access. This is what makes the same underlying knowledge base safely usable across teams with different access scopes.
Tool invocations — writing back to Salesforce, drafting a reply in Outlook, opening a case in ServiceNow — go through audited, scoped integrations. We do not give the model raw access to customer systems. Every tool call is an explicit, logged, permissioned operation, and the underlying integration uses service principals or OAuth scopes that the customer's IT team controls.
Architecture diagrams covering all of this in detail are in the Security & Architecture Brief, available under NDA.
Available under NDA
Security & Architecture Brief. A detailed technical document covering identity flow, data flow, model routing, encryption posture, key management, audit logging architecture, and per-deployment variations. Standard request from security review desks.
How this gets decided
The deployment is shaped in Phase 0, alongside the data audit and operational mapping — which tenant, which region, how identity flows, where models run. By the end of Phase 0, you have an explicit architecture recommendation that fits your security posture and your operating model, and a clear-eyed view of what it implies for cost, timeline, and integration complexity downstream.
If you are evaluating BuildClub for an engagement and your security team needs answers before the first call, start with a Phase 0 conversation. We will give you the architecture briefing and the deployment recommendation as part of that work.
Want to walk through the security model with our team?
Most security reviews are 30–60 minutes. We're happy to talk through the in-tenant architecture, controls, and how we'd structure your specific engagement.