Platform Security

KLUE Platform Security

KLUE processes extremely sensitive data: your code, your configurations, and the vulnerabilities we find. Here is exactly how the platform protects it.

Last updated: August 2026

In short

Every scan runs in an isolated, ephemeral sandbox. Findings are stored in your tenant, isolated by row-level security, and encrypted in transit and at rest. Client data is never used to train our models, and for sensitive workloads we can run models so that your data never leaves a controlled environment.

How KLUE secures your data

Hosting

  • KLUE runs on a public cloud provider with per-tenant row-level security on the database and object storage.
  • Each customer's data is isolated at the data layer so one tenant can never access another's data.
  • Cloud hosting, hosted database, and object storage are operated under contract by vetted subprocessors (see the Subprocessors page).

Data residency

  • Customer scan content and findings are stored in the region configured for the tenant.
  • Shellvoide is based in the United States; some subprocessors operate in the US and other countries.
  • For EEA/UK transfers, we rely on appropriate safeguards such as Standard Contractual Clauses or an applicable adequacy decision.

Encryption

  • Data in transit is encrypted with TLS 1.2 or higher.
  • Data at rest is encrypted with AES-256.
  • Passwords and API keys are stored only as salted hashes, never in plain text.
  • Keys used to clone source code from connected repositories are short-lived and scrubbed immediately after use.

AI & model training

  • KLUE uses large language models to plan and carry out testing. Relevant context from your scan, which can include snippets of source code, configuration, or findings, is sent to a model provider to be processed and returned.
  • We send the minimum context needed to complete a task and apply credential redaction before data leaves the sandbox.
  • We use model providers under agreements that restrict the use of submitted data to serving our requests. Where a provider offers controls against using inputs for model training, we enable them.
  • Client engagement data is never used to train our models.
  • KLUE is model-agnostic. For sensitive workloads, locally hosted or self-managed model deployments can be arranged so that data does not leave a controlled environment.

Sandboxed execution

  • Every scan runs inside an isolated, ephemeral virtual machine provisioned by our sandbox provider.
  • Source code is cloned using short-lived tokens that are scrubbed after use.
  • Security engines (cloud audit, code review, live app/API testing, autonomous testing) run inside the sandbox.
  • The sandbox is destroyed when the scan finishes, along with the ephemeral environment and its working copy of your data.

Access controls

  • Access to KLUE customer data is restricted to named personnel with a legitimate need.
  • All access is authenticated and logged, and is attributable to an individual.
  • SSO/SAML and MFA are available for KLUE customers.
  • Outbound connections from scan environments are allow-listed.

Audit logging

  • Access to customer data is logged.
  • Scan activity, findings, and reports are written to storage isolated to your tenant by row-level security.
  • Customers can export findings and reports from their workspace at any time.
01

How a scan runs

You configure a scan in the dashboard and our API checks your plan quota and concurrency limits.

A dedicated sandbox is created each scan runs inside an isolated, ephemeral virtual machine. Source code is cloned using short-lived tokens that are scrubbed after use.

Security engines run inside the sandbox KLUE performs cloud/M365 audits, source code review, live app/API testing, autonomous testing, or threat intelligence collection as configured.

An AI engine reasons over the work KLUE uses large language models to plan, select tools, and interpret results. Relevant context is sent to a model provider for processing, with credential redaction applied first.

Findings stream to storage results, logs, and reports are written to our database and object storage, isolated to your tenant by row-level security.

The sandbox is destroyed when the scan finishes, the ephemeral environment and its working copy of your data are torn down. Reports and findings remain in your workspace until you delete them or your retention period ends.

Need platform-specific details for a security review?

See our subprocessors, privacy policy, and engagement data handling.