Security and data handling.

Authentication and access

There are two layers of identity in Hover: who your people are, and which deployment a relay connection belongs to.

Accounts

Users sign in with Google Sign-In or a one-time email code. Hover issues its own short-lived access tokens (signed RS256, with public keys published at a standard JWKS endpoint for downstream verification) plus a longer-lived refresh token that rotates on use, with reuse detection. The Hover CLI and desktop app obtain a token through the same sign-in and store it locally, scoped to the server it was issued for.

Authorization: who can do what

Access is enforced by a central policy engine (Cedar, AWS's open-source authorization engine) consulted on every privileged operation, rather than by ad-hoc checks scattered across services. Each member holds one role (Org Admin, Tenant Admin, Team Admin, Operator, or Viewer) and sees and acts only on the orgs, tenants, teams, and deployments that role and their team membership allow. Hover support staff are a separate, audited principal.

Deployment credentials

Every deployment runs as an isolated session with two pieces of identity: a unique 32-bit session ID and a per-deployment API key, minted when the deployment is created. The field proxy and operator client sign their registration to the relay with HMAC-SHA256 keyed by that API key; the relay verifies the signature and pairs the proxy to its matched client. Forged or replayed registrations are rejected, and two deployments cannot see each other's traffic, by design. API keys are not embedded in source code; they're issued per-deployment and rotatable.

Transport

Transport is HMAC-authenticated on every packet, which prevents tampering and replay. The in-flight video stream is not separately encrypted in transit; its confidentiality depends on the underlying network path. This matches how most operational drone-streaming products work today. Per-session encryption of the relay legs is on the roadmap. If your procurement requirements demand it before that ships, raise it during discovery.

Encryption at rest

All persistent customer data at rest is encrypted. The database runs on KMS-encrypted volumes with customer-managed keys; the recording and detection object stores use S3 SSE-KMS, also with customer-managed keys. The remaining storage buckets (org logos, downloads, the website, and infrastructure state) use S3 server-side encryption with AES-256 (SSE-S3).

What we log

Hover keeps operational data in a few places, none of which holds video or command payloads:

Session and usage events (server-side)

Connection events: when a proxy or client registers, when a session ends, retransmit and reorder counters, latency, error events. These exist to operate the platform: to triage incidents, verify health, and prove a deployment was working during a given window. They contain no video and no MAVLink command payloads, and the underlying event stream is retained about 7 days.

Flight index (server-side metadata)

One metadata record per flight (duration, data volume, connectivity, operator), plus rolled-up summaries (GPS path, altitude, battery, flight-mode segments) when an org enables telemetry capture. Metadata about the flight, never the video or the command stream. Retention is tier-based: roughly 90 days on Pilot, a year on Crew, retained on Fleet and above. (Separate from cloud-recording retention, below.)

Audit log

Privileged and staff actions, and authentication events, are written to an audit log retained one year.

Field-side logs (on your hardware)

The proxy and client write their own logs to disk on your machines. The Hover Relay app shows them in-app, and the CLI streams them with hover logs; they never leave your hardware unless you choose to share them.

What we keep, and what we don't

The governing rule is metadata, not content: Hover holds an indexed record of what happened, not the video or the command stream. The relay forwards video and MAVLink bytes and does not retain them. There are two deliberate, narrow exceptions, both opt-in and customer-controlled:

• Cloud recording (opt-in, Fleet and above). If you enable recording on a deployment, the flight is also muxed to cloud storage so it's browsable and shareable from the dashboard. It auto-deletes on a tier-based schedule (Pilot 7 days, Crew 30 days, Fleet 1 year, Enterprise custom), and you can delete it sooner. The field SD card stays the canonical, customer-custody copy; cloud recording is the convenience copy.
• Detections (opt-in, Fleet and above; private beta). On an armed deployment, sampled frames are sent to the AI model under zero data retention; the model provider keeps nothing. Hover stores only the detection event (rule, label, confidence, time, location) plus one small cropped thumbnail per match. No full frames, no stream.

Otherwise the limits hold:

• No command-history archive. Operator inputs and MAVLink command payloads are forwarded and discarded; they would reveal operational tactics, so Hover does not capture them.
• No customer-data warehouse. Hover does not aggregate customer video, telemetry, or identifying data into a shared analytics surface.
• No PII beyond accounts. The only personal data Hover retains is the account record (email, Google identity, display name) held by the auth service.

What lives where

• Cloud. Single AWS US region, Hover-managed and monitored. Holds the flight-index metadata, the audit log, account records, and (only if you enable them) cloud recordings and detection thumbnails, per the schedules above. No cross-region replication today.
• Field SD card. The canonical recording, written to a labeled card. The operator swaps it and hands it to evidence, the same as a body-worn-camera card.
• Operator laptop. Local logs only. No persistent video storage on the operator side.

Compliance posture

Data ownership

Customers retain ownership of all video, telemetry, location, and operational data generated through the platform. We process that data only to operate and support the platform. We may use anonymized, aggregated operational telemetry (packet-loss histograms, latency distributions, retransmit counters) to improve the platform. We do not aggregate identifying customer data. The full data-ownership terms live in the master services agreement.

Incidents and disclosure

We will notify customer points of contact promptly when we identify a security incident affecting a deployment. Coordinated disclosure to end users (the agencies your customers serve) remains a customer responsibility. Specifics live in the MSA.