Version. 0.1 Date. 2026-06-04 Status. Investigation / decision document. Lays out what protects engagement Memory today, the four mechanisms for keeping content from the system builder, what each actually defends against, the core tension with the Companion needing to read content, and a tiered recommendation. Aimed at the question of cryptographic impossibility but does not overclaim it. Not a change request. Author. Claude.ai (investigation layer). Operator: Marvin Percival. Origin. The Operator's question: what makes it impossible for the system builder (Marvin / DUNIN7) — or anyone — to see engagement Memory, so that potential operators and organizations can trust Loomworks. Companion to the Memory Disclosure Layer investigation; together they are the two halves of enterprise trust in confidential content.
> SUCCESSOR NOTE. This investigation was continued under a new base name. From v0.2 onward the line is data-at-rest-protection-investigation (current: data-at-rest-protection-investigation-v0_2). The base name changed because the inquiry broadened from engagement content specifically to data-at-rest protection generally (engagement content, personal Memory, secrets, and the confidentiality-posture ladder). This document (engagement-content-confidentiality-investigation-v0_1) is the prior position, retained; the data-at-rest-protection-investigation series supersedes it.
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 get 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 same posture as 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 somewhere the builder cannot inspect. The only mechanism that delivers true impossibility while keeping the Companion working is confidential computing (secure enclaves), at real architectural cost.
The core tension, stated 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 and sharper:
> At the moment the server reads plaintext, can we make it so that DUNIN7 — the builder, with full infrastructure access — still cannot see it?
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 the application and query PostgreSQL directly, and where data is encrypted, the builder holds the key. The truthful statement today is: 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). Enterprises trust them via operational and legal controls. The question is whether Loomworks wants to offer more than that.
Weakest to strongest, by what each defends against.
Application access control + encryption at rest (system-held key) + audit logs + contracts.
Engagement content encrypted under a key the customer holds; DUNIN7 stores only ciphertext at rest.
Plaintext is decrypted only inside a hardware-isolated enclave (e.g. 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 it. The enclave proves to the customer, via cryptographic attestation, exactly what code is running before the customer's key is released to it.
Content encrypted on the customer's device; the server only ever holds ciphertext, never the key.
| Mechanism | Stops the builder? | Companion still 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.
DUNIN7 — Done In Seven LLC — Miami, Florida Engagement Content Confidentiality Investigation — v0.1 — 2026-06-04