Security
Security is not a retrofit. It is woven into the fabric.
Security on most software platforms is a layer applied after the product works. On BWI® it is an architectural commitment made on day one, enforced in the shared kernel every product inherits. This page documents the posture, the structural decisions, and the controls in enough detail to satisfy a compliance lead reviewing the platform for procurement.
Built to the standard
BWI® was architected to ISO 42001 from day one. The commitment shows up in four places, each a decision made before the first product shipped.
Full prompt control through the Prompt Manager. Every prompt is a database row, edited in the admin UI by a customer-authorized administrator, audited like any other change. Not an environment variable. Not a constant in a config file. A row. The reason is auditability: a database row is queryable, exportable, versionable, and reversible.
Full audit of every intelligence call through the AIAuditLog. Every model call captures provider, model name, prompt template version, full input, full response, cost, user ID, isolation boundary, timestamp, and the action chain that initiated it. The log is the same shape regardless of which product produced it, because every call routes through the same Intelligence Queue. When the auditor asks “show every prompt that ran for customer X in the last ninety days,” the answer is a query.
Encryption at rest across the platform. Customer data, audit logs, retrieval indexes, generated artifacts, and intelligence operation outputs are encrypted at rest. Encryption keys are per-customer where customer-scoped, per-instance otherwise, rotated on a documented cadence.
Single-tenancy as the default. Every customer instance is its own deployment. Its own database. Its own encryption keys. Multi-tenancy as a default is a security posture, and it is not the posture this platform takes.
Formal SOC 2 Type 2 and ISO 42001 certification are targeted ahead of general availability. The architecture claim does not depend on the certificate. BWI was architected to the standard before the certificate process began.
Provider architecture
The intelligence layer is provider-agnostic by design. The Provider Manager is capability-based, not vendor-locked. Every model call declares the capability it needs and the manager resolves the active provider from the database. Multiple providers can satisfy one capability. Failover is configured.
What this gives the customer’s compliance review: the provider list is not a static disclosure that goes stale between renewals. It is a live configuration with a documented rotation process and a per-call audit trail. When a provider’s status changes (a model deprecates, an outage hits, a contract ends), BWI rotates providers without customer involvement or service disruption. The capability is the contract; the brand behind the capability is replaceable.
Every credential flows through a managed secret store. There are no environment-variable secrets in deployment YAML. Rotating an API key is an admin action, not a redeploy.
Dedicated by design
Per-customer isolation is enforced in the shared kernel, not at the application layer. The Bubbles model tags every piece of customer-scoped content with a bubble key. Every retrieval query, search index lookup, cross-product action call, and audit log read scopes against the bubble key by construction. A new product team writing new code cannot accidentally bypass the rule because the shared kernel enforces it before the product code runs.
Single-tenancy is the default deployment posture. Every customer instance runs in its own AWS deployment, with its own database, its own encryption keys, and its own isolation boundary. Data isolation is the floor, not the upgrade.
A multi-entity scenario tests the model. A business runs BWI across twenty of its own entities inside one instance. Each entity has its own bubble. Compliance findings on entity seven cannot leak into entity twelve, even if an analyst’s permissions accidentally allow it, because the bubble check runs at a layer the request never bypasses.
Owned by you
Your data is yours. Exportable any time, in usable formats, without negotiating. The export covers customer records, the full AIAuditLog and ActionLog, generated documents, knowledge bytes, and the artifacts produced by every intelligence operation that ran on your behalf.
If you ever leave BWI, we hand back what is yours. The offboarding process is documented, scheduled, and contractually committed. We do not hold your data hostage as a renewal lever.
A commitment, not a feature.
Compliance posture
BWI inherits SOC 2 alignment from INT, its parent company. INT’s SOC 2 control environment covers personnel, change management, vendor risk, and operations, and applies to BWI as an extension of INT.
SOC 2 Type 2 and ISO 42001 certification are targeted ahead of general availability. Until the certificates are in hand, the language we use is honest: built to, aligned to, architected to. We do not use “compliant with” or “certified” until they are true. The structural claim is true today and verifiable in the codebase.
The audit trail
Every intelligence call writes to the AIAuditLog. Every cross-product action writes to the ActionLog. Every user-initiated action writes to the ActivityLog. The three logs share a structure and a query interface, joined on the action chain that initiated each call. The audit trail is one trail, not three.
A SOC 2 Type 2 control sample is a query. An ISO 42001 prompt-control review is a query. An internal incident review is a query. A regulator’s request for evidence is a query. The compliance posture is auditable in seconds, not screenshots.
Identity and access
Single sign-on. SAML 2.0 and OIDC for enterprise customers. Per-customer identity provider configuration. Sixty-second logout propagation across products.
Multi-factor authentication. Enforced on every external-user session that touches signing, approval, or financial actions.
Role-based access control. Per-product RBAC. Per-customer role definitions. Audit-logged role assignments.
Deployment posture
Customer production deployments run in AWS, in isolated instances, with one database per customer. The deployment topology is one of the platform’s load-bearing decisions: it is why isolation is structurally enforced and not just an access-control claim.
Contact
Security inquiries: security@bwi.com
A BWI Trust Center is planned, to host the current posture, certifications, and subprocessor list in one place.
The security claims on this page are documentable today on request; the full SOC 2 Type 2 report will be available once certification lands.
[Request Early Access]