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

    Inputs and permissions

    How encrypted inputs and key access work, how each required owner authorizes independently, and how standing permissions cover routine decisions.

    Agents need authority for the resources they use and the results they release. Standard binds those permissions to execution, whether the resources belong to one organization or several owners.

    Each required owner authorizes independently. One owner’s approval cannot replace another’s, and a sponsor or coordinator cannot approve on an owner’s behalf. Owners sign their authorizations with keys they hold.

    In the release example, the candidate artifact, verifier, test suite, and release policy have distinct roles. The coding agent can submit a candidate without gaining authority to change the accepted checks.

    Encrypted storage

    Protected inputs are encrypted before they are contributed and are uploaded for the accepted protected runtime. Standard's confidential runtime decrypts them only when the access conditions are met. Private contents stay out of agent conversations and ordinary tool arguments.

    An encrypted-input reference identifies an object and its expected digest. Holding the reference does not grant permission to decrypt or use it. References can still contain sensitive metadata and should follow your disclosure policy.

    Key access and attestation

    The key-access policy determines which attested runtime and authorized execution may obtain decryption material. Required checks include the accepted runtime identity, workload, and applicable authority. If the required conditions are not met, the protected execution cannot use the input.

    The key is used inside the protected environment. The requesting agent and Standard's operators do not receive it through the normal protected-input path.

    Code, models, and validation inputs

    Code and model artifacts can be protected inputs as well as data. They must match the runtime's supported formats and resource limits.

    For independent validation, pin the verifier and its inputs under authority separate from the producing agent. Hardware attestation alone does not make a test suite trustworthy. The accepted policy must identify which checks are required, and evidence must bind the outcome to those checks and the candidate artifact.

    See Formats and limits.

    Permission scope

    ScopeWhat it establishes
    CallerWhich identity may request the operation.
    WorkloadWhich approved code, model, or supported operation may run.
    ResourcesWhich inputs and capabilities the execution may use.
    ReleaseWhat result may leave and which recipients may receive it.

    Permission to run a computation does not automatically authorize disclosure of its inputs. Membership in a Space does not grant access to every resource in that Space.

    PreviousIntegration referenceNextAccounts and billing

    On this page

    • Encrypted storage
    • Key access and attestation
    • Code, models, and validation inputs
    • Permission scope
    • Standing permissions
    • Independently owned resources
    • Related pages

    Standing permissions

    An owner can grant bounded standing permissions for routine operations, within a narrowly accepted scope, and let agents act within those bounds. A new scope needs fresh authority: a request to use a new verifier, expand resource access, or change the result recipient must satisfy each affected owner's policy before continuing.

    When a policy reserves an authorization decision, the required authority must be supplied. Missing authority blocks the operation or release; an agent cannot broaden its own permissions. Authorization cannot turn invalid evidence into valid evidence.

    Independently owned resources

    A workflow can add another owner's data, software, or model when needed. Each owner retains control over its contribution and permitted release, and the operation runs only when every required owner has authorized it. This is the same permission model used within one organization, with more required authorities.

    Related pages

    • Accounts, Spaces and billing
    • Security model