Trust
What Alfred can and can't see.
We sell discretion, so we hold ourselves to a simple rule: every claim on this page is something the architecture actually enforces — and where we haven't finished auditing, we say so plainly rather than overclaim.
Enforced today
- Each rep's private work lives in a per-rep store, scoped to them at the database (row-level security) and application layers.
- The shared company agent has no read path to a rep's private store — enforced at two layers, not promised.
- Managers see team-level aggregates, never your DMs without your explicit approval.
- Each client's context is isolated, and a continuous test in our CI checks that isolation holds.
- Alfred starts in shadow mode — it observes and drafts, and only acts when you grant it.
- Alfred confines its writes to its own owned space; it doesn't edit your other documents.
How the shared agent works
- The shared agent (Lucius) is off until your admin turns it on — it ships disabled by default.
- Seeing any individual's detail (beyond aggregates) requires that person's explicit approval — a consented reveal, not a manager override.
What we haven't finished auditing
- Operator and logging access paths — whether any internal tooling could surface private content.
- Our model vendor's data-retention posture and the exact prompt data sent to it.
- Backup isolation across tenants.
Until those audits are complete and reflected in our DPA, we describe these as designed to keep client context walled off — not as absolute guarantees. We'd rather tell you what we can't yet claim than overclaim.