FAQ
Managed confidential execution, clearly explained
What Standard runs, how it differs from a sandbox, what the managed service protects, and what Standard Proof establishes.
Standard is a managed confidential execution service. It starts approved Wasm workloads just in time inside an attested trusted execution environment (TEE), enforces authority and release rules outside the caller, and returns permitted results with Standard Proof.
A typical sandbox is designed to contain a process and protect surrounding infrastructure. Standard is designed for sensitive agent functions: a managed hardware-backed confidential runtime, approved Wasm workloads and resource limits, scoped authority outside the agent, controlled result release, and Standard Proof.
Yes. Standard manages admission, attestation, workload activation, the confidential runtime lifecycle, resource enforcement, result release, Standard Proof, and cleanup. You provide the agent integration, accepted workload, protected inputs, and policy.
No. Your agents keep running in their existing environments. They call Standard through MCP, the SDK, or the CLI for the bounded functions that need confidential execution, controlled release, or verifiable evidence.
Approved Wasm workloads that fit the supported memory, fuel, duration, input, output, and import limits. Examples include private data analysis, artifact validation, and model scoring with compatible inputs. The workload must implement its checks within those limits; Standard does not run arbitrary repository test suites or host a full agent.
Contributed protected inputs are encrypted in storage and decrypted inside the accepted confidential runtime for an authorized operation. Owners prepare inputs in their own environments; the design keeps plaintext out of requesting-agent context, coordination services, and operator-visible logs. Only permitted results are released.
It lets a recipient verify the recorded workload, relevant inputs and permissions, accepted runtime, and result and release evidence against independently accepted references. It does not prove the answer is true or automatically authorize another action.
No. The receiving integration automatically checks Standard Proof against its accepted trust references and the expected operation before accepting the result. Missing or failed required evidence checks block acceptance. Your application separately evaluates the findings and decides whether the next action is authorized.
A Space brings together the participants, permitted operations, contributions, and release rules for a workflow. Membership does not by itself grant access to private inputs or permission to run every operation.
A versioned, accepted contract for a class of work: its workload, roles, inputs, limits, required authority, and result and release rules. The profile describes the work; owner permissions determine whether it may use particular assets.
No. Start with one organization and one sensitive function, such as a private data analysis or verified agent handoff. The same Space model can add independent owners when a function needs their assets or approval.
No. Paying, inviting, authenticating or coordinating does not create authority over another owner’s protected assets. Each required owner must supply accepted authorization for the permitted use and release.
No. Participants retain control of their own credentials and protected assets, and each signs with keys it holds. The accepted execution can process only what they authorize, and private material is not exposed as general agent context.
Not necessarily. Owners can permit routine operations through bounded standing permissions. A new scope, restricted release, or other policy condition may require additional authorization. Requests outside the granted authority are blocked.
Yes. The operation profile defines each permitted output and who may receive it. In vendor diagnostics, the customer receives detailed findings while the vendor receives a narrower service summary. Each release still needs the applicable owners’ permission, and no recipient receives more than its output allows.
The result is not released to that recipient under that request. Successful computation never overrides a missing required release permission.
No. Connecting an agent does not give Standard access to your files, credentials, or other private data. Protected inputs must be prepared and authorized separately, and private inputs do not travel through MCP.
The verification workflow must pin its test suite, evaluator, and acceptance policy outside the producing agent’s authority. Evidence binds the reported outcome to those exact checks and the tested artifact. Changing the checks cannot silently count as passing the previously accepted checks.
Calling an existing external API does not, by itself, require its provider to join Standard. A vendor that contributes protected code or authorizes its use participates as an independent owner in the operation. Calling a provider’s API, or having that provider participate, does not bring its external backend inside Standard’s attested execution boundary.
Use protected execution when a workload must process private inputs or when the recipient needs evidence about the exact workload and runtime. The attested hardware-backed TEE protects the operation from ordinary host and operator access under the documented trust model.
It establishes the claims covered by the execution evidence under the accepted trust model. It does not by itself prove truthful inputs, sufficient tests, or a correct model answer. The next step must verify the evidence and apply its own acceptance rules to the result.
Sign in with your own account and accept the invitation. You keep your own credentials and signing keys, and you authorize only your own contribution and the results that depend on it. The sponsoring organization pays for the execution it sponsors; you don’t need your own paid plan to participate.
Request access for one bounded agent function. Describe its workload, protected inputs, limits, permitted result, and recipient. Contact Standard for a usage-based proposal.