Enterprise & Trust

01/Security

Tenancy and isolation

uRun is multi-tenant. Every resource, apps, deploy keys, secrets, sessions, usage, is scoped to your organization (org). The CLI and API authenticate with an org-scoped deploy key, and all operations are filtered to that org. Your functions run as their own deployed runtimes on GPU capacity provisioned for your org.

The precise runtime isolation boundaries (per-tenant network policy, node and GPU sharing guarantees, and the formal isolation model) are part of the security review we share under NDA; contact us.

Secret handling, Vault-backed

Runtime secrets your functions need (model-hub tokens, third-party API keys) are Vault-backed and server-side. You store values in the console under Settings, Secrets; your code declares the names via Credentials(platform=[...]) on the @app.function; uRun injects the matching values as environment variables when the function runs.

• Platform secrets live on the server and never touch a developer's machine and never reach the browser.
• Rotation is value-only: update the secret, and the next session picks it up without a redeploy.
• The env=[...] and optional_env=[...] declarations are a separate, explicit path that forwards values from your local shell at deploy time; use platform= for anything that should stay server-side.

See Credentials in the docs for the full declaration model.

Authentication

uRun separates operator and console auth from your end-users' auth:

• Console and deploy (operators). The console authenticates with WorkOS; org membership and SSO are managed there. Deploys use an org-scoped deploy API key (urun_…), which is the only long-lived credential and must never be shipped to a browser.
• End users (Frontend Auth). When you ship a frontend, your users authenticate against your own identity provider. uRun supports two modes:
  • WorkOS (default in production). Verified against the org's provisioned JWKS.
  • Customer JWT, trusted JWKS. You register your IdP's JWKS URL, issuer, and audience in Settings, Frontend Auth (or via urun auth trust-jwk), and uRun verifies your users' JWTs against it. uRun never mints or stores your JWTs; your IdP issues them, uRun only verifies.

SAML and SCIM provisioning beyond what WorkOS provides is in progress; contact us for your requirements.

Application security

Every change to uRun's own code goes through CI before it ships. That pipeline runs static analysis (SAST), dynamic analysis (DAST), infrastructure-as-code (IaC) scanning, and infrastructure vulnerability scanning. Traffic to and from uRun is encrypted in transit (TLS).

We don't publish the specific tool list, scan cadence, or thresholds here; that level of detail is part of the security review we share under NDA; contact us.

Infrastructure security

uRun's control plane and GPU capacity run on AWS. Data at rest is encrypted, and data in transit is encrypted via TLS.

The specific network segmentation, VPC boundaries, and per-tenant isolation guarantees are covered by the same NDA security review referenced under Tenancy and isolation above.

Corporate security

Employee access to internal systems, source control, cloud infrastructure, and the console's admin tooling, requires single sign-on (SSO) with multi-factor authentication (MFA). Access is scoped to least privilege, and offboarding (revoking access when someone leaves or changes roles) is a formal, defined process.

02/Compliance and certifications

The honest summary: we run org-scoped isolation, Vault-backed server-side secrets, CI-gated scanning, and AWS infrastructure with encryption at rest and in transit today, and we are using those primitives as the foundation for a SOC 2 Type I readiness effort (targeted first), followed by Type II.

03/Vulnerability disclosure

Last updated: June 24, 2026.

uRun welcomes good-faith reports from security researchers. If you believe you have found a vulnerability in a uRun-operated service, email security@urun.sh with the subject Vulnerability Disclosure. Please do not file public issues for security reports.

What to include

Include as much detail as you can, especially:

• The affected service, domain, endpoint, package, or workflow.
• Steps to reproduce, including proof-of-concept code, screenshots, request and response samples, or logs where helpful.
• The potential impact, including what data or capability could be exposed.
• Any known mitigations or conditions needed to exploit the issue.
• Whether the vulnerability has been reported or disclosed anywhere else.

Response targets

We target an initial acknowledgment within 3 business days and a first triage update within 10 business days after receiving enough detail to assess impact or reproduce the issue. These are operational targets, not a contractual SLA.

In scope

We are especially interested in reports affecting uRun-operated production services and customer-facing surfaces, including:

• urun.sh and uRun-operated subdomains such as docs.urun.sh, console.urun.sh, and api.urun.sh.
• uRun customer-facing APIs, SDKs, CLI flows, and hosted docs.
• Authentication, authorization, org isolation, session handling, deploy keys, and frontend JWT verification flows.
• Secrets handling, recording access, data exposure, or business-logic flaws that could affect customer data or workloads.

If you are unsure whether a target is in scope, email security@urun.sh before testing.

Out of scope

The following activity is not permitted under this policy:

• Social engineering, phishing, or contacting uRun employees, customers, or vendors outside the reporting process.
• Physical attacks against offices, hardware, or infrastructure providers.
• Denial-of-service, stress testing, resource exhaustion, or other testing that degrades service reliability.
• Automated scanning, credential stuffing, brute force, or rate-limit testing without prior written coordination.
• Accessing, modifying, deleting, or exfiltrating data that does not belong to you.
• Reports about third-party services or customer-deployed applications that uRun does not operate, unless the issue is caused by uRun's platform.

Research rules and safe harbor

Only test against accounts, organizations, apps, and data you own or are explicitly authorized to use. Stop testing as soon as you can demonstrate the issue, preserve confidentiality, and give us a reasonable opportunity to investigate before public disclosure.

If you follow this policy and act in good faith, we will treat your research as authorized and will not pursue legal action against you for the security research itself. This safe harbor does not cover extortion, privacy violations, data destruction, service disruption, or activity outside this policy.

Bug bounty status

uRun does not currently operate a public bug bounty program and does not guarantee rewards. We may choose to provide discretionary recognition or rewards for original, high-impact, well-documented reports, but any reward is at uRun's sole discretion and may require identity, tax, and compliance checks. If a reward is required before testing, get written agreement from uRun first.

Public disclosure

Please give us up to 90 calendar days from your initial report before public disclosure, unless we confirm remediation sooner or we agree on a different timeline in writing. If a fix needs more time because of scope, customer coordination, or third-party dependencies, we will explain the status and work with you on coordinated disclosure.

04/Reliability and SLA

Our reliability roadmap is built around the control plane (console, API, deploy) and the session data plane (live GPU sessions) as separate tiers, because they fail and recover differently.

What's real today: org-scoped runtimes, Vault-backed secrets, and recording-to-S3 with a 24-hour TTL all ship now (see above). What's on the roadmap toward a signed SLA: a public status page, per-tier uptime reporting, an incident-communications process, and credit-backed SLA terms for eligible plans.

05/Privacy

This section covers how uRun handles the data that passes through the platform. For the legal detail, what personal data we collect, our subprocessors, retention, and how to exercise your privacy rights, see the full Privacy Policy.

Data handling

This is the data handling model for Customer Content, the prompts, files, media, and outputs your workloads process. It is the technical counterpart to the commitments in our Terms of Service.

The headline commitments:

• We never train on Customer Content. Prompts, completions, media, files, and other Customer Content are never used to train, fine-tune, or otherwise improve any model. No feature does this today, and we will not introduce one that does without your explicit opt-in.
• You own your content and you can delete it. Recordings can be deleted at any time, stores and artifacts are deletable when you choose, and app history, session records and their doc state, can be purged on request.
• Metadata never carries content. Usage, billing, and event metadata consists of counts, durations, GPU shapes, and identifiers. None of it includes prompt or completion content.

Where session content lives

uRun's product primitive is the stateful session: it reconnects, parks, and replays. That is the frame for everything retained, surface by surface:

Zero data retention (ZDR)

Zero data retention means a provider stores no Customer Content at all. uRun's default posture is not that: the session model deliberately retains session state so sessions reconnect, park, and replay, and video recordings are on by default. What we can state plainly:

• Customer Content is never used to train or improve any model.
• Inference completions stream in memory and are never recorded.
• Recorded media, audio and video, in both directions, expires after 24 hours by default and can be disabled per stream or for your organization.
• Usage, billing, and analytics carry counts and identifiers only, never content.

If your workload has zero-data-retention requirements, contact security@urun.sh. We will scope the configuration you need, recordings off org-wide, warm-start snapshots off, retention commitments for session records, and put the commitments you need in writing, including in a DPA. We would rather build to your requirement than overclaim.

Session recordings (DVR, S3, 24-hour default TTL)

Session media streams are recorded by default; every session is a DVR you can seek and replay. Recordings are stored in object storage (S3) with a 24-hour default TTL, after which they are deleted automatically; the recordings API (session.recordings in the SDK) lets you list, replay, and pin or retain a recording past the temporary window. You can trace a recording for a session from the console (see Sessions).

Recordings capture media in both directions, the streams your app produces and inbound streams such as a user's microphone, audio and video alike. Token and data streams are never part of media recordings.

If your use case needs a different default retention window, or recordings disabled entirely, contact us.

Other data

• Secrets. Vault-backed, server-side (see Secret handling above).
• Billing and usage. Consumption rolls up per org.
• Control documents and events. Session doc state is kept with the session (see Data handling for the retention model); the event spine carries lifecycle metadata only.
• Product analytics. uRun uses PostHog to understand how the console and docs are used (for example, which pages get visited or which features get adopted). This is separate from your runtime data and Customer Content. See the Privacy Policy for what's collected.

Data protection and residency (roadmap)

GDPR-aligned handling and region-pinned data residency are being designed but are not guarantees you can rely on yet. We run a short, fixed 24-hour recording TTL today as a concrete step in that direction.