# Standard

> 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 agents keep their planning and orchestration. They call Standard for bounded, sensitive functions that need protected inputs, independently controlled policy, or verifiable execution. Standard does not host complete agents or accept arbitrary workloads. Membership in a Space does not grant access to another participant’s private inputs or permission to run every operation; sponsoring a Space does not grant authority over another owner’s assets.

## Availability

Space access is by request: request access for your organization and describe the work you want to run. Connecting an agent does not grant execution access or authority over another owner’s resources.

Next step: https://standardruntime.com/contact?intent=space-access

## Documentation

These pages are the source for this guide. Read them for detail.

- [Overview](https://standardruntime.com/docs/overview): Start with one sensitive function: what Standard manages, what owners control, and how a recipient verifies the permitted result.
- [How Standard works](https://standardruntime.com/docs/how-it-works): The architecture, the operation lifecycle, operation profiles and Spaces, the security layers, and what Standard Proof establishes, with interactive examples.
- [Run your first task](https://standardruntime.com/docs/first-task): Start with one organization and an approved Wasm function, set authority and release rules, and verify the permitted result.
- [Connect](https://standardruntime.com/docs/first-task/connect): Sign in from the CLI, authorize the SDK from your code, or connect an agent through MCP; every entry point reaches the same account and operations.
- [Join a Space](https://standardruntime.com/docs/join-a-space): Review the proposed work, authorize your contribution, and choose what may be released, without joining another organization’s account.
- [Examples](https://standardruntime.com/docs/examples): Five example operation profiles with their definition and configuration files: software release integrity, vendor diagnostics, supplier assessment, model evaluation and joint analytics.
- [Operation profiles](https://standardruntime.com/docs/execution-packages): Define the program, participant roles, inputs, permitted outputs, and execution limits.
- [Inputs and permissions](https://standardruntime.com/docs/inputs-and-permissions): How encrypted inputs and key access work, how each required owner authorizes independently, and how standing permissions cover routine decisions.
- [Accounts, Spaces and billing](https://standardruntime.com/docs/inputs-and-permissions/accounts-spaces-billing): How accounts, Spaces and invitations relate to permissions, and why connecting or paying never grants rights over another owner's inputs.
- [Results and lifecycle](https://standardruntime.com/docs/results-and-lifecycle): Automatic verification and result delivery, approval requests, failures, retries and cleanup status.
- [Verification checks](https://standardruntime.com/docs/results-and-lifecycle/verification-checks): The evidence reference: each check the receiving client runs automatically, the references it uses and where it runs, for integrators and auditors.
- [Follow-on tasks](https://standardruntime.com/docs/results-and-lifecycle/follow-on-tasks): Use one task's verified result as the input to another, with evidence linking the two.
- [Cleanup](https://standardruntime.com/docs/results-and-lifecycle/cleanup): What Standard removes after a task, what it keeps, and when cleanup counts as complete.
- [Integration reference](https://standardruntime.com/docs/integration-reference): Reference for Standard’s Control transaction, CLI, MCP transport, application bindings, participant custody, and execution evidence.
- [Security model](https://standardruntime.com/docs/security-model): What confidentiality, enforcement and verification protect, who must be trusted and what the guarantees do not cover.

## Connect, execute, verify

1. Connect an authorized identity through the CLI, the SDK, or MCP. OAuth authorizes a connection, not a payment or unrestricted resource access.
2. Discover the actual tasks and schemas available to the authenticated account. Follow them; do not invent tool names, task fields, formats, or capabilities.
3. Define the permitted operation, resources, result recipients, and accepted verification references. Each required owner authorizes its own contribution and release; one owner’s approval cannot replace another’s. Standing permissions define reusable authority within a narrow accepted scope. Each operation must still satisfy its required admission and release approvals.
4. For protected workloads, encrypt inputs before contributing them for the accepted protected runtime, and configure key access for that runtime. Submit an operation request under the accepted profile with input references, never private contents in ordinary tool arguments.
5. Follow the operation’s status and idempotency contract. A submitted request, a lost response, or a running process does not establish completion.
6. Verify Standard Proof in the recipient’s trusted integration against accepted references. Missing or failed required checks block acceptance. Evaluate the result and authority for the next action separately.

## Example: code verification to release

A coding agent submits a candidate artifact. The release owner controls an approved Wasm verification workload, test suite, and acceptance policy. The producing agent cannot replace those checks under its own authority. Standard Proof binds the recorded verifier execution and outcomes to the exact candidate.

The release agent verifies the evidence, evaluates the findings against its release policy, and enforces authority for release. Valid proof can report failed tests or security findings. Only the exact tested artifact may proceed when the required conditions pass. A new artifact needs its own evidence.

## Multi-owner expansion: vendor diagnostics

A customer’s maintenance agent asks a vendor to diagnose an equipment issue. The customer contributes an encrypted telemetry window; the vendor contributes its proprietary diagnostic program. Each owner authorizes its own contribution and the release of results. An assurance team receives only the permitted findings and verifies Standard Proof before acting. Neither owner receives the other’s raw input.

Private inputs never travel through MCP. Do not put raw private files, private keys or secret material into MCP arguments or ordinary model context. Previously disclosed information cannot be made private retroactively.

## Product and connection

- [Homepage](https://standardruntime.com/): managed confidential execution for sensitive functions.
- [Examples](https://standardruntime.com/docs/examples): five example operation profiles with their definition and configuration files.
- [How Standard works](https://standardruntime.com/docs/how-it-works): approved Wasm workloads, scoped authority, confidential execution, controlled release, and Standard Proof.
- [Security](https://standardruntime.com/docs/how-it-works#trust): who authorizes, where plaintext is, what can leave, and what is not covered.
- [What you can verify](https://standardruntime.com/docs/how-it-works#verification): what execution evidence establishes, and what it does not.
- [Connection guide](https://standardruntime.com/connect): sign in from the CLI, authorize the SDK, or connect an agent through MCP.
- Remote MCP endpoint: https://standardruntime.com/api/mcp (Streamable HTTP; authenticated account access required).
- [FAQ](https://standardruntime.com/faq): when to use Standard, how it protects work, and how to get started.
- [About](https://standardruntime.com/about): the purpose, founder, and principles behind Standard.
- [Pricing](https://standardruntime.com/pricing): pricing is quoted per organization. The sponsoring organization pays for execution; invited contributors don’t need a separate paid plan to participate, but still sign in and authorize how their own inputs are used.

## Broader ambition

Verifiable autonomy is the broader ambition described on About, not a claim that Standard verifies every agent decision. The product’s scope is managed confidential execution of approved, sensitive agent functions. Evidence of an execution does not establish that an agent’s overall plan or subsequent actions are correct.

## Runtime, Space, task

Standard manages an attested runtime for supported operations, including workload activation, execution limits, result release, evidence, and cleanup. A Space binds participants, an agreed operation profile, each required owner’s authority, release rules, and verification expectations for one or more tasks. It can serve a single organization’s agents or several independent owners. Joining it does not grant unrestricted rights over other participants’ inputs.

## Application and runtime responsibilities

Existing agents retain their planning and orchestration. Standard is not a workflow builder, composer, or general agent framework. It provides supported execution with enforced policy and verifiable evidence.

For confidential work, protected data, code, and models are encrypted before they are contributed and are decrypted inside the accepted runtime for the authorized operation. Recipients decrypt permitted results with keys they hold. The protected path is designed to keep plaintext inputs from requesting agents and Standard’s operators. Only permitted results leave.

An external API or MCP provider remains external. A supported interaction can record the request and response Standard controlled or observed. It does not attest the provider’s internal computation. Using a tool does not by itself require its provider to join Standard or move its backend into the runtime.

## Permissions and approvals

Every input has an owner who decides which tasks may use it and which results may be released, and to whom. Permission to analyze is not permission to disclose. Routine tasks run under standing permissions; approval is requested only when an owner’s policy reserves the decision. An agent cannot grant itself broader authority. Joining a Space, accepting an invitation, contributing an input, and paying for usage are distinct from authorizing use of another owner’s input; none of them grants rights over another owner’s assets.

## Verification and follow-on tasks

Verification is built into the integration: verification software, not a language-model judgment, checks environment, workload, inputs, authorization, and result binding against references the recipient accepted independently. Missing or failed required checks withhold the result; unchecked claims are reported as not checked. A passed check is not authorization to perform the next action: the receiving application or action service enforces its own action policy.

A verified result can feed a later task. The later task binds its actual input to the earlier permitted output or a verified transformation; listing earlier task identifiers is insufficient. Each task keeps its own permissions, and any step outside Standard remains an unverified step. Approval does not repair invalid evidence. These are integration principles, not additional MCP tool names; discover and obey the actual task contract.

## When to invoke Standard

Use Standard when an agent needs a bounded function with confidential inputs, policy outside the requesting agent, controlled result release, or independently verifiable execution evidence. Examples include checking agent-written code, gating release on a security report, analyzing private data, and passing results between agents. Select a supported operation whose evidence covers the claim the next step requires.

Protected execution matters when the workload must process protected inputs inside the attested boundary. An ordinary external tool interaction does not move the provider’s backend into Standard.

## Inputs and execution limits

Executable workloads are approved Wasm modules. Their code, model, and data inputs must match supported formats and fit the runtime’s resource limits. Standard is not a host for arbitrary models, containers, or GPU workloads, and an external model API is a separate recipient outside the protected task.

Tasks run in bounded execution windows rather than as continuously hosted services. Check supported duration, memory and input/output limits before requesting work; requests over a limit are rejected before they run. A reusable Space does not imply an indefinitely running worker, arbitrary multi-hour execution or resumable private working state.

## Fail closed and report limits

Report unsupported tasks, missing permissions, pending approvals, quota limits, failed or unchecked evidence and pending cleanup explicitly. Do not silently fall back to ordinary chat or unprotected processing. Treat result release, downstream acceptance, and cleanup as separate outcomes. Evidence of execution does not prove truthful inputs, sufficient tests, correct AI answers, compliance certification, physical events or universal physical erasure. Outputs can reveal information about private inputs; release rules and repeated-query limits must fit the task.