Security
Security at Airlock
Airlock is a security product — the standard we hold ourselves to reflects that. This page describes how we protect your data, your streams, and your trust.
Local-first by design
Audio and video never leave your machine. All inference runs on-device.
Minimal data collection
We collect only what's needed for accounts and licensing. Nothing more.
Encrypted everywhere
TLS in transit, encryption at rest, and restricted file permissions on-device.
Principle of least privilege
Each component only accesses what it needs. No broad permissions.
1. Architecture Overview
Airlock uses a split architecture that separates the security-sensitive hot path from the cloud control plane:
Local Engine (Desktop)
- All audio and video processing happens on your device using on-device AI models. Media streams are never transmitted to Airlock servers or any third party.
- The engine runs as a separate local process with its own HTTP and WebSocket interfaces, accessible only on
127.0.0.1. - Policy evaluation, incident detection, and protective actions (muting, blurring, scene switching) all execute locally with no network dependency.
Cloud Control Plane
- The cloud API handles only account management, subscription billing, entitlement verification, and device licensing. It has no access to your media.
- Cloud services can go offline without affecting core protection functionality on your device.
2. Desktop Application Security
2.1 Electron Hardening
The Airlock desktop application is built on Electron with the following protections:
- Context isolation: enabled. Renderer processes cannot access Node.js APIs directly.
- Node integration: disabled. All system access goes through a secure, explicitly defined context bridge.
- Sandbox: enabled. Renderer processes run in a sandboxed environment.
- IPC allowlist: only named operations are exposed via the preload bridge. No arbitrary IPC channels.
2.2 Credential Storage
- Device tokens are stored in the application data directory with restricted file permissions (
mode 0600— owner read/write only). - No credentials are stored in plain text in configuration files, environment variables, or application logs.
2.3 OBS Integration
- Communication with OBS uses the OBS WebSocket v5 protocol over a local connection.
- Authentication uses SHA-256 challenge-response when OBS has a password configured.
- No OBS credentials are transmitted to Airlock servers.
3. Authentication and Authorization
3.1 User Authentication
- User authentication is handled via JWT tokens verified using HMAC-SHA256 or RSA signatures via JWKS endpoints.
- Tokens are short-lived and verified on every API request.
3.2 Device Authentication
- Desktop clients authenticate using device tokens — unique, per-device credentials issued during initial registration.
- Device tokens can be revoked at any time from your account, immediately deauthorizing the device.
- Device tokens are transmitted via the
Authorization: DeviceTokenscheme over HTTPS only.
4. Cloud Infrastructure
- Encryption in transit: all communication between clients and cloud services uses TLS 1.2 or higher.
- Encryption at rest: database storage is encrypted at rest using AES-256.
- Payment processing: all payment data is handled by Stripe, a PCI DSS Level 1 certified provider. We never store, process, or transmit credit card numbers on our infrastructure.
- Access controls: internal access to production systems follows the principle of least privilege with audit logging.
5. Data We Do Not Collect
We believe transparency about what we don't collect is as important as what we do. Airlock never collects:
- Audio or video recordings from your streams
- Transcripts or speech-to-text output
- Facial recognition data or biometric identifiers
- The content of detected incidents
- Specific words or phrases flagged by the profanity filter
- OBS or streaming platform credentials
- Screen captures or frame data
6. Incident Response
In the event of a security incident affecting our cloud services:
- We will notify affected users within 72 hours of confirmed unauthorized access to personal data, as required by applicable law.
- Notifications will include the nature of the incident, data potentially affected, and remediation steps taken.
- Because media processing is local-only, a cloud infrastructure breach cannot expose your audio, video, or stream content.
7. Responsible Disclosure
We welcome responsible security research. If you discover a vulnerability in Airlock, please report it to us privately so we can address it before public disclosure.
Report a vulnerability
Email: security@airlock.stream
Please include a description of the vulnerability, steps to reproduce, and any relevant proof-of-concept material. We aim to acknowledge reports within 48 hours and provide a resolution timeline within 5 business days.
We ask that you:
- Give us reasonable time to address the issue before public disclosure
- Avoid accessing or modifying other users' data
- Act in good faith to avoid disruption to the Service
8. Compliance
Airlock is designed with privacy regulations in mind, including GDPR and CCPA. Our local-first architecture inherently minimizes data collection and processing risk. For details on how we handle personal data, see our Privacy Policy.
9. Questions
If you have questions about our security practices, please contact us at security@airlock.stream.