Security

Authentication

Accounts are managed by Supabase Auth with email and password, Google OAuth, or GitHub OAuth. After login, your browser holds a session token (a JWT) that is refreshed automatically by the platform middleware, so a working session does not silently expire mid-work.

The API accepts that session token in two forms: as the session cookie the dashboard sends anyway, or as an Authorization Bearer header. Programmatic access without a browser login uses API keys instead, described below. Endpoints reject requests without a valid credential; only the explicitly public routes, such as the health check and the contact form, work unauthenticated.

Roles and permissions

Every account has exactly one role: CLIENT, OPERATOR, or ADMIN. Clients own robots and pay for sessions, operators control robots and earn from sessions, and admins run the platform. You choose between client and operator during onboarding; the admin role is assigned by platform administrators and cannot be self-selected.

Role checks happen server-side on every request, not in the UI. Beneath the API, database access is additionally restricted with row-level security policies, so even a bug in an endpoint does not turn into free access to other accounts' rows.

API keys

API keys give scripts and servers access without a browser login. You create and revoke them in /dashboard/settings; keys carry the prefix ayr_live_ and are sent as an Authorization Bearer header. A key acts with the role and permissions of the account that created it, so a leaked key is exactly as bad as a leaked password.

• Keep keys server-side. They do not belong in client-side JavaScript, mobile apps, or public repositories.
• Use one key per integration. When something leaks, you want to revoke one consumer, not all of them.
• Rotate without downtime: create the replacement key first, deploy it, then revoke the old key in /dashboard/settings.
• Revoke immediately on any suspicion. Creating a fresh key costs seconds; an attacker with a valid key can do anything your account can.

Safeguards during live control

Live control is bound to a session lease. A robot accepts commands only while it is in exactly one ACTIVE session, and only from the operator holding that session; the robot itself is marked IN_SESSION for everyone else. An operator can hold at most one ACTIVE or PAUSED session at a time, which rules out one person nominally controlling two arms at once.

The cockpit provides an emergency stop that halts the arm immediately, and pausing or ending the session stops command flow as a whole. On top of that, the platform monitors operator activity: after a period of no input an inactivity warning is sent, and if the operator stays inactive the session is stopped automatically. That protects both sides, the client from paying for idle time and the robot from sitting in an uncontrolled state with a live lease.

Audit trail

Every session keeps an event log: start and end, pauses and resumes, activity checks, inactivity warnings, operator switches, extension requests, and errors, each with a timestamp. When a dispute is reviewed, this event log is the primary evidence, which is one more reason the platform writes it automatically instead of relying on anyone's memory.

Beyond sessions, significant platform actions are recorded in an audit log with the acting user id, the action, the affected resource, and metadata. Profile changes, payment-relevant transactions, and admin actions all leave entries. Audit records are written by the platform and are not editable through any user-facing interface.

Encryption and data protection

All traffic to and from the platform is encrypted in transit with TLS, including video streams and control signals. At the data layer, row-level security policies restrict database access per account. Payment data is the clearest boundary of all: cards and bank details are handled exclusively by Stripe and never touch AY-Robots servers.

Reporting a vulnerability

If you find a security issue, report it responsibly through the /security page or the /contact form using the Bug Report category. Include what you found, where, and how to reproduce it; do not access data of other users beyond the minimum needed to demonstrate the issue, and do not publish details before we have had a reasonable chance to fix it. We read every report.

Frequently asked questions