Frontend Layer
- React SPA served over HTTPS
- All sensitive UI operations client-side encrypted
- No plaintext content written to browser storage
- Auth tokens managed in memory, not localStorage
For security teams
Shield Desk Security Overview
Detailed diagrams, threat model, and implementation notes for security teams evaluating Shield Desk's architecture, data handling, and operational controls.
Book a technical demoDetailed Diagrams
System Architecture
The major components and how they interact, from the browser to the encrypted entity store.
Tap a layer, or scroll for the full detailDetailed diagrams
System architecture
Shield Desk is deployed entirely within its own secure platform environment. These are the major components and how they interact.
API & Function Layer
- Shield Desk backend functions in a secure runtime
- Each function authenticated via request-scoped SDK
- Service-role elevation only after a user auth check
- No direct database access from the client
Data & Storage Layer
- Shield Desk entity store, encrypted at rest
- Private file storage for attachments
- Signed, time-limited URLs for file access
- No raw message content in operational logs
Component interaction flow
User DeviceEncrypt at origin
HTTPS / TLS 1.3Transit protection
Shield Desk APIAuth and routing
Function RuntimeBusiness logic
Entity StoreEncrypted at rest
Detailed diagrams
Network topology
Shield Desk operates on a closed-network model. All service communication flows through authenticated, TLS-encrypted channels, and external integrations are isolated to dedicated function boundaries.
Internal service communication
Client to Shield Desk APITLS 1.3 only
Function to Entity StoreInternal VPC
Function to File StorageSigned URLs, scoped
Function to Auth ServiceToken-validated
External integration boundaries
OAuth ConnectorsIsolated function scope
Notion / Google APIsAccess token, no persist
Webhook endpointsSignature-verified
AI inference callsOpt-in, documented flow
Network segmentation principles
- No direct client access to the database or storage layer. All access is mediated through Shield Desk's authenticated backend functions.
- External integrations run in isolated function contexts and cannot access unrelated entity data.
- Webhooks from third-party providers are validated via cryptographic signature before processing.
- All outbound API calls to external services use short-lived OAuth access tokens scoped to the minimum required permissions.
Detailed diagrams
Data flow
Different data types follow distinct paths through the system, each with the appropriate encryption and access controls applied at the point of creation.
Message Content
- User composes message on the client
- Encrypted before transmission
- Stored encrypted in the entity store
- Decrypted only for authorised recipients
- Never written to system logs
File Attachments
- File selected by user on the client
- Uploaded via the UploadFile integration
- Stored in private file storage
- Accessed only via signed, time-limited URLs
- URL expiry enforced server-side
Operational Metadata
- Event occurs: login, access, or config change
- Timestamped event record created
- Stored in a tamper-evident audit log
- Accessible to authorised admin roles only
- Retained per documented retention policy
Integration Data
- OAuth token obtained for a connector
- Token used for a scoped API call
- Response processed in function context
- Relevant data persisted to the entity store
- Token not stored beyond the function lifetime
Client-side security
File encryption: zero-knowledge by design
Sensitive files are encrypted entirely within the user's browser before they ever reach Shield Desk's servers or cloud storage. This means Shield Desk cannot view the contents of your encrypted files.
User initiates upload
A user selects the Encrypted File option when uploading in Partner Comms, messages, or Chambers.
Client-side key generation
Shield Desk's frontend code, running entirely in the user's browser, generates a unique encryption key and Initialization Vector. These are randomly generated and never leave the browser in an unencrypted state.
Client-side file encryption
The file is encrypted directly in the browser using the generated key and IV, transforming readable content into ciphertext. The original file never leaves the device unencrypted.
Encrypted upload to decentralised storage
Only the encrypted file is sent to our partner's decentralised storage network. Shield Desk's backend receives the encrypted blob, a Content Identifier, and file metadata such as name and size, never the original content.
Key and IV management, client-side only
After upload, the raw key and IV are shown to the user in their browser. The user can copy and store them, or save them to their Shield Desk Key Vault, where the keys are re-encrypted client-side using a user-defined Vault Password. The Vault Password is never sent to or stored on Shield Desk servers.
File sharing and decryption
Recipients receive a link to the encrypted file and the re-encrypted keys. Decryption occurs entirely in the recipient's browser using their Vault Password to unlock the file keys. The unencrypted content is never exposed to Shield Desk's servers.
Why Shield Desk cannot see your files
Encryption happens locally
Files are encrypted in your browser before being sent anywhere. The original content never reaches Shield Desk's infrastructure.
Keys never leave your browser unencrypted
Raw encryption keys are never transmitted to Shield Desk's backend. They are managed by the user or encrypted again with a client-side Vault Password before storage.
Shield Desk handles only ciphertext
The backend stores only scrambled file data and double-encrypted key information. Without the user's client-side passphrase and file keys, the content stays inaccessible, even to us.
This architecture keeps data confidential between the sender and authorised recipients, with Shield Desk acting as a secure, yet blind, facilitator.
Threat model
Identified threats and mitigations
We model threats across several categories. For each, we describe the attack vector and the specific controls implemented in Shield Desk to reduce risk.
Provider-side data access
Attack vector
Platform operator reads stored message content from the database or logs.
Mitigation
Message content is encrypted before storage. Operational logs avoid raw content. Provider access to plaintext is limited by design, not just policy.
Credential theft and session hijack
Attack vector
Attacker obtains a valid auth token via phishing, leaked secrets, or session fixation.
Mitigation
Auth tokens are short-lived and request-scoped. The auth layer enforces token expiry and rotation. All sensitive operations re-validate identity server-side.
Unauthorised access via misconfiguration
Attack vector
A misconfigured role or sharing link exposes data to unintended parties.
Mitigation
Fine-grained RBAC is enforced at the API layer. File access requires time-limited signed URLs. Workspace boundaries are cryptographically isolated.
Third-party integration compromise
Attack vector
A compromised OAuth connector or external service injects malicious data or exfiltrates tokens.
Mitigation
Integrations run in isolated function scope. Tokens are short-lived and never persisted beyond the function call. Webhook payloads are signature-verified before processing.
Cross-site scripting (XSS)
Attack vector
Malicious script injected via user-generated content renders in another user's browser.
Mitigation
React's JSX rendering escapes all user content by default. Content Security Policy headers are enforced. User markdown is rendered through a sanitised component with no raw HTML execution.
Insider misuse and data exfiltration
Attack vector
Authorised user intentionally exports or leaks sensitive data.
Mitigation
All access events are written to a tamper-evident audit log. Admin actions require elevated role verification. File download links are single-use and expiry-enforced.
Implementation notes
The controls behind the guarantees
Authentication & Authorisation
Shield Desk Auth Layer
- All authentication is handled by the Shield Desk platform, with no custom auth implementation.
- Session tokens are request-scoped and validated server-side on every function invocation.
- The auth SDK binds the caller's identity to the request context.
- Unauthenticated requests return 401 before any business logic executes.
Role-Based Access Control
- User roles (admin and user) are enforced at both the API and entity access levels.
- Admin-only functions explicitly check the admin role and return 403 if not met.
- Entity-level security rules restrict which records each role can read, write, or delete.
- Regular users can only view and update their own record.
Data Protection & Key Management
Encryption at Rest and In Transit
- All data in the entity store is encrypted at rest using AES-256.
- All client-server communication is enforced over TLS 1.3.
- End-to-end encryption is applied to message content and file attachments in supported flows.
- Private file storage is separate from the entity store; access requires time-limited signed URLs.
Key Management Principles
- Keys for supported workflows are generated client-side and never transmitted in plaintext.
- Decryption keys are not stored on Shield Desk servers; we cannot recover content without the key holder.
- The secure Key Vault stores user-managed keys in encrypted form, accessible only to the key owner.
- Encrypted attachments use per-session key derivation; the derived key is ephemeral.
Data Retention
- Operational metadata is retained for the minimum period required to run and secure the service.
- Raw message content is not written to system or application logs.
- Signed file access URLs expire automatically; expired URLs cannot retrieve files.
- Retention periods and data categories are documented and reviewed periodically.
Secure Communication
Direct & Group Messages
- Messages are encrypted before leaving the sender's device in supported flows.
- Content is not accessible in plaintext to the platform operator.
- Message metadata is minimised and not linked to content.
Partner Communications
- Cross-organisation workspaces use isolated scopes; neither party can access the other's internal content.
- File attachments in Partner Comms are encrypted with per-session keys.
- Partner session boundaries are enforced cryptographically, not by application policy alone.
Chambers (Voice & Video)
- Chamber sessions run in encrypted, isolated scopes.
- Session data is ephemeral, with no persistent recording unless explicitly configured.
- Access requires valid workspace membership and an active auth session.
Secure Coding Practices
Frontend Hardening
- React JSX auto-escapes all rendered content, with no unsanitised raw HTML injection.
- User markdown is rendered through an allowlist of safe elements only.
- No sensitive credentials or tokens are stored in localStorage or sessionStorage.
- Content Security Policy headers restrict script execution to trusted origins.
Backend Hardening
- Backend functions run in a secure-by-default runtime with no implicit filesystem or network access.
- Input validation is performed before any entity read, write, or external API call.
- SQL injection is not applicable; a parameterised query interface exposes no raw SQL.
- Webhook payloads are validated via provider-issued cryptographic signatures before processing.
Compliance & Auditing
Compliance Alignment
- Designed to support GDPR-aligned data handling: minimisation, purpose limitation, and documented retention.
- Security controls are informed by NIST Cybersecurity Framework principles.
- No customer message content is used for advertising, analytics, or model training.
- Third-party audits and certifications will be published as they are completed.
Security Event Logging
- Authentication events are logged with timestamp and identifier.
- Administrative actions are written to a tamper-evident audit log.
- File access events record who accessed what and when, without logging raw content.
- Logs are monitored for anomalous patterns, including unusual access volumes and off-hours admin activity.
Integrations Security
OAuth App Connectors
- OAuth flows request only the minimum scopes required for the specific feature.
- Access tokens are retrieved at runtime and never persisted to the database.
- Shared connectors use the builder's account; app-user connectors isolate each user's token.
- Token revocation immediately terminates connector access.
API Key Management
- API keys for external services are stored as encrypted environment secrets, not in code.
- Keys are accessed within backend functions and never exposed to the client.
- Each secret is scoped to the specific function that requires it.
- Key rotation is performed via the secrets interface without code deployment.
Third-Party Data Boundaries
- Data from external integrations is processed in isolated function scope.
- Only the fields explicitly required are persisted to Shield Desk entities.
- External services do not receive user credentials or internal entity IDs.
- Integration failures do not expose internal data; errors are caught and sanitised.
Due diligence
What we protect against, and what stays yours
A concise summary of what Shield Desk's architecture is designed to protect against, and where your own controls remain essential.
Designed to protect against
- Vendor compromise: encrypted content is inaccessible even if Shield Desk infrastructure is breached.
- Insider threat, provider-side: operational staff have no routine access to decrypted content.
- Legal compulsion: where content is encrypted client-side, we cannot produce plaintext in response to a subpoena.
- AI vendor exposure: customer content is not sent to AI infrastructure without explicit opt-in and a documented data flow.
- Man-in-the-middle: all communication is enforced over TLS 1.3, and client-side encryption adds a second layer.
- Misconfigured sharing: workspace boundaries, signed URLs, and role enforcement limit accidental exposure.
Outside Shield Desk's control
- Compromised endpoints: malware, keyloggers, or screen capture on the user's device bypass all encryption.
- Lost keys without recovery: if a user loses their vault passphrase and has no backup, content cannot be recovered.
- Social engineering of authorised users: a legitimately authenticated user can share or export data.
- Weak passwords and credential reuse: authentication strength depends on your identity provider and user behaviour.
- Broader network and device security: we do not control your organisation's perimeter or endpoint posture.
Sub-processors
The third parties that process or store data on behalf of Shield Desk.
| Provider | Purpose | Location |
|---|---|---|
| Shield Desk Platform | Application hosting, entity store, function runtime | EU / US |
| Cloud Storage Provider | Private encrypted file storage | EU (primary) |
| AI Inference Provider | Optional AI features, opt-in only | US (documented per feature) |
| Email Delivery | Transactional notifications and invitations | EU / US |
| Payment Processor | Subscription billing, no card data touches Shield Desk | US |
We commit to at least 30 days of advance notice of any material change to this list, and customers may object to additions within that period. A maintained list is available on request.
Due diligence
Data residency
Shield Desk supports data residency selection at the organisation level. Your choice determines where customer content and operational metadata are stored at rest.
🇬🇧Available
United Kingdom
UK GDPR aligned. Data remains within UK data centre boundaries.
🇪🇺Available
European Union
GDPR Article 44 compliant. EU-based storage and processing.
🇺🇸Available
United States
Controls aligned to US enterprise security expectations. Suitable for US-primary organisations.
- Data residency is configured at onboarding and can be changed by request with 30 days of notice.
- Sub-processor locations are aligned to your selected residency region where technically feasible.
- Cross-region data transfers for AI features are documented per feature and require explicit opt-in.
- Contact us to confirm residency options for your specific use case.
Due diligence
Incident response commitments
In the event of a confirmed security incident affecting customer data, Shield Desk follows a structured response process with clear notification timelines.
Notification timelines
Initial customer notification72 hours or less
Regulatory notification, where required72 hours or less
Incident status updatesEvery 24 hours
Full post-incident report14 days or less
Response procedures
- A named security contact is available for all enterprise customers.
- Affected customers are notified directly via their registered security contact email.
- Notifications include the nature of the incident, data categories potentially affected, remediation steps taken, and recommended actions.
- Regulatory bodies are notified in line with GDPR Article 33 obligations and applicable US state laws.
- Post-incident reviews are conducted and findings shared with affected customers on request.
Due diligence
Vulnerability disclosure policy
We welcome responsible disclosure from the security research community. If you discover a potential vulnerability in Shield Desk, please follow the process below.
How to report
- Email security@getshielddesk.com with a clear description, steps to reproduce, and potential impact.
- Include your contact details if you would like to be kept informed of our progress.
- Do not publicly disclose the vulnerability before we have had a reasonable opportunity to remediate.
- We acknowledge receipt within 2 business days and provide a status update within 10 business days.
Programme details
Acknowledgement2 business days or less
Triage and initial assessment10 business days or less
Critical severity fix target30 days or less
Bug bountyAvailable, contact us
We operate a good-faith disclosure process. Researchers acting in accordance with this policy will not face legal action from Shield Desk. Bug bounty eligibility and amounts are determined case by case.
Walk the architecture with our team
We will map Shield Desk to your compliance requirements and threat model, and help you scope a pilot for your most sensitive workflows.