Security & Encryption
How RESTK protects your API secrets with AES-256-GCM client-side encryption and per-workspace key isolation — and what our managed cloud sync does not protect against.
RESTK encrypts your sensitive API data on your device before it reaches our servers, using per-workspace AES-256-GCM keys.
Cloud sync uses managed encryption. The threat model below sets out exactly what it does and does not defend against.
If you need a mode where we cannot decrypt your data even in principle, use a local or git workspace. Local needs no account and no network at all; git keeps your workspace data as files in a repo you own, though Git Sync still requires a RESTK account.
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 (Stored as Ciphertext)
| 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 gets an external attacker to your data — each layer serves a distinct purpose and has to be defeated separately. The layers raise the cost of an outside compromise; they do not put the data beyond our own reach, since the keys are server-managed.
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 barriers against an attacker who reaches the database alone. Note that both barriers are ours: the keys that unwrap workspace keys are held by us, so this raises the cost of an external compromise, not our own ability to decrypt.
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.
Threat Model
Encryption at rest and in transit defends against a specific set of attacks, and not others. Rather than summarise it with a label, here is what it does and does not defend against.
| Scenario | Can RESTK Read Your Secrets? |
|---|---|
| Normal API operation (sync, pull, push) | No — the server stores and serves encrypted blobs; nothing decrypts on this path |
| A database backup leaks, keys untouched | No — backups contain only encrypted data |
| An attacker gets the database but not the keys | No — encrypted data without the key infrastructure is unreadable |
| RESTK decrypts it | Yes — decryption happens in the RESTK app, using keys we manage |
The first three rows are what encryption buys you: an attacker who reaches the database, a backup, or the sync path gets ciphertext. The last row is its limit. Managed encryption defends your data against outside access; it does not put your data beyond our reach. If you need the latter, use a local or git workspace.
If that is unacceptable, do not use cloud sync
Use a local workspace (nothing leaves your machine, no account and no network required) or a git workspace (plain files in a repo you own — note that Git Sync still requires a RESTK account). In both, your workspace data never passes through a server of ours under a key of ours, so we cannot decrypt it. Values marked secret are never synced and never committed, in any mode.
Why sync works this way
Managed keys are what make server-side team features possible: workspace invites without a key-exchange ceremony, recovery when a laptop dies, and adding a teammate without every existing member re-encrypting their data. It is a deliberate trade of one property for another, not an oversight. If the trade does not suit your work, local and git workspaces do not make it.
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.
OS Secure Store
Sensitive credentials — session tokens, authentication data, and stored passwords — are kept in the OS secure store (macOS Keychain / Windows Credential Manager). 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 held in the OS secure store (macOS Keychain / Windows Credential Manager). 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, and the server stores and serves ciphertext — nothing on the sync path decrypts it. But this is managed encryption: the workspace keys are server-managed, so RESTK is technically able to decrypt synced data. We do not call it end-to-end or zero-knowledge, because it is not. See the threat model.
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
Workspace roles are Owner, Manager, Editor, and Viewer. (Organization roles — Owner, Admin, Member — are separate.)
| Workspace role | Can decrypt workspace data? | Can add/modify data? | Can manage members? |
|---|---|---|---|
| Owner | Yes | Yes | Yes |
| Manager | 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
We are not certified against any of these
RESTK holds no compliance certification. What follows is not a claim of coverage — it maps our encryption architecture to the technical encryption controls these frameworks specify. Full compliance depends on your organization's broader security program, policies, and procedures.
Technical encryption controls these frameworks specify
| Framework | Encryption Controls Our Architecture Addresses |
|---|---|
| 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) |
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?
Not during normal operations. Your synced data is stored encrypted and nothing on the sync path decrypts it, so an engineer browsing the database sees ciphertext. But because sync uses managed encryption, RESTK as an organization is able to decrypt. Access is restricted and audited, but it is not impossible by design.
If "impossible" is the bar you need, use a local or git workspace. Values marked secret are never synced in any mode, so they never reach us at all.
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 the OS secure store (macOS Keychain / Windows Credential Manager), 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, unreadable without the key infrastructure (see the threat model)
- In transit — data is encrypted on your device before transmission, with HTTPS providing a second layer
- On your device — local database encryption, OS secure store integration (macOS Keychain / Windows Credential Manager), 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].