Version 0.1 · 2026-06-04 · Investigation / decision document
The honest answer to "what makes it impossible for you to see engagement Memory" is: today, nothing makes it impossible. Access is governed at the application level — members see their engagements, non-members are refused, there is no admin god-view — but the system builder holds the database credentials and the encryption keys, so the builder can read content directly. This is the posture of nearly every SaaS company, and enterprises accept it through operational and legal controls, not cryptographic ones.
To make it genuinely impossible for the builder to read content, the decisive change is that the encryption key for engagement content must be held by the customer, never by DUNIN7 — and because the Companion must read plaintext to reason, that decryption must happen where the builder cannot inspect it. The only mechanism that delivers true impossibility while keeping the Companion working is confidential computing (secure enclaves), at real architectural cost.
The core tension, once: Loomworks' value is an AI that reads and reasons over your Memory. That requires the server to see plaintext. True "we never see your content" and "our AI reasons over your content" are in direct conflict. The achievable strong claim is not blanket zero-knowledge; it is enclave-sealed processing with customer-held keys for the engagements that need it.
Decision needed: which trust model Loomworks commits to, and whether high-assurance is a tier rather than a blanket property.
The Companion must read plaintext to do its job. Shaping arranges content; Rendering produces from it; answering a question requires reasoning over Memory. All of this needs the server to process readable content.
So the question is never "can we hide content from the server entirely" — the answer is no, or the product stops working. The real question is narrower:
Every mechanism below either threads that needle or fails it.
Built and real, but defeatable by the builder:
loomworks_secret_key).Why this does not stop the builder specifically: DUNIN7 runs the infrastructure — database credentials, server, and the encryption key. Application access control is enforced by the application; the builder can bypass it and query PostgreSQL directly, and where data is encrypted, the builder holds the key. The truthful statement today: the application prevents members and non-members from exceeding their role; it does not prevent the system operator from reading the database directly.
This is not a Loomworks failing — it is the default posture of essentially all SaaS (Slack, Notion, Salesforce can all technically read customer data). The question is whether Loomworks wants to offer more.
Weakest to strongest, by what each defends against.
Application access control + encryption at rest (system-held key) + audit logs + contracts.
Stops: members/non-members exceeding their role. Does not stop: the builder — holds key and database. Claim: "access is governed and audited" — not impossibility.
Engagement content encrypted under a key the customer holds; DUNIN7 stores only ciphertext at rest.
Stops: the builder reading the database at rest — a dump is gibberish without the key. Does not stop: reading at processing time, when the server must hold key or plaintext transiently. Claim: "we cannot read your stored data" — with an asterisk a CISO will find: what about when your AI processes it?
Plaintext is decrypted only inside a hardware-isolated enclave (AWS Nitro Enclaves, Intel SGX). The enclave processes content for the Companion; the host OS — and therefore the builder, even with root — cannot inspect inside. The enclave proves to the customer, via cryptographic attestation, exactly what code runs before the customer's key is released to it.
Stops: the builder — genuinely, even with full infrastructure access. Does not stop: a flaw in the enclave code, or exotic side-channels. Constrains how you build. Claim: "we cannot see your content, and here is attestation proving it" — the genuine strong claim. Cost: significant — a foundation, not a feature.
Content encrypted on the customer's device; the server only ever holds ciphertext, never the key.
Stops: everyone but the customer, always. Breaks: the Companion — a server that never sees plaintext cannot run an AI over it. Claim: true zero-knowledge — at the cost of the thing Loomworks is.
| Mechanism | Stops builder? | Companion works? | Cost | Honest claim |
|---|---|---|---|---|
| 1 — Operational trust | No | Yes | Low (≈ today) | Governed & audited |
| 2 — Customer keys at rest | At rest only | Yes | Low–medium | Can't read stored data* |
| 3 — Secure enclaves | Yes | Yes (in-enclave) | High | Sealed even from us, attested |
| 4 — Client-side E2E | Yes | No | Breaks product | True zero-knowledge |
* asterisk = does not cover processing-time access. Mechanism 3 is the only one that delivers genuine impossibility while the Companion still functions.
The practical answer is almost certainly not one mechanism for everything. It is a tier:
This yields a truthful split claim: ordinary engagements are governed and audited; high-assurance engagements are cryptographically sealed even from us, with attestation to prove it. A CISO respects this precisely because the strong claim is made only where it is actually true.
Do not claim impossibility you cannot back. "We literally cannot see your data" invites one question — who holds the encryption key? — and if the answer is "we do," credibility is gone.
Do claim the precise strong version: access is role-enforced; admin access is audit-logged and tamper-evident; content is encrypted; and for engagements that require it, processing is enclave-sealed with customer-held keys, provable by attestation. Precision is what earns a security professional's trust.
FORAY is the natural substrate for the audit-trail half ("FORAY attests"); OVA is the natural substrate for the access-scoping half. Both are already in the protocol triangle. The enclave work is net-new infrastructure.
Adopt the tiered trust model as the direction: operational trust as the default, enclave-sealed customer-held-key processing as the high-assurance tier. Treat genuine impossibility as a real, achievable property — but only via Mechanism 3, only where the engagement needs it, and only after Q1 (where decryption-in-use happens relative to the model call) is answered, because that question determines whether the seal is real.
Do not adopt the blanket zero-knowledge claim; the product's own design — an AI that reads Memory — contradicts it. The achievable strong claim is sealed-where-it-matters, attested, and precise.
If accepted, the next step is a scoping note that answers Q1 concretely and specifies the high-assurance tier as an engagement property.