Security & trust

Built to be trusted.

Kernalin runs untrusted GPU code for a living. Trust isn't a policy page here — it's an engineering property, wired into how workloads are ingested, isolated, and verified. Where your data goes is spelled out in our privacy policy: the Explain and Optimize features send kernel source to Anthropic's Claude models via OpenRouter.

Request early access Explore the platform

Foundations

Trust engineered into the pipeline.

Four properties hold on every workload you send. These are available today — badged accordingly, with roadmap items kept honestly separate below.

Sandboxed, network-isolated execution

Every workload runs inside a sandbox with no network access, as an unprivileged user on a read-only root filesystem, with resource limits. A built-in self-test checks the isolation on each runner.

Available

Static scanning that never runs your code

On intake, uploads are statically analyzed — never executed. The scanner refuses malicious pickles, banned imports, zip-bombs, and path-traversal payloads before anything touches a GPU.

Available

Immutable audit trail + content-addressed storage

Runs, verdicts, and artifacts are content-addressed and append-only. Every number has a durable, tamper-evident record behind it.

Available

Verification as a trust property

Anti-reward-hacking isn't just about correctness — it's a security posture. A kernel can't quietly drop work, memorize outputs, or game the benchmark past the graders.

Available

Static security scanning

Nothing runs on intake.

The safest way to handle a malicious upload is to never execute it. Kernalin statically analyzes every workload the moment it arrives and refuses anything that looks like an attack — long before a sandbox, let alone a GPU, is involved.

Available

Refused before execution

Malicious or arbitrary-code pickles

Banned / dangerous imports

Zip-bombs and decompression abuse

Path-traversal in archive members

Content-addressed

Every artifact is identified by its hash — you can prove exactly what was measured.

Append-only

Run history is immutable. Verdicts are recorded, never quietly rewritten.

Auditable

A metric-diff and provenance trail sits behind every reported speedup.

Audit & provenance

A record you can stand behind.

When you gate a production deploy on a Kernalin verdict, you need to prove later what was run and what was decided. Content-addressed storage and an immutable audit trail mean the number and the evidence behind it can't drift apart.

On the roadmap

Enterprise controls, honestly staged.

The following are planned, not shipped. We badge them Roadmap and make no compliance claims we haven't earned.

Multi-factor authentication

TOTP and WebAuthn for password sign-in. Today, teams that need MFA can enforce it through SSO (OIDC or SAML), which is available now alongside RBAC.

Roadmap

Directory sync

SCIM provisioning and deprovisioning from your identity provider. Today, SSO accounts are created on first sign-in.

Roadmap

Formal compliance certifications

Independent compliance attestations are planned. We make no certification claims today.

Roadmap

Kernalin does not currently hold any formal security or compliance certification. Any such certifications listed here are planned and will only be claimed once independently attested.

Responsible disclosure

Found something? Tell us.

If you believe you've found a security vulnerability in kerneln.com, the Kernalin app, the rnx CLI or the VS Code extension, email [email protected] with steps to reproduce. We aim to acknowledge reports within 3 business days and will coordinate disclosure with you. Please don't access other users' data, degrade the service, or disclose an issue publicly before we've had a chance to fix it. Our security.txt has the details.

Report an issue

Early access is open

Trust the number, not the promise.

See how verification makes every Kernalin speedup something you can audit and gate on.

Request early access Explore the platform