Security & Encryption
How RESTK protects your API secrets with AES-256 client-side encryption, per-workspace key isolation, and zero-knowledge architecture.
RESTK encrypts your sensitive API data on your device before it reaches our servers. Our server stores, syncs, and delivers encrypted data — it never sees the plaintext values. This applies to individual and team workspaces equally.
For a high-level overview, see our blog post How RESTK Encrypts Your API Data.
Encryption Is Always On
Workspace encryption is enabled by default and cannot be disabled. Security is a default, not an option.
What Gets Encrypted
Encrypted (Server Cannot Read)
| Data Type | Examples |
|---|---|
| Auth credentials | Bearer tokens, API keys, OAuth client secrets, Basic auth passwords, JWT signing keys |
| Header values | Authorization header values, custom secret headers, webhook signatures |
| Parameter values | Token parameters, secret query strings, API key parameters |
| Request body content | JSON payloads, XML bodies, form data, GraphQL queries with variables, raw text |
| Environment variable values | Staging/production API keys, database connection strings, service tokens |
Not Encrypted (Visible for UI and Organization)
| Data Type | Why It Stays Unencrypted |
|---|---|
| Request names | Needed for search and organization in the UI |
| HTTP methods (GET, POST, etc.) | Needed for display and filtering |
| URLs | Needed for display (use environment variables for secret URL segments) |
| Collection and folder names | Needed for workspace navigation |
| Header and parameter names | Needed for UI display (only names, never values) |
| Workspace metadata | Name, description, member list |
Best Practice
Store all sensitive URL segments (tokens, keys, internal hostnames) in environment variables rather than hardcoding them in URLs. Environment variable values are encrypted; raw URL strings are not.
Encryption Architecture
RESTK uses a layered key system. No single key can access your data, and each layer serves a distinct purpose.
AES-256-GCM
All encryption uses AES-256-GCM (Advanced Encryption Standard with 256-bit keys in Galois/Counter Mode). This is an authenticated encryption algorithm that provides both confidentiality (data cannot be read) and integrity (data cannot be tampered with without detection). It is the same standard used by governments and financial institutions for classified data.
Three Layers of Protection
Layer 1: Workspace Keys
Every workspace gets its own unique encryption key, generated using a cryptographically secure random number generator.
- Isolation: If you have 5 workspaces, there are 5 independent keys. Compromising one has zero impact on the others.
- Strength: AES-256-GCM with authenticated encryption — provides confidentiality and integrity.
Layer 2: Key Protection at Rest
Workspace keys themselves are encrypted before being stored in our database. This means our database contains encrypted keys protecting encrypted data — two independent barriers, not one.
Layer 3: Device-Bound Key Delivery
When your device needs a workspace key, it is delivered using a one-time transport key that is:
- Derived from your active session and a device-specific secret
- Unique to each key request
- Never stored anywhere — exists only for the duration of the key exchange
- Bound to your specific device and session
Device Secret
When you first set up RESTK on a device, the app generates a unique device secret — a random cryptographic value that stays on your device and is never sent to our servers in its original form. This secret is one of the inputs used to create the transport key for secure key delivery.
- Device binding: A session token alone is not sufficient to request workspace keys — your device secret is also required
- Multi-device independence: Each of your devices has its own secret. Signing out on one device does not affect the others
- No server storage: We never store your device secret. We receive only a one-way cryptographic fingerprint during key exchange operations
If you lose a device, your workspace keys are unaffected — they are safely stored (encrypted) in our key management system. When you sign in on a new device, a new device secret is generated and your workspace keys are securely delivered using the new device's transport key.
Key Rotation
How It Works
RESTK automatically generates new workspace keys on a regular schedule, ensuring that each key protects only a limited window of data.
- A new key version is generated and becomes the active key
- New data is encrypted with the latest key version
- Existing data remains encrypted with its original key version and stays readable
- All historical key versions are retained (encrypted) so older data can still be decrypted
- Each encrypted value carries a version identifier so the correct key is always selected
- Team members receive updated keys automatically during their next sync
What You See
Nothing. Key rotation is invisible. Your data remains accessible and encrypted without any interruption or action on your part.
Zero-Knowledge Architecture
"Zero-knowledge" means our servers have no ability to read your encrypted data during normal operation.
| Scenario | Can RESTK Read Your Secrets? |
|---|---|
| Normal API operation (sync, pull, push) | No — server stores and serves encrypted blobs |
| A RESTK engineer inspects the database | No — they see encrypted strings, not plaintext |
| Database backup is accessed externally | No — backups contain only encrypted data |
| Law enforcement requests data | We can provide encrypted blobs, but not plaintext secrets |
| Full server access is obtained | No — encrypted data without the separate key infrastructure is unreadable |
On-Device Protection
Server-side encryption protects your data on our infrastructure. RESTK also applies multiple layers of protection on your device itself.
Encrypted Local Database
Your workspace data is stored locally in an encrypted database. The encryption key is derived from your identity and bound to your device — the database file is unreadable if copied to another machine or accessed outside the app.
Your authentication data (sessions, tokens) is stored in a separate encrypted database bound to your specific device hardware. This database cannot be transferred or cloned between machines.
macOS Keychain
Sensitive credentials — session tokens, authentication data, and stored passwords — are kept in macOS Keychain. These credentials are:
- Accessible only when your device is unlocked
- Isolated from other applications on the same device
- Protected by the same hardware security that guards your system passwords
Field-Level Encryption
Rather than encrypting your entire database as a single blob, RESTK encrypts each sensitive field independently. Each Bearer token, header value, parameter value, and request body is encrypted separately with its own initialization vector.
- Granular protection: Decrypting one field does not expose any other
- Efficient key rotation: Each field can transition to a new key version independently
- Minimal decryption: The app only decrypts the specific fields needed for display at any given moment
Cached Response Encryption
When RESTK caches API responses on your device for offline access or history, those cached responses are encrypted at rest using a dedicated encryption key managed by macOS Keychain. Clearing your cache securely removes both the encrypted data and its key.
Forward Secrecy on Sign-Out
When you sign out of RESTK, the app regenerates your device secret. Previous session credentials — even if somehow captured — cannot be used to derive transport keys or access workspace encryption keys. Each sign-in session is cryptographically independent.
Log Sanitization
All application logs are automatically sanitized to prevent accidental exposure:
- Tokens and API keys are masked before being written to any log
- Authentication headers (Bearer, Basic, JWT) are redacted to show only a safe prefix
- Personal information (email addresses, user IDs) is partially masked
- Sensitive patterns (credit card numbers, phone numbers) are detected and redacted automatically
AI Assistant Safeguards
When using AI assistants via MCP (Model Context Protocol):
- Explicit approval required: Every AI-initiated action that modifies data requires your confirmation
- Visibility controls: Only data explicitly marked as shared with AI is accessible to assistants
- Per-action confirmation: There is no "approve all" mode — each write operation is individually reviewed
Team & Organization Security
All encryption protections apply equally to shared team workspaces. Each team member's device independently encrypts and decrypts data. The server moves encrypted data between devices without ever accessing the plaintext.
Shared Workspace Key Model
Every team member with workspace access receives the same workspace key, delivered independently through their own device-bound transport mechanism. The workspace key is the same for all authorized devices, but the mechanism to deliver it is unique per device per session.
| Device | Device Secret | Transport Key | Workspace Key |
|---|---|---|---|
| Alice's laptop | Unique to laptop | Derived from laptop session + secret | Same workspace key |
| Alice's desktop | Unique to desktop | Derived from desktop session + secret | Same workspace key |
| Bob's laptop | Unique to Bob's laptop | Derived from Bob's session + secret | Same workspace key |
Per-Workspace Key Isolation
Organizations typically have multiple workspaces. Each has completely independent encryption keys.
| Workspace | Encryption Key | Members |
|---|---|---|
| Production APIs | Key A (independent) | Alice, Bob, Charlie |
| Staging APIs | Key B (independent) | Alice, Bob, Dave |
| Internal Tools | Key C (independent) | Alice, Eve |
Exposure of Key B (Staging) would have zero impact on Production APIs or Internal Tools. Workspace key isolation is absolute.
Member Onboarding
When a new team member is added:
Admin Adds Member
Admin adds the member to the organization and assigns them to specific workspaces with appropriate roles.
Member Installs and Signs In
The member installs RESTK and signs in on their device.
Automatic Key Exchange
On first sync, the member's device automatically generates a device secret, requests workspace keys for each workspace they have access to, and receives keys via secure, device-bound transport.
Ready to Collaborate
The member's device decrypts all workspace data locally. No manual key exchange, no shared passwords, no setup scripts.
Member Offboarding
When a team member is removed:
- Admin removes the member from all workspaces and the organization
- API access is immediately revoked
- The member can no longer request or receive workspace keys
Rotate Credentials After Removing Members
After removing a member who had access to sensitive credentials, rotate the credentials themselves (API keys, tokens, passwords) in addition to removing workspace access. This is standard security hygiene — if someone had access to a credential and no longer should, the credential should be changed.
Role-Based Access
| Role | Can decrypt workspace data? | Can add/modify data? | Can manage members? |
|---|---|---|---|
| Owner | Yes | Yes | Yes |
| Admin | Yes | Yes | Yes (limited) |
| Editor | Yes | Yes | No |
| Viewer | Yes | Read-only | No |
All roles that can access a workspace can decrypt its data. Encryption ensures your data remains protected at every layer — on our servers, in transit, and at rest. Within the workspace, access control is enforced by role-based permissions at the application layer.
Compliance
RESTK's encryption architecture supports compliance with several common frameworks:
| Framework | Relevant Controls |
|---|---|
| SOC 2 Type II | Encryption at rest (CC6.1), encryption in transit (CC6.7), logical access controls (CC6.3) |
| GDPR | Data protection by design (Article 25), security of processing (Article 32) |
| HIPAA | Encryption of ePHI at rest and in transit (§164.312(a)(2)(iv), §164.312(e)(1)) |
| PCI DSS | Protect stored cardholder data (Req 3), encrypt transmission (Req 4) |
Compliance Note
RESTK's encryption addresses the technical controls for these frameworks. Full compliance depends on your organization's broader security program, policies, and procedures. We are not claiming certification — we are saying our architecture provides the technical encryption controls these frameworks require.
Audit Trail
All key management operations are logged for audit purposes:
- Key generation events
- Key rotation events
- Key delivery events (which user, which device, which workspace)
- Member addition and removal events
These logs are available to organization admins and can support your compliance audit requirements.
FAQ
Is my data encrypted during transit?
Yes. All communication between your device and RESTK servers uses HTTPS (TLS 1.2+), which encrypts data in transit. But more importantly, your sensitive data is also encrypted before transit — so your data has two independent layers of protection during every transfer.
Can RESTK employees see my API keys?
No. During normal operations, your sensitive data exists in plaintext only on your device. Our database contains encrypted values that cannot be read without the key infrastructure.
What encryption algorithm is used?
AES-256-GCM (Advanced Encryption Standard with 256-bit keys in Galois/Counter Mode). This is an authenticated encryption algorithm approved for protecting classified information by the U.S. National Security Agency.
Does encryption slow down the app?
AES-256-GCM is extremely fast on modern hardware — most processors have dedicated AES instruction sets. Encryption and decryption add negligible latency (microseconds) to your operations.
Can I disable encryption?
No. Workspace encryption is enabled by default and cannot be disabled.
What if RESTK shuts down?
You can export your workspace data at any time. The export produces a readable file with your decrypted data, which you own and control.
Is my data safe if someone copies my local database file?
Yes. Your local database is encrypted with a key derived from your identity and bound to your specific device. Copying the database file to another machine produces an unreadable file.
Can different team members have different encryption levels?
No. Encryption is applied uniformly to all workspace data. All members with workspace access can decrypt all encrypted fields in that workspace. If certain team members should not see certain credentials, use separate workspaces for different sensitivity levels.
Does key rotation cause any downtime?
No. Key rotation is a background operation. New data uses the new key; old data uses the old key. Both keys are available to authorized team members. There is zero downtime or disruption.
Can AI assistants access my data without my knowledge?
No. RESTK's AI assistant integration requires your explicit approval for every action that reads or modifies your data. Only data you have specifically marked as shared with AI is visible to assistants.
Is there a limit on team size for encryption?
No. The encryption model scales with team size. Each new member receives workspace keys through the same secure mechanism regardless of whether the team has 3 or 300 members.
How do we handle contractor access?
Treat contractors like any other team member: add them to relevant workspaces with the minimum role required, remove them from all workspaces when their engagement ends, and rotate any credentials they had access to.
What happens if a team member loses their device?
Your data remains protected by multiple layers. The local database is encrypted with a device-bound key that cannot be reconstructed on another machine. Credentials are stored in macOS Keychain, which requires the device to be unlocked. If the team member signs out remotely (revoking their session), the device can no longer request workspace keys from the server.
Summary
Your data is protected by AES-256 encryption with a layered key architecture at every level:
- On our servers — data is stored as encrypted blobs that cannot be read without the separate key infrastructure
- In transit — data is encrypted on your device before transmission, with HTTPS providing a second layer
- On your device — local database encryption, macOS Keychain integration, and field-level encryption
- Across teams — per-workspace key isolation, device-bound key delivery, and automatic key rotation
Have questions about our security architecture? Reach out at [email protected].