Security is not a retrofit. It is woven into the fabric.
That sentence is the third of three places it appears on the public BWI® site, and we are using its third appearance here because this is where the claim has to be defended in detail. The home page makes the assertion. The /security page documents the controls. This piece is where the structural argument lives.
The argument is that a security posture worth having cannot be built by adding security to a product that already works without it.
What “retrofit” actually means
A retrofit, in the security context, is the pattern where a product ships, gets traction, accumulates a customer base, and then has to acquire a defensible security posture in order to keep selling to enterprise buyers. The order of operations is: feature, feature, feature, customer, customer, customer, auditor phone call, security epic, security epic, certificate.
The customer who buys the platform at the end of that sequence is buying a product with security overlaid on top. The audit log lives in a table that was added in year three. The encryption at rest covers the data added after year four; the data from years one and two is on the migration list, where it has been for eighteen months. The MFA enforcement is configurable per organization, which is to say the customers who turn it on are protected and the ones who do not are not. The compliance lead at the customer’s end signs the contract and inherits all of this.
A product built with security woven into the fabric is structurally different. There is no MFA toggle the customer can leave off, because MFA enforcement is in the shared kernel. There is no audit log that covers some operations and not others, because every operation routes through one kernel that writes one log. There is no data added before the encryption requirement, because the encryption requirement predates the data. The compliance lead does not inherit residual risk because the residual was not allowed to accumulate.
Four places the fabric shows
One: prompt control is a database row
Every intelligence operation on the platform is run by a prompt that was authored, reviewed, and approved by a customer-authorized administrator. The prompt lives in a database row in the Prompt Manager. The row is editable in the admin UI. The row is audit-logged. The row is versioned.
The row is not a constant in a Python file. It is not an environment variable. It is not a YAML key. It is a database row.
The reason is auditability. When the regulator asks “show me every prompt that ran in production for customer X in the last ninety days, and identify which administrator approved each version,” the answer is a join. The customer’s compliance lead can run the query themselves through the admin UI. The retrofit version is “the prompts are in source control and the change history is in git.” That works at engineering scale. It does not survive a procurement review.
Two: every intelligence call writes to the audit log
The Intelligence Queue is the only path a model call takes. There is no bypass for a developer to write a quick experimental call directly to a provider. Every call writes an AIAuditLog row with provider, model, prompt template version, full input, full response, cost, user ID, isolation boundary, timestamp, and the action chain that initiated the call.
The log is the same shape regardless of which product produced the row. A Foundry document generation, an Aria voice synthesis, a Forge dossier pass, an Axis gap finding, a Concierge realtime voice turn: all the same audit log, all the same fields, all queryable in the same place.
The retrofit version is “we log AI calls at the application layer.” That produces logs of different shapes from different products and a year-three project to normalize them. The fabric version is a queue no product can bypass and a log no product can avoid writing.
Three: bubbles enforce isolation in the shared kernel
Every customer-scoped piece of content carries a bubble key. Every retrieval query, search index lookup, cross-product action call, and audit log read scopes against the bubble key by construction. Not by convention. Not by code review. By the shared kernel itself: the data access layer rejects queries that fail to scope.
The 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. A retrieval query scoped to entity seven physically cannot return content from entity twelve, even if a developer accidentally writes code that omits the scope check, because the omission is caught at the layer beneath the developer’s code.
The retrofit version is “we use row-level security at the application layer.” That works when every developer remembers to apply the rule. The fabric version is the rule applied at a layer the developer cannot bypass.
Four: provider rotation is the platform’s problem
Every model call declares a capability and the Provider Manager resolves the active provider from the database. Failover order is configured. Credentials route through a managed secret store. Rotating an API key is an admin action.
When a provider’s status changes (a model deprecates, an outage hits, a contract ends), BWI rotates without customer involvement. The customer’s compliance lead does not need to file a change request for the provider list at every renewal. The audit log captures which provider ran which call at the moment it ran. The compliance posture survives the rotation.
The retrofit version is “we have a single provider integration and will eventually add a second.” That is the model where every provider change is a renegotiation with every customer. The fabric version is the model where the provider list is part of the platform’s posture and the customer’s compliance documentation references the posture, not the individual providers.
What this is not
This is not the claim that BWI cannot be breached. Every platform can be breached. The claim is that the platform’s defense is structural rather than incidental: the controls run at a layer the product code cannot bypass, the audit trail covers every operation rather than the ones the product team remembered to log, the isolation boundary is enforced by the data access layer rather than by the developer’s discipline.
This is also not the claim that the certificates are in hand. ISO 42001 and SOC 2 Type 2 are targeted ahead of general availability. Until they land, the language we use is honest: built to, aligned to, architected to. The structural claim is true today and verifiable in the codebase, which is the part the certificate eventually attests to.
We built the fabric first. The certificate documents what is already true.
[Read the security posture in detail → /security]
[Request Early Access]