How Standard works
Where your function runs, and what governs it
Standard activates approved Wasm workloads just in time inside an attested trusted execution environment (TEE). It enforces scoped authority and release rules outside the caller, then returns the permitted result with Standard Proof.
Architecture
Where your function runs
Your agent, participant signing keys and external tools remain in their existing environments. Standard coordinates the operation and runs the approved Wasm workload inside the accepted confidential runtime. Protected inputs are encrypted before contribution; permitted outputs are delivered to their authorized recipients.
- Protected dataencrypted by the data owner before contribution
- Participant-held signing keyssign its own authorizations
- Its policies and trust referenceswhich profile may use its data, and what it receives
- Approved Wasm workloadencrypted by the code owner before contribution
- Participant-held signing keyssign its own authorizations
- Its policies and trust referenceswhich revision runs, and what it receives
- Caller identity and scoped authority
- Accepted workload and policy snapshots
- Scheduling, quotas, and lifecycle
- No ordinary plaintext protected inputs
Outside the TEE: checks each request against every required owner’s authority before anything runs.
- Assurance teamthe permitted findings, decrypted with keys it holds
- Customer and vendortheir own permitted outputs, such as findings or a service summary
- Agents and systemsdecide the next action under their own policy
Recipients can verify Standard Proof in their own environment against independently accepted references before using the permitted result.
External tools stay outside the attested boundary
Function requirements
What your function needs
- Approved Wasm
- Package the function as an approved WebAssembly module with a supported interface.
- Compatible inputs
- Prepare inputs in the module’s accepted format and contribute encrypted inputs from your environment.
- Declared limits
- Set memory, fuel, duration, input, output and import bounds. Confirm the fit before adapting your function.
- Permitted result
- Define the allowed output and recipient in advance; the computed values are produced during execution.
Owners configure the scope during setup. Standing permissions cover routine requests; Standard checks current authority for every operation.
Managed operation lifecycle
Set up the function. Verify each operation.
Establish the accepted function, participants and permissions during setup. Routine requests use that configuration, while Standard checks the current authority and exact inputs for each operation.
Initial setup
- Function and profile
- Select the supported Wasm workload, accepted revision, input format, limits and permitted outputs.
- Participants and authority
- Establish the required owners, caller and recipient identities, standing permissions and release rules.
- Contributions and verification
- Configure encrypted-input preparation, key access and the recipient’s independently accepted verification references.
Each operation
The coding agent requests the approved validation function for a specific candidate artifact. The release owner supplies authority separately; the request cannot replace the checks or expand their scope.
Temporary execution state is cleaned up according to the runtime lifecycle. Results, retained evidence and Space configuration have separate lifecycles.
Cleanup and retention →Approved functions
Define the work. Keep each owner in control.
An operation profile describes the accepted workload, input roles, limits, outputs and required authority. Each owner authorizes the use of its assets and the permitted release separately. Selecting a profile does not grant access.
- 1The profile declares roles, slots and outputs
- 2Each owner authorizes its own contribution
- 3Standard enforces the approved scope
Scoped authority
A Space defines who can run what and what may leave
Start with one organization. Add owners only when the function needs their assets or approval.
| Participant | Contributes | May authorize | Receives |
|---|---|---|---|
| Release owner | ContributesApproved checks and the candidate artifact | May authorizeThe checks, candidate scope and permitted report | ReceivesWhat the release rules permit |
| Release agent · recipient | ContributesNo private input | May authorizeIts own deployment decision | ReceivesValidation report + Standard Proof |
| Sponsor | ContributesPayment for the operation | May authorizeNothing over another owner’s assets | ReceivesUsage and billing records |
Being invited, signing in or paying does not, alone, authorize execution, asset use or result release.
Security and plaintext boundaries
Where protected inputs and permitted results can be seen
Protected inputs are encrypted before contribution and decrypted inside the accepted confidential runtime after the required access and attestation conditions are met. Authorized recipients decrypt their permitted results in their own environments.
| Location | Intended visibility |
|---|---|
| Data or code owner’s environment | Intended visibilityIts own source inputs, workload and keys, under that owner’s custody. |
| Requesting agent | Intended visibilityAuthorized references and permitted outputs. Protected source inputs need not enter the agent’s context. |
| Standard coordination services | Intended visibilityAccount, permission, status and usage metadata, together with protected-input references. Routine coordination is not a plaintext path for protected inputs. |
| Protected storage and transit paths | Intended visibilityEncrypted contributions and protected results, according to the supported contribution and delivery protocols. |
| Accepted confidential runtime | Intended visibilityPlaintext required by the trusted host, approved workload and release logic while processing. |
| Authorized recipient | Intended visibilityIts permitted output, decrypted with keys it holds in its own environment. |
What the service enforces
Confidentiality, authority, limits, and proof
- Caller identity and scoped authorityThe agent’s accepted identity and current permission to request the exact function, inputs, and result.
- Approved workload and limitsThe exact Wasm revision and its memory, fuel, time, input, output, and import bounds.
- Attested confidential runtimeHardware-backed protection for plaintext inputs while the approved workload runs, with managed startup and cleanup.
- Permitted result and Standard ProofRelease rules govern what reaches each recipient; signed evidence binds the operation the recipient can verify.
- Account access
- Permission to contribute
- Permission to execute
- Permission to release
Account access, permission to contribute, permission to execute and permission to release are separate checks. Passing one does not satisfy another.
Security boundary
The requesting agent does not control the sensitive function
Standard separates who requests an operation from who authorizes it, which protected inputs it may use, which workload and limits apply, what may be released, and what the recipient can verify.
Who speaks for each owner?
An accepted identity, acting under bounded delegation and signed authority. Delegations can be revoked, and authority must be current when it is used.
Who can approve an operation?
Each required owner, independently. Sponsoring a Space or inviting a participant does not transfer control of anyone’s assets.
What can leave?
Only permitted results may be released, and only to permitted recipients. Execution success alone is not release permission.
What can the next system verify?
Signed, checkable evidence for the exact operation, under trust roots it accepted. Verification does not confer new permissions.
What is not covered?
Correct answers, true inputs, complete secrecy of metadata, erasure of copies an authorized recipient keeps, the integrity of arbitrary external backends, and regulatory certification without certification evidence.
Independent parties still rely on accepted hardware, runtime, workload and policies, secure keys, correct verifiers and references, and their own endpoint custody, as the security model sets out.
Standard Proof
Verify the exact operation and permitted result
Standard Proof binds the recorded execution environment, accepted workload and profile, input commitments, applicable owner authority and released result. Your receiving integration verifies those bindings against references and policy it accepted independently before using the result.
- Expected profileaccepted profile revision
- Owner authorityeach required owner, for this workload and result
- Input bindingexpected input digests
- Accepted runtimeattested TEE measurement
- Result and releasepermitted result digest · intended recipient
- Evidence accepted
- Evaluate the findings against your policy
- Apply your next-action authorization
Valid evidence is not permission. Your own authorization still decides the next action.
| Check | Required relationship |
|---|---|
| Runtime | Required relationshipThe evidence-signing identity must be bound to the accepted runtime under the supported trust model, with applicable attestation freshness and revocation checks. |
| Workload and profile | Required relationshipThe recorded workload and profile revisions must match those accepted for the operation and be bound to the execution evidence. |
| Inputs | Required relationshipRecorded input commitments must match the expected artifacts or snapshots used by the operation. |
| Authority | Required relationshipRequired permissions must cover the applicable asset use, execution and release under the relevant validity rules. |
| Result and recipient | Required relationshipEvidence must bind the exact released result to its intended recipient and permitted release context. |
| Signature and references | Required relationshipSigned evidence must validate under references and policy established independently of the candidate result. |
Input bindings identify the artifacts or snapshots used. Source provenance is covered only when the operation includes evidence of the source. Execution evidence does not establish that source records are truthful or complete.
Verify the evidence, evaluate the result, and check authority for the next action. A valid proof does not grant permission for that next action.
Example · Single-organization release integrity
Verify an internal agent handoff
Your coding agent builds a candidate artifact. Compare its own report, signed evidence from a different approved profile, and evidence from the release owner’s accepted checks.
What verified it, and can I check that myself?
The release agent has no independently verifiable record of the required checks.