Security
Infino is a retrieval engine over Apache Parquet in object storage: keyword, vector, hybrid search, and SQL. Durable data is the files in the bucket. Isolation, authentication, encryption, and deletion differ across the self-hosted engine, Infino Cloud, and a dedicated deployment.
A SOC 2 Type II audit is underway. A Data Processing Agreement and architecture review are available on request; the report will be available after completion.
The engine
The engine is Apache-2.0. The retrieval path, the write path, and the manifest that names a commit are source you can read.
Tables are Parquet in S3, Azure Blob, GCS, or local disk. BM25 and vector indexes live inside those files, which remain standard Parquet after Infino is stopped.
Object storage is the system of record. Commits are an atomic swap of a manifest pointer over immutable files. Control-plane records (accounts, hashed keys, placement, metering) live separately from tenant data.
If you run the engine yourself, the process and the bucket are yours. Encryption, IAM, VPC, and deletion are the controls on that environment. Report engine vulnerabilities through GitHub security advisories.
Infino Cloud (beta)
The engine, run by us, multi-tenant on Google Cloud. Compute scales to zero when a database is idle. The object store enforces the tenant prefix.
Isolation
Each tenant’s data sits under its own prefix: <customer>/<database>/. Each database has its own tables and namespace.
Each database is a separate OS process, with its own memory.
A worker receives a short-lived token whose access boundary is that prefix. Google Cloud allows GET and PUT only inside the prefix. Tokens rotate before expiry without restarting the process. A compromised worker is limited to one prefix, for the life of that token.
The tenant is taken from the API key at the gateway. The customer id is the key’s owner.
The gateway authenticates, rate-limits, routes, and mints those tokens. Tenant data is read by the worker. Local disk cache, when used, is a private 0700 directory under a distinct OS user per worker.
Isolation is tested in CI against real cloud storage: a token scoped to one tenant reaches only its prefix, and two tenants with the same database name stay isolated across keyword, vector, SQL, hybrid, writes, and key rotation.
Authentication
API clients send Authorization: Bearer. Keys are 192-bit random secrets. We store a SHA-256 hash and show the plaintext once at creation. Comparison is constant-time. Keys expire, rotate with a grace window, and revoke.
Console users sign in with OIDC (Google and GitHub). Sessions are signed cookies, HttpOnly, Secure, SameSite, 24-hour lifetime. Cookie-authenticated writes also require a CSRF token.
Internal services authenticate to each other with cloud-issued instance identity tokens. A valid API key opens the databases on that account. Dedicated deployments can add per-database keys, read/write roles, and SSO-group mapping.
Encryption
Client traffic is TLS, terminated at the load balancer, with HSTS. Compute to object storage is HTTPS. Data in the bucket is AES-256 with provider-managed keys. Local disks on data nodes use full-disk encryption. Customer-managed keys (CMEK) are available on a dedicated deploy.
Network and compute
Gateway and data-node VMs have no public IP. Ingress to the gateway is the provider front-end and health checks. Administrative access is the provider’s identity-aware proxy. Fleet identities reach Google APIs on the private network. Workers run sandboxed: dropped capabilities, a seccomp allow-list, hard memory limits, and a distinct OS user per tenant.
Operational secrets come from configuration and cloud secret management. Production starts only with production secrets. Object-store access uses ambient cloud identities. The identities that route and mint tokens handle routing and minting; the worker reads tenant data.
Durability, residency, deletion
The bucket is durability. Google rates that class of storage at eleven nines annually. Customer data stays in the region the account is deployed in.
Deleting a database refuses new traffic, removes routing, stops the process, and drops the local cache. That teardown is crash-safe and idempotent. Prefix-wide erasure and record-level deletion are in progress and covered in the DPA.
Dedicated deploy
Single-tenant service in your cloud, on-prem, or hosted by us: your VPC, your keys, the same engine and the same files. Enterprise includes customer-managed keys, region pinning, and a DPA.
Summary
The managed service includes provider-enforced prefix isolation, one process per database, worker sandboxing, TLS, AES-256 at rest, hashed API keys, OIDC console login, least-privilege identities, network lockdown, CI isolation tests, and crash-safe database teardown.
Dedicated single-tenant deployments, customer-managed keys, a DPA, and an architecture review are available on request. The SOC 2 Type II audit, prefix-wide erasure, and record-level deletion work are underway.
Contact
Architecture review, DPA, SOC 2 status, dedicated deploy: infino.ai/talk. Engine vulnerabilities: github.com/infino-ai/infino/security. Privacy: infino.ai/privacy.