Security

Veri runs training jobs and serving deployments on GPU infrastructure that we provision on your behalf. This page describes how workloads are isolated, how tenant boundaries are enforced, and how credentials are handled. For how we collect and use personal information, see our Privacy Policy.

1. Isolation model

• Single-tenant GPU instances. Every training job and every deployment replica runs on its own dedicated GPU instance. We do not pack workloads from different customers onto the same machine, and we do not slice GPUs across tenants.
• Ephemeral compute. Training instances are terminated when the job completes, fails, or is cancelled, and their local disks (downloaded datasets, model weights, temporary files) are destroyed with the instance. Serving instances are torn down the same way when a deployment is stopped or scaled down.
• Sandboxed custom code. Code you bring yourself (custom training scripts run via run-script and similar bring-your-own-code paths) executes inside a gVisor (runsc) sandbox on the instance, which intercepts system calls and separates your code from the host runtime.

2. Tenant boundaries

• Owned-resource checks. Every API resource (jobs, datasets, models, deployments, evaluations) is looked up scoped to the authenticated account. Requests for a resource you do not own return not-found; ownership is verified before any read or write.
• Per-tenant storage prefixes. Customer content in object storage lives under prefixes owned by your account, and the control plane verifies ownership before signing any access to it.
• Scoped presigned URLs. GPU workers receive short-lived presigned URLs for exactly the artifacts their job needs. Workers have no broad bucket credentials and cannot enumerate or read other customers' data.
• Per-job callback tokens. Each job is issued a unique random token for reporting status and uploading artifacts, so one job cannot impersonate another or push updates into someone else's job.

3. Credential handling

• API keys are hashed. Veri stores only a SHA-256 hash of each API key (plus a short display prefix). The full key is shown once at creation and cannot be recovered from our database.
• Integration credentials are encrypted. Third-party credentials you connect (for example Weights & Biases or Hugging Face tokens) are stored encrypted at rest in our database.
• Signed web sessions. The dashboard authenticates through our identity provider and proxies requests to the control plane with HMAC-signed headers, so browser sessions cannot forge control-plane identity.
• Constant-time comparison. Internal master-key authentication uses constant-time comparison to prevent timing attacks.

4. Network & infrastructure

• Managed control plane. The Veri control plane runs as containers on AWS Fargate; we do not operate long-lived self-managed servers for the API.
• Encryption in transit. API, dashboard, and data-transfer traffic uses HTTPS/TLS. Customer content in object storage is encrypted at rest with server-side AES-256.

5. Responsible disclosure

If you believe you have found a security vulnerability in Veri, email daniel@veri.studio with enough detail for us to reproduce the issue. We will acknowledge your report promptly and keep you informed as we investigate and fix it. We will not pursue legal action against researchers who test in good faith, avoid privacy violations and service disruption, and give us a reasonable window to remediate before public disclosure.

6. Compliance

Veri is an early-stage product and does not yet hold SOC 2, ISO 27001, or similar certifications. We are happy to walk through our security posture, architecture, and roadmap with prospective customers: email daniel@veri.studio or book a call.