Security and data
What a workspace agent sends, how it is protected, what mlab.sh stores and for how long.
Workspaces are built so that the data stays with you and a compromised mlab.sh could not turn the agent against you.
What stays on the host
- The data itself: a memory dump is read where it is, never uploaded. Raw memory and extracted files only travel when a member asks for them, one request at a time.
- The policy:
policy.tomlis written by your administrator on the host. mlab.sh can help draft it, but has no way to change it. It decides which tools run, which folders they may read, which operations they may answer, and where results may be uploaded. - The audit log: the agent records every request it served or refused in
audit.jsonlon the host, whatever mlab.sh does.
How a request travels
A member clicks in mlab.sh. mlab.sh signs the request and encrypts it for that agent's key only.
The request reaches the agent over the connection the agent opened (outbound, TLS). Nothing listens on the host.
The agent checks the signature against the mlab.sh key it pinned at enrolment, rejects replays, then checks the request against the local policy. A refusal is signed and logged too.
The tool answers. The agent signs and encrypts the answer for mlab.sh; a large result (an index, an extracted file) is encrypted the same way before it is uploaded, and only to an upload host the policy allows.
Keys: Ed25519 signatures and HPKE encryption, generated on the host at enrolment. The agent's secret key never leaves the host; mlab.sh pins the agent's public keys, and the agent pins mlab.sh's. Check the fingerprint shown next to the enrolment code: enrolment stops if it does not match.
What mlab.sh stores
| Data | Stored | How |
|---|---|---|
| Memory index (processes, modules, network, registry, findings...) | yes, until it expires or is deleted | encrypted at rest (AES-256-GCM), bound to the workspace, agent and dump |
| Raw memory pages, extracted images, dumped regions | no | sent to the member's browser, never kept |
| YARA rules and matches | no | rules stay in the member's browser, matches are shown and dropped |
| Who did what | yes | organization audit log |
Before an index leaves the host, values that look like secrets (passwords, tokens, API keys, Bearer headers, cloud access keys) in command lines and environment variables are replaced with [redacted]. The policy can turn that off (redact_secrets = false) or drop environment variables altogether (collect_environment = false).
Data holding period
Each workspace decides how long mlab.sh keeps what its agents sent: 6 months, 3 months (default), 1 month, 2 weeks, 1 week or 48 hours. Pick it when you create the workspace or in its Settings tab; a change is in the audit log.
An index expires that long after it was built, and is deleted within the hour after that; each index shows the date it will be deleted. Shortening the period applies within the hour to what is already stored. Dumps on your hosts are never touched, so an expired dump can simply be indexed again.
Revoking
Revoke an agent (Agents tab) and its connection closes at once and its credentials stop working; enrolling it again needs a new code. Deleting the workspace revokes every agent first, then deletes its indexes.