The safest data is the data we never collected.

The tray icon is not optional

The agent shows a permanent system-tray icon reflecting the real tracking state, and an administrator cannot hide it. Covert deployment is not a supported configuration and not a feature request we will take — partly because it is restricted by law in several Australian states, and mostly because a monitoring tool people find out about later is worse than none.

Each tenant has its own database. There is no shared activity table with a tenant column, so a missing WHERE clause cannot leak another organisation's data — the query would have to open a different database file. Cross-tenant isolation is covered by automated tests that run on every change, including on the API and the MCP endpoint.

Tenant deletion deletes the database. When an organisation or a tenant is removed, its data store is destroyed before the row that names it is dropped, so a later tenant reusing a code cannot inherit anything.

• ✓In transit: TLS 1.3 for agent, dashboard and inter-service traffic. HSTS on the web tier. On self-hosted installs the client installer enables TLS by default and pins the server certificate.
• ✓At rest: AES-256 on the managed cloud, including backups.
• ✓Passwords: salted hashes, never stored or logged in the clear. Minimum ten characters with mixed classes, plus a dictionary and common-pattern check that rejects passwords which pass the character rules but are still guessable.
• ✓API tokens and session identifiers: hashed at rest. A copy of the database is not enough to impersonate anyone.
• ✓Third-party secrets: SSO client secrets are encrypted in the tenant database rather than stored as configuration.
• ✓Sessions: secure, HTTP-only cookies; every signed-in device is listed in the dashboard and can be revoked individually.

MunkiSee staff

Multi-factor authentication is mandatory and cannot be turned off by policy or by the account holder — an un-enrolled staff account is blocked from every administrative route until it enrols. Production access is limited to named operators and every administrative action is audit-logged. Staff accounts do not have single sign-on: there is no external identity provider in the path to our control plane.

Your organisation's owners

Set when the tenant is created and invited by email. MFA is mandatory here too — a new owner must enrol before any tenant resolves, so there is no window in which the account with the most authority is protected by a password alone.

Your dashboard users

Invited by an owner, by email or by a one-time setup link. MFA is self-service and encouraged rather than enforced, because this tier is where a locked-out user costs you a working day. Single sign-on is available and configurable by your Admin role: Microsoft Entra ID, Google Workspace, Okta, any OpenID Connect provider, or SAML 2.0.

Permissions are per-area rather than a single admin flag — reports, settings, user management, monitoring configuration and backups are separate grants, and API tokens are scoped to the same areas with read and write split.

Administrative actions are written to a durable, searchable audit log — including the changes people most want to be able to prove later: who widened the tracking hours, who turned on out-of-hours monitoring and confirmed it, who deleted activity, who added or removed a user.

Some entries cannot be cleared. The audit log has a purge for routine noise, but records of account recovery and of monitoring-scope changes are exempt from it, so the trail that matters in a dispute cannot be tidied away by somebody with dashboard access.

Enrolment is controlled from your side: an optional device approval queue holds new machines until an administrator accepts them, and a blocked-device list refuses named hostnames outright, including machines that were previously enrolled and deleted.

Locked out. Every install is issued single-use recovery keys, verifiable offline, so a self-hosted customer with no reachable administrator is not dependent on us being online to get back in. A recovery session is scoped to resetting one password and then burns itself, and using one writes an audit entry that cannot be deleted.

Backups. Scheduled archives with configurable retention, optionally protected by a passphrase you hold — so an archive that leaves your control is not readable by whoever finds it.

Retention. Detailed activity is kept for the period your plan allows, and you can configure it downward. Past that boundary the raw events are rolled into hourly summaries and deleted rather than archived: trends survive, the minute-by-minute detail does not linger, and deletion means deletion.

Managed cloud. Hosted in the region agreed at signup, in a database dedicated to your organisation. Our sub-processors are named in the Data Processing Agreement — infrastructure, Stripe for billing (billing contact and invoice data only, never activity data), and a transactional email provider for invites and reports. You are notified in advance of any addition, with a right to object.

Self-hosted, on Enterprise. Activity data never leaves your infrastructure and we have no access to it whatsoever. The only thing a self-hosted install exchanges with us is licence state and seat counts — no activity, no user names, no device names. Offline builds are available for air-gapped sites, where even that exchange is replaced by a signed licence bundle.

If data residency is an absolute requirement rather than a preference, the self-hosted deployment removes the question rather than answering it.

Continuous integration runs the full test suite on every change, including the measurement pipeline and the cross-tenant isolation checks. Dependencies are tracked and updated; production access is segregated and limited to named operators.

Service health is published on the status page. Incident response follows internal escalation runbooks, and our breach-notification commitments — notice without undue delay, in time for you to meet your own statutory deadlines, with the detail regulators require — are contractual, in clause 8 of the DPA.

MunkiSee does not currently hold ISO 27001 or a SOC 2 report. We would rather say that plainly here than have you find it out in week three of a procurement cycle. The controls described on this page are real and we will evidence them; an audited attestation of them is not something we have today.

What we do provide: completed security questionnaires, the named sub-processor list with entities and regions for your tenant, the DPA with Standard Contractual Clauses where relevant, and the audit rights in clause 10 of the DPA — including inspection, satisfiable by third-party attestation where an inspection would touch another customer's data.

If you believe you have found a vulnerability in MunkiSee, tell us through the contact form and mark it as a security report. We aim to acknowledge within two business days and will keep you updated until it is closed.

We ask for reasonable disclosure: give us a chance to fix it before publishing, do not access or modify data belonging to anyone else while testing, and do not run denial-of-service or social-engineering tests against us or our customers. We will not pursue action against anyone who reports in good faith within those bounds. We do not currently run a paid bounty programme, and we will credit you if you would like us to.