Privacy and retention
Content off by default, the lawful basis enabling it demands, how long anything is kept, and who can see what.
On this page
The default is metadata: what is installed, how it is configured, which models, how many tokens. The content of anybody's work stays on the device.
Content is off, and turning it on is a deliberate act
Three content grains are off by default. Enabling any of them:
Requires an administrator capability
Not something a member of the organisation can switch on.
Demands a stated lawful basis
Recorded with who gave it and when. The system asks, and stores the answer, rather than assuming somebody thought about it.
Makes every subsequent read auditable
An access-log row is appended, with a required reason, before any bytes return — and there is no reusable signed URL that could be read later without leaving a trace.
A managed configuration pushed by your MDM can only ever switch content collection off, never on. The direction is enforced rather than conventional: a fleet-wide setting that could enable content reading would be a single misconfiguration away from a very different product.
How long anything is kept
| Default | |
|---|---|
| Evidence blobs | 14 days |
| Metadata and transitions | 30 days, deliberately longer than the blobs |
Both are settable. A daily job expires what has passed its window, so retention is a thing that happens rather than a policy nobody enforces.
Erasure. An organisation can be deleted, and it takes a stated reason that becomes the audit entry plus its own confirmation word. There is also "unenrol every device", which revokes credentials and deletes nothing — the two are different actions on purpose.
One honest limit: the Microsoft device mirror is recreated by the next sync from your tenant, which is the source of truth and which endlayer does not delete from. Removing a device there for good means removing it in Intune, or disconnecting the connector — which deletes the whole mirror.
Who can see what
Three roles, as a chain rather than a matrix.
| Role | Holds |
|---|---|
| Member | the estate: posture, coverage, aggregate token cost, evidence reads, generating evidence packs, acknowledging findings |
| Admin | all of that, plus the person-shaped reads — identity, per-person cost, session titles, conversation prose — plus settings, enrolment, devices and roles |
| Owner | all of that, plus billing. Its single privileged call site is deleting the organisation |
A member sees the estate; an administrator sees who. That line is the whole design, and it is why aggregate coverage and per-person detail are separate capabilities rather than one "read" permission.
Evidence packs are the exception worth knowing about: they are generated by any member, because they are built from a separate safe projection in which chat, session titles, serials and per-device browsing detail are absent structurally. No role can widen a pack, which is what makes handing one to an auditor a safe act rather than a careful one.
The queries behind all of this derive the organisation from the authenticated caller on the server, never from an argument — so there is no request shape that asks for another tenant's data.
Fuller treatment: content and privacy, retention and erasure and access control.