Data Security
How Airlock protects your data at every layer
Security Architecture
Airlock is built on the HARP protocol (Human Approval Relay Protocol), designed so that no single component — including the Airlock Gateway itself — can access sensitive data. Security is enforced through cryptography, not trust.
End-to-End Encryption
Payload Encryption
All AI action payloads (commands, file diffs, terminal output) are encrypted with AES-256-GCM using a symmetric key shared only between the enforcer and the approver. The Gateway processes only opaque ciphertext.
Key Management
Encryption keys are generated during workspace pairing and stored locally on the enforcer and the approver device. Keys are never transmitted to or stored on the Gateway.
Cryptographic Signatures
Approval decisions are cryptographically signed using Ed25519 digital signatures. The approver's private key never leaves their mobile device. The enforcer verifies the signature locally before allowing any AI action to execute.
Signature verification is local. Even if the Gateway were compromised, forged approvals would fail signature verification at the enforcer. This is the core security guarantee of the HARP protocol.
Zero-Knowledge Gateway
The Airlock Gateway operates as a zero-knowledge relay with strict guarantees:
- •No payload access: The Gateway relays encrypted artifacts without decryption capability
- •No key material: Encryption keys and signing keys are never transmitted to the Gateway
- •Log redaction: A dedicated
RedactionMiddlewarestrips sensitive headers and prevents payload data from appearing in logs, traces, or error reports - •Minimal push notifications: Push notifications contain only request IDs and artifact type labels — no payload content
Fail-Closed Enforcement
All Airlock enforcer extensions operate in fail-closed mode. If any part of the approval flow fails, the AI action is blocked:
Gateway unreachable → Blocked
Invalid signature → Blocked
Request timeout → Blocked
JSON parse error → Blocked
Missing routing token → Blocked
Submission error → Blocked
Transport Security
In addition to end-to-end encryption, the Gateway enforces:
- •HTTPS/TLS for all API communication
- •
X-Content-Type-Options: nosniffto prevent MIME-type sniffing - •
X-Frame-Options: DENYto prevent clickjacking - •
Cache-Control: no-storeto prevent caching of sensitive responses - •
Referrer-Policy: strict-origin-when-cross-origin
Integrity Verification
Every artifact is canonicalized using JSON Canonicalization Scheme (JCS / RFC 8785) before hashing with SHA-256. This produces a deterministic artifactHash that both the enforcer and approver can independently verify,
ensuring no tampering occurred in transit.
Open Source & Auditability
The following components are open source for independent audit:
- •HARP Protocol Specification: Full protocol spec with test vectors and compliance criteria
- •Enforcer Extensions: Cursor, Windsurf, Antigravity, and Copilot enforcers
- •Gateway API Client: The client library for gateway integration (coming soon)
Security Summary
| Layer | Mechanism | Standard |
|---|---|---|
| Payload Encryption | Symmetric AEAD | AES-256-GCM |
| Decision Signing | Digital Signatures | Ed25519 |
| Artifact Integrity | Canonical Hashing | JCS + SHA-256 |
| Transport | Channel Encryption | TLS 1.2+ |
| Failure Mode | Fail-Closed | Block on any error |
Your Data Rights
In accordance with applicable data protection laws (including GDPR, CCPA, and similar regulations), you have the right to request access to, correction of, or deletion of your personal data that we process. To submit a request for erasure (right to be forgotten) or to exercise other data subject rights, please contact us at support@airlocks.io. We will process valid requests within the timeframes required by applicable law and will confirm once your data has been deleted or otherwise handled as requested.