Security
A tool that tests memory boundaries should keep its own.
This page summarizes how Memtru handles your systems and data. The full threat model, including what is only partially mitigated, is in the documentation.
Local execution
Tests run in your environment. The CLI has no telemetry and contacts only the targets you configure.
Synthetic fixtures
Every run creates its own principals, tenants, markers and namespace. No real personal data is needed.
Scoped cleanup
Only records the run created are deleted, using the owner's own context. A failed run never triggers a wipe.
Outbound URL policy
Metadata and link-local addresses are always refused; loopback and private ranges need explicit opt-in; remote targets need confirmed authorization.
Fingerprints, not content
Reports describe fixtures by hash. Raw content is opt-in and stripped before upload.
Redaction and rejection
The CLI redacts common credential formats; the server rejects any upload that still contains one.
Token handling
256-bit random API tokens, shown once, stored as SHA-256 hashes, scoped to one project, expirable and revocable.
Server-side authorization
Every query is filtered through the signed-in user's organization membership. Foreign ids return not found.
Browser protections
Nonce-based Content-Security-Policy, HttpOnly SameSite cookies, origin checks on mutations, strict security headers.
What we do not claim
- Memtru has not had an independent security audit.
- It holds no certifications and does not establish regulatory compliance.
- A passing run is not proof that a system cannot leak memory.
- Deletion tests check retrieval visibility, not erasure from backups or derived data.
Read more
To report a vulnerability, email security@memtru.com. Please do not include real personal data.