Security
Security practices designed for real production workflows.
Cyberdesk is built to protect customer data, limit unnecessary data exposure, handle sensitive inputs with stronger controls, and support a modern SaaS security posture across infrastructure, automation, and AI workflows.
Trust center and certifications
For current trust materials, security documentation, and compliance status, visit our Trust Center. You can also review our public badges below.
Data retention
We follow a data-minimization approach and maintain defined retention policies by data type so information is kept only as long as needed for service delivery, support, reliability, and legal obligations.
Encryption in transit and at rest
Cyberdesk protects customer data with encrypted transport and encryption at rest, alongside access controls and infrastructure hardening.
Highly sensitive data
For highly sensitive data, we use multiple layers of security, including Basis Theory-backed vaulting so secrets are handled separately from normal workflow data.
LLM data handling
Our policy is to prefer zero-data-retention configurations with LLM vendors where supported, while keeping the most sensitive secret classes out of model traffic entirely.
Data retention and retention policies
Cyberdesk is designed around data minimization. We aim to collect and retain only the information needed to operate the product, support customers, maintain reliability, and satisfy legal or contractual obligations.
We maintain retention policies by data class rather than treating all data the same. That means operational data, logs, workflow artifacts, and highly sensitive inputs are handled with different controls and lifecycles based on risk and business need.
- Retention is limited to what is necessary for product operation, support, compliance, and incident investigation.
- Data is not kept indefinitely by default; deletion and cleanup are part of the operating model.
- For sensitive workflows, we favor architectures that reduce how much raw data enters long-lived systems in the first place.
Encryption and platform security
Cyberdesk protects data both in transit and at rest. Encrypted connections are used for service communication, and stored platform data is protected with encryption at rest together with access restrictions and credential controls.
We complement encryption with service-level authorization, environment separation, least-privilege access, and infrastructure hardening so that security does not depend on any single control alone.
- Encryption in transit for customer and service communication.
- Encryption at rest for stored platform data.
- Operational access controls designed to reduce exposure of production systems and data stores.
Highly sensitive data and Basis Theory
For passwords, API keys, and other highly sensitive values, Cyberdesk uses multiple layers of security rather than treating those inputs like standard workflow data. Sensitive values are stored in a secure third-party secret vault powered by Basis Theory.
Those values are handled separately from ordinary inputs, are not broadly exposed across the platform, and are resolved only at the last possible moment during actual computer actions such as typing into a target application.
- Sensitive values are not logged in Cyberdesk.
- Sensitive values are not stored as normal plaintext workflow data.
- Only aliases are persisted where appropriate; the underlying secret material remains in the secure vault.
- After the run completes, sensitive values are deleted from the vault.
LLM data handling and zero-retention posture
Cyberdesk uses AI to power automation, but our security design separates secret handling from model interactions. The most sensitive secret classes do not need to be sent to LLMs at all.
For model traffic more broadly, our policy is to prefer zero-data-retention configurations with LLM vendors where the provider and workload support it. We also aim to keep model inputs scoped to the minimum necessary for the requested task.
- Highly sensitive secrets are kept out of normal model traffic.
- Zero-data-retention settings are preferred with LLM vendors where supported.
- Model inputs are scoped as narrowly as possible for the task being performed.
Supabase isolation and IP restrictions
We isolate access to Supabase-backed systems and limit direct exposure of underlying infrastructure wherever practical. Access to data stores and supporting services is intended to flow through approved service paths rather than broad public entry points.
As part of that model, Cyberdesk restricts database and infrastructure access with network boundaries, service controls, and IP-based restrictions where applicable. The goal is to narrow the set of systems and addresses that can reach sensitive backing services.
- Restricted access paths to backing infrastructure.
- Network-layer controls and IP-based restrictions where applicable.
- Reduced public exposure of critical internal services and data paths.
Monitoring, incident response, and assurance
Security is an ongoing operating function, not a one-time setup task. We monitor core systems for availability and security issues, investigate anomalies, and continue to improve controls over time.
Customers who need additional diligence materials can use our Trust Center, and current operational health is available on our public status page.
- Ongoing monitoring of core systems and reliability signals.
- Internal processes for investigating incidents and improving controls.
- Additional review materials available through our Trust Center.
Questions and security reviews
If you need more detail on Cyberdesk's security program, would like to review documentation, or want to discuss a specific compliance or architecture requirement, contact mahmoud@cyberdesk.io.