Skip to main content
AcuSight’s security model comes down to four ideas: people and devices hold different credentials, everything travels over TLS, every request is scoped to exactly one organization, and devices never listen for inbound connections. This page walks through each, with pointers to the deeper docs.

Identities

People sign in through single sign-on. Authentication is handled by a dedicated identity layer (OIDC) — it owns passwords and sign-in security, and AcuSight services only ever see tokens, never credentials. You can sign in with Google, GitHub, or email (Signing in). What you can do is governed by your role — owner, admin, or member (Orgs, users & multi-tenancy) — and removing a member both revokes their access and terminates their active sessions. Devices hold per-device keys. Each device authenticates with its own key, issued at provisioning and stored by the platform only as a hash — it can’t be read back out, only rotated. A device key works solely on device endpoints: a compromised device can’t act as a user, enroll other devices, or see anything outside its organization. Full lifecycle in Device keys & provisioning tokens. Media links are short-lived. Images and video in the dashboard load through expiring signed URLs rather than long-lived public links, so a copied media URL stops working after it expires.

Transport

All traffic is TLS — browser to platform and device to platform alike:
  • Hosted (acusight.io) terminates TLS with publicly trusted, automatically renewed certificates, and sends HSTS so browsers refuse to downgrade to plain HTTP.
  • On-prem / LAN installs terminate TLS with a private certificate authority created at install time; devices are handed the CA certificate during provisioning so they can verify the platform.
On the device side, every connection is outbound — check-in, uploads, and model pulls over HTTPS, and container management over a short-lived encrypted tunnel that exists only while you’re using it. Devices expose no ports and run no listening services. See Architecture for the full picture.

Organization isolation

Your organization is resolved when a request is authenticated — from the user’s token, the device’s key, or the signature on a media URL — and everything after that is filtered to it. There is no org ID to pass and none to get wrong. That includes container management: when you open a device’s containers, the platform only ever exposes endpoints belonging to your organization’s devices. Isolation is covered by regression tests in the platform’s own test suite. The design is described in Multi-tenancy.

Data

  • Recordings are short-lived by design. Continuous recording segments expire automatically after roughly 24 hours — recording exists for review and playback, not as an archive.
  • Your working data persists until you delete it. Projects, datasets, annotations, dataset versions, trained models, and detection events remain available for as long as you keep them.
  • Deleting is real. Removing a device deletes its keys and its management endpoint; removing a member deactivates their sign-in.

Next steps

Device keys & provisioning tokens

The credentials in a device’s life, and how to rotate or revoke them.

Multi-tenancy

How organization isolation is enforced across the platform.