Standard
  • Docs
  • Examples
  • Pricing
  • About

Get started

  • Overview
  • How Standard works
  • Run your first task
  • Connect
  • Join a Space

Build

  • Examples
  • Operation profiles
  • Integration reference

Concepts

  • Inputs and permissions
  • Accounts and billing
  • Results and lifecycle
  • Verification checks
  • Follow-on tasks
  • Cleanup

Security

  • Security model
Documentation menu

Get started

  • Overview
  • How Standard works
  • Run your first task
  • Connect
  • Join a Space

Build

  • Examples
  • Operation profiles
  • Integration reference

Concepts

  • Inputs and permissions
  • Accounts and billing
  • Results and lifecycle
  • Verification checks
  • Follow-on tasks
  • Cleanup

Security

  • Security model
Standard

Managed confidential execution for sensitive functions.

© 2026 Standard Runtime, Inc. All rights reserved.

  • Security
  • Docs
  • Examples
  • Pricing
  • FAQ
  • About
  • Contact
  • Terms
  • Privacy
  • Cookies
  • Docs
  • Examples
  • Pricing
  • About
  • Get started

    • Overview
    • How Standard works
    • Run your first task
    • Connect
    • Join a Space

    Build

    • Examples
    • Operation profiles
    • Integration reference

    Concepts

    • Inputs and permissions
    • Accounts and billing
    • Results and lifecycle
    • Verification checks
    • Follow-on tasks
    • Cleanup

    Security

    • Security model

    Get started

    • Overview
    • How Standard works
    • Run your first task
    • Connect
    • Join a Space

    Build

    • Examples
    • Operation profiles
    • Integration reference

    Concepts

    • Inputs and permissions
    • Accounts and billing
    • Results and lifecycle
    • Verification checks
    • Follow-on tasks
    • Cleanup

    Security

    • Security model

    Overview

    Start with one sensitive function: what Standard manages, what owners control, and how a recipient verifies the permitted result.

    Standard is a managed confidential execution service: approved Wasm workloads start just in time inside an attested trusted execution environment, scoped authority and release rules stay outside the caller, and each permitted result includes Standard Proof.

    Your applications, services and agents keep their logic and orchestration where they are. They use Standard for the bounded operations that need enforceable permissions, protected execution, controlled release, and evidence another system can check.

    The single-organization case

    Start with one organization and one sensitive function. Example: a software-release workflow uses approved checks on a candidate artifact:

    • A coding agent produces a candidate artifact.
    • The release owner controls an approved Wasm workload that runs the required checks against that artifact.
    • Standard Proof binds the recorded execution and check outcomes to the candidate.
    • A release agent verifies the evidence and applies the release policy to that exact artifact.

    One organization can configure this workflow. The producing agent has no authority to replace the accepted test suite, evaluator, or release policy. If those change, the evidence must identify the change and the applicable authorization.

    Standard Proof establishes the recorded execution claims. It does not prove that the inputs were truthful, that the findings are correct, or that the next action is authorized.

    Independent participants in one Space

    A Space binds the participants, the agreed operation profile, input permissions, required approvals, permitted recipients, and verification expectations for an operation. It can serve one organization; add independent owners only when the function needs their assets or approval.

    • Each participant joins under its own identity and keeps control of its own assets.
    • Each required owner authorizes the use of its own contribution and the release of results. One owner’s approval cannot replace another’s.
    • Sponsoring, inviting or coordinating a Space does not create authority over another owner’s data or code.
    • A recipient receives only its permitted result and verifies Standard Proof against references it accepted itself.

    Example: a customer's maintenance agent asks a vendor to diagnose an issue. The customer contributes an encrypted telemetry window and the vendor contributes its approved diagnostic workload. Each owner authorizes its own contribution and release, and an assurance team verifies the findings with Standard Proof.

    What the runtime provides

    CapabilityPurpose
    Scoped authorityIdentify the caller and establish what it may request, use, or release.
    Policy enforcement
    NextHow Standard works

    On this page

    • The single-organization case
    • Independent participants in one Space
    • What the runtime provides
    • Choose the execution boundary
    • Execution to next action
    • Key terms
    • Continue building
    Apply the accepted rules during execution and before a result leaves.
    Attested runtimeExecute supported workloads within an environment whose identity can be checked.
    Confidential executionDecrypt protected inputs inside the runtime and release only permitted outputs.
    Standard ProofBind the relevant execution claims to a result so a recipient can verify the handoff.
    Managed lifecycleOperate workload activation, execution limits, result release, evidence, and cleanup, with completion and cleanup reported separately.

    Choose the execution boundary

    Standard runs the approved Wasm workload over authorized inputs inside the confidential runtime. Code, data, and model inputs must fit the workload's supported formats and execution limits. Protected artifacts remain encrypted in object storage until the runtime meets the access conditions.

    Existing external tools remain external. A supported interaction can record what Standard controlled or observed, such as an authorized request and response. That evidence does not attest the provider's internal computation. A tool provider does not need to move its backend into Standard simply because an agent uses its API or MCP interface.

    Select a supported operation whose evidence covers the claim your next step needs. See the integration reference.

    Execution to next action

    1. Configure authority. Define the participants, operation, resources, release rules, and accepted verification references. Each required owner authorizes its own part.
    2. Submit work. Provide the supported operation and input references. Protected contents stay out of ordinary tool arguments.
    3. Enforce the rules. Standard checks authority and applies the execution and release policy.
    4. Return result and proof. The permitted output is bound to execution evidence.
    5. Verify and continue. The receiving integration checks the evidence, then applies its own acceptance policy to the result.

    Standing permissions cover routine work within a narrowly accepted scope. A request outside those bounds is blocked until each required owner supplies valid authority.

    Key terms

    TermMeaning
    Operation or taskA defined unit of work requested through a supported Standard interface.
    ParticipantAn organization, agent, human or service that contributes inputs or authority, or receives a result. Each keeps its own identity.
    SpaceA governed context for participants, authority, an accepted profile, release rules and evidence. It can serve one organization or several independent owners. It is not a shared running computer.
    Operation profileA versioned, accepted contract for a class of work: its workload, roles, inputs, limits, authority, and result and release rules. It grants no access by itself.
    Standing permissionsAn owner’s bounded, signed permission for routine operations. A new scope needs fresh authority.
    Operation requestThe concrete profile reference, workload and input references, parameters, and requested result for one proposed operation.
    Encrypted-input referenceA reference to an encrypted object and its expected digest. Access to the reference does not grant decryption rights.
    Standard ProofExecution evidence binding the relevant runtime, workload, authority, inputs, and result claims within the recorded execution boundary.

    Continue building

    • Run your first task
    • Inputs and permissions
    • Results and lifecycle
    • Security model