Skip to content
Enterprise

Security, governance, and control
for production GPU workloads.

Kernalin runs untrusted kernels for a living, so isolation and auditability aren’t features bolted on — they’re how the engine works. Here’s what’s enforced today, and what’s coming for larger teams.

Request early access Explore the platform
Trust boundary first

Built to run code it doesn’t trust.

Optimizing a kernel means executing a candidate you didn’t write. Kernalin treats that as the core threat model: every run is sandboxed and network-isolated, every action is recorded immutably, and governance controls for larger organizations are on the way. We’re explicit about which is which.
Enforced today

Isolation and auditability, already on.

These aren’t roadmap items — they’re the foundation the verification engine already stands on.
Available

Sandboxed, network-isolated execution

Every candidate runs inside a contracts-first sandbox with no outbound network. Untrusted kernels can’t exfiltrate, phone home, or reach beyond the inputs they’re handed — the same isolation that makes anti-cheat trustworthy.

Available

Immutable audit trails

Ingest, verify, benchmark, and gate each write an append-only record with its verdict and evidence. Every shipped speedup traces back to the proof that cleared it — nothing is edited after the fact.

Available Role-based access control is available in the app.
RBAC

Roles that map to how teams actually work.

Three roles with resource-level permissions, so access follows responsibility: who can ingest a workload, who can ship a candidate, who can only look. Every privileged action lands in the audit log, tied to the identity that took it.
AD
Admin
Manage members, roles, and workspace policy. Full control over who can ingest workloads, trigger optimization, and see results.
EN
Engineer
Ingest, profile, optimize, and gate — the full working surface, scoped to the resources their role grants.
VI
Viewer
Read verdicts, reports, and history without the ability to change a workload or ship a candidate.
Available Single sign-on is available: one OIDC or SAML connection per workspace, on a verified email domain.
SSO

Your identity provider, your rules.

Federate access through the directory you already run. Enforce your own MFA and session policy at the IdP; accounts are created on first SSO sign-in. Directory sync (SCIM) is on the roadmap.

SAML 2.0

Signed SAML responses from your identity provider, checked for issuer, audience and replay.

OpenID Connect

Authorization code flow with PKCE, with ID tokens verified against your provider’s keys.

Okta

Connect Okta over OIDC or SAML 2.0.

Microsoft Entra ID

Connect Entra ID (Azure AD) over OIDC or SAML 2.0.

Available
Workspace isolation

Separate teams. Separate blast radius.

Workspaces keep each team’s workloads, results, and members walled off from the others. Data and history stay scoped to the workspace that owns them, so an experiment in one org can’t leak into — or be seen by — another. Combined with sandboxed execution, isolation runs from the identity layer all the way down to the kernel run.
01 Scoped workloads & history available
02 Per-workspace membership available
03 Isolated results & reports available
04 No cross-workspace visibility available
Talk to us

Bringing Kernalin to a larger org?

Tell us about your security requirements, your identity stack, and how your teams are structured. We’ll walk you through what’s enforced today, share the governance roadmap, and figure out where early access fits.
Talk to us Read the security model
Early access is open

Enterprise-grade from the trust boundary up.

Isolation and audit trails today, governance controls next. Bring verification-first GPU optimization to your organization.

Request early access Explore the platform