Control who can release a model and what its code can access.

Infrastructure under your control

Your team manages networking, identity configuration, secrets, data location, backups and recovery. It controls log access and connections to monitoring or SIEM tools. Support access and diagnostic sharing are agreed with you.

Operating responsibilities

Explicit network requirements

Local execution and full network isolation are different requirements. Review configured identity providers, signed software delivery and operational services before accepting a no-internet requirement.

Connectivity and offline operation

Single sign-on over OpenID Connect

People sign in through configured Okta, Google Workspace or Microsoft Entra ID, using OpenID Connect with the authorization code flow and PKCE. Entra is restricted to your tenant and Google to the domains you allow. With Okta and Entra, configured groups or app roles determine the role of an existing account.

Accounts by invitation only

There is no public sign-up, and single sign-on will never create an account by itself: an account exists only once someone accepts an invitation. Local accounts need a password and a code from an authenticator app at every sign-in, and repeated failed attempts lead to a lockout. Approvals, break-glass and role changes ask for the identity check again.

Roles and approvals

Roles separate viewers, developers, releasers, administrators and auditors. Auditors can review models, call records, the audit log and evidence without changing them. Payload visibility follows the environment’s data policy and the auditor’s permissions. An account created or given a higher role in the last 72 hours does not count toward the approvals a promotion needs without a second administrator.

Scoped API keys

API keys are shown once, stored only as a keyed hash and checked in constant time. Each key belongs to one environment and carries its own scopes, services, rate limit, daily quota, allowed networks and expiry, and the application shows the expiry status of each key. A key can be rotated with a grace period or revoked at once. A network that keeps sending refused requests is turned away before any key is read.

Built not to crash

Every input has a numeric limit, memory use is bounded and every input and output operation has a timeout. Going over a limit returns a clear error, and the platform keeps running.

Isolated execution

Workbook calculations never run inside the API. Each version runs isolated, with no network or file access and strict limits on memory and time. A failure becomes a clear error for the caller, and every other service keeps running.

Isolated builds

An uploaded workbook is processed apart from the platform’s data and secrets, without network access. The platform never relies on that processing’s own report of what it produced.

Masked, encrypted call history

Each environment keeps full inputs and outputs, masked ones or metadata only. In production, inputs and outputs are kept for 30 days by default, encrypted and masked in display and export, while request IDs, metadata and receipts are kept for ten years by default.

Erasure and legal hold

Planned: on request, erase a data subject’s call inputs and outputs so the running service can no longer read them, while request IDs, metadata and receipts stay for their retention period; and legal holds that block the deletion of the records they cover, approved through maker-checker.

An audit chain without personal data

The tamper-evident audit log’s hash chain holds no personal data. Names, email and IP addresses are kept apart from it and anonymized when their retention ends, without breaking its proof of integrity.

Audit log and receipts