Security & trust
Trust Center
You resell SnitchOS to companies with real security teams, and their review will be thorough. The answers are documented here: how tenant data is isolated, who can sign in, how the agent updates itself, what is and is not collected, and how long it lives. Where a control is still in progress, we say so plainly rather than round it up.
Compliance status
SOC 2 Type I readiness, stated honestly.
SnitchOS is in SOC 2 Type I readiness with a full Trust Services Criteria control mapping and evidence collection underway. This is readiness work, not a completed attestation and not a certification. We do not yet hold a SOC 2 report, and we will not describe ourselves as certified, compliant, or attested until an independent auditor issues one.
Trust Services Criteria control mapping
| Trust Services Criteria | Representative controls in place | Evidence being collected |
|---|---|---|
| Security — Common Criteria (CC1–CC9) | Entra SSO, RBAC least privilege, three-layer tenant isolation, signed and verified updates, network hardening | Access reviews, configuration baselines, audit-log exports |
| Availability (A1) | Nightly database dumps, weekly object-store mirror, cross-datacenter copies, scheduled health checks | Backup logs, restore tests, uptime monitoring |
| Confidentiality (C1) | TLS 1.3 in transit, tenant-scoped storage keys, disposal on offboarding | Transport configuration, retention and disposal records |
| Processing Integrity (PI1) | Idempotent ingest, append-only audit trail, server-side input validation | Pipeline logs, audit-trail exports |
| Privacy (P1–P8) | Out of scope for this examination | Not applicable |
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
The installer is signed today, and the agent verifies its own updates.
The MSI and all three executables are already code-signed — nothing is pending. Updates are cryptographically checked before anything runs as SYSTEM.
Signed installer and binaries
- Azure Trusted Signing, subject
CN=Shield Management Inc - RFC 3161 timestamped, so signatures stay valid after the certificate ages
- Certificate valid through 2028-08-22
- 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 & network
Encrypted on the wire, closed at the perimeter.
The agent will not talk over an unencrypted channel, and the management VM exposes as little as possible to the public internet.
In transit
- TLS 1.3 for every endpoint-to-API connection
- The agent rejects any non-TLS response rather than falling back
- It talks only to
api.snitchos.com, with optional certificate pinning
Network posture
- UFW defaults to deny-incoming on the management VM
- The object store is bound to loopback and is not reachable from the public net
- Postgres is reached over a local Unix socket with peer authentication, not a network port
Audit logging
Every mutation is written down and kept.
The audit trail is append-only. Administrative actions are recorded as they happen, and the log is exportable for the evidence pull your customer's auditor asks for.
What each entry records
- Actor — the authenticated admin who acted
- Source IP and user-agent of the request
- Target — the record or setting that changed
- Outcome — whether the action succeeded or was rejected
Access and retention
- Read it through the JSON audit API or export to CSV
- Append-only — entries are not edited or removed
- Retained three years to support Trust Services Criteria CC7.2
Data handling & retention
Collect the shape of the workday, not its contents.
SnitchOS captures how time is spent, not what is written. Content stays on the endpoint. Everything collected has an end date, and it is disposed when a 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
Screenshot lifecycle
Hot for 30 days
Recent screenshots stay immediately browsable in the dashboard grid and lightbox for the first 30 days.
Cold to day 365
After 30 days they move to cold storage, retrievable for review but out of the hot path, through day 365.
Hard-delete
At the end of the window they are hard-deleted. Retention has a fixed end date rather than growing without limit.
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.
Backups & recovery
Copies exist off-site, and we are precise about how they are protected.
Recovery data is written nightly and mirrored to a second datacenter. We are also explicit about the current limit of that off-site copy, rather than rounding it up.
What we back up
- Nightly full database dumps
- Weekly object-store mirror of screenshots and exports
- Copies replicated to a second datacenter for disaster recovery
How they are protected
Transfers to the off-site target run over an encrypted channel — the copies are encrypted in transit. To be honest and precise: the off-site copies are not encrypted at rest. That is a documented item on our list, not a claim we hide behind. We will not describe our backups as "encrypted off-site" until at-rest encryption is in place.
Payments
Card data never touches our servers.
Billing runs on Stripe. Checkout is Stripe-hosted, so full card numbers and security codes go directly to Stripe and are never handled by SnitchOS.
Stripe-hosted checkout
Card entry happens on Stripe's own hosted pages. Auto-pay charges the saved payment method off-session on the due date, and paying the last overdue invoice reactivates a suspended account automatically.
What we store
- A Stripe payment-method token — a reference, not the card
- Card brand, last four digits, and expiry, for display only
- No full card number and no security code, ever
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.
See SnitchOS on your own fleet. We'll cut you a per-tenant installer with a 30-day pilot key so you can test the controls, not just read about them.