Security & trust
Trust Center
The four answers a security review actually needs: how tenant data is isolated, who can sign in, how the agent updates itself, and what is — and is not — collected.
Tenant isolation
One platform, every customer, walled off in three layers.
Isolation is enforced as defense in depth, not by a single application check. A request for another tenant's data does not leak an authorization error — it returns a 404, because outside your scope the record does not exist.
Database layer
Every row that touches endpoint data carries a tenant_id. Every query filters on it. There is no shared table where one customer's activity sits next to another's without that column.
Object-store layer
Screenshots and exported files live under object keys prefixed with the tenant ID. The storage path itself encodes ownership, so a mis-scoped read cannot resolve to another tenant's bucket space.
API layer
Every endpoint is scope-checked against the caller's tenant grants before it reads or writes. Managers see only the tenants you assign them; super-admins see the whole book of business.
404 Not Found, never a partial record or a permission hint. The three layers hold independently, so a bug in one does not open the others.Authentication & access
Microsoft identity in, local passwords out.
There is no username-and-password form to phish or brute-force. Admins sign in with their Microsoft 365 account and are provisioned deliberately — no one self-registers into your tenant.
Entra SSO only
Sign-in runs through Microsoft Entra using the authorization-code flow with PKCE. Each account is bound to its immutable Entra object ID on first login, so identity cannot be reassigned by changing an email address. Local passwords were removed in v0.3.
Role-based access
Two roles: Manage and View-only. Write attempts from a View-only session are rejected at the authentication chokepoint, not merely hidden in the interface, so a crafted request cannot bypass the read boundary.
Scoped by design
Access is scoped per tenant. A manager is granted one or more specific customers; a super-admin spans every tenant. No account sees data it was not explicitly assigned.
Code signing & hardened updates
Signed installer. Verified updates.
The MSI and all three executables are code-signed, and updates are cryptographically checked before anything runs as SYSTEM.
Signed installer and binaries
- Authenticode-signed via Azure Trusted Signing
- RFC 3161 timestamped, so signatures stay valid after the certificate ages
- Every executable in the MSI is signed, not just the package wrapper
Hardened self-update
- Verifies the Authenticode publisher on every downloaded update
- Checks the SHA-256 hash and a separately signed release manifest
- Refuses downgrades, so an old build cannot be forced back on
- Update directory is writable only by SYSTEM and Administrators, and updates apply only when no interactive session is present
Data in transit
Encrypted on the wire.
Every agent-to-API connection is TLS-encrypted, and the agent refuses to fall back to an unencrypted channel. It talks only to api.snitchos.com. Database and object storage are not exposed to the public internet.
Data handling & retention
Collect the shape of the workday, not what’s typed.
SnitchOS captures how time is spent, not what is typed. Everything collected has a fixed retention window, and a tenant's data is purged when the customer leaves.
What we collect
- Active window: foreground process, title, and user, sampled about every 10 seconds
- Idle versus active state, so idle time is not credited to the foreground app
- Browser URLs as scheme, host, and path only — query strings stripped at the endpoint
- Input metrics as counts only: keystroke, mouse-click, and mouse-distance totals
- One deduplicated screenshot per minute, skipped while idle
What we never collect
- The keys or content you type — the counter increments and discards the keystroke
- Clipboard contents, file contents, or message bodies
- Audio, microphone, or webcam capture
- Saved passwords, and the query strings that carry SSO and OAuth tokens
What we don't do
It is not a keylogger
Input is counted, never recorded — keystroke_count, mouse_click_count, mouse_distance_px. The keys you press never leave the endpoint.
It is not a rootkit
The service is visible in Task Manager as SnitchOSAgent and a local admin can uninstall it. MSPs need that for support.
It does not read content
No clipboard, no file contents, no message bodies, no audio, no webcam, no saved passwords. Screenshots are visual frames only.
It does not store URL secrets
Only scheme, host and path are kept. Query strings and fragments are stripped on the endpoint and again on ingest, so SSO tokens are never saved.
Employee notice & lawful disclosure
Built for disclosed monitoring of company-owned devices.
SnitchOS is designed for company-owned, MSP-managed endpoints, deployed with appropriate notice to the people using them. The posture is transparency, not stealth.
Where it belongs
- Company-owned, MSP-managed Windows endpoints
- Deployed with appropriate employee notice
- Not for personal devices
- Not designed to be undetectable — the service is visible and uninstallable by a local admin
Per-user kill switch
Monitoring can be turned off for an individual user. The agent stops collecting for that session while existing history is retained, so you can honor a specific exclusion without uninstalling the fleet. See the product overview for the control.
Bring documented answers to your next security review.
Create your account and test the controls on your own fleet — 30 days, every feature.