Standard

Managed confidential execution

Run your agents’ sensitive functions inside a confidential runtime

Let agents request approved functions on private data. Standard runs those functions in hardware-backed confidential environments, enforces independent permissions, and delivers permitted results with execution evidence your systems can verify.

Request accessSee how it works

For AI agents, applications and automated workflows.

Built for the agent era

Agents request the work. Owners control what runs and what leaves.

Agents are taking on work that involves private data, proprietary code and consequential results. Owners need to control which functions may run, which inputs they may use, and which results may reach each recipient.

Standard enforces those permissions outside the requesting agent. Each permitted result includes execution evidence the receiving system can verify.

Your agents stay in their existing environments. Approved functions run in Standard.

Built for protected executionConfidential computing, without managing the infrastructure

  • Just-in-time execution

    Run approved functions on demand, with managed activation, resource limits, and cleanup.

  • Hardware-backed isolation

    Protect sensitive computation inside an attested confidential environment, with bounded WebAssembly execution.

  • Independent authority

    Enforce who can execute a function, which assets it may use, and what results may leave. The requester cannot grant itself another owner’s permissions.

  • Standard Proof

    Bind the recorded workload, authority, inputs, execution environment, and permitted result into cryptographic evidence.

Developer infrastructure

Give your agents approved functions to call

Publish a supported WebAssembly function and define its inputs, limits and permitted outputs. Each required owner authorizes its use. Your agent or application requests the operation, and the permitted recipient verifies the result’s execution evidence.

  1. 01 · Deploy

    Publish the function with its operation profile: inputs, limits, roles and the permitted result.

    standard deploy ./release-checks.wasm \
  --profile profile.json
→ profile release-checks@4 published

  2. 02 · Authorize

    Each required owner approves in the Console with a passkey, per operation or under a standing permission with a use count and expiry.

    Console · passkey approval

  3. 03 · Run

    Request the operation. Inputs are encrypted on your host and contributed only after the runtime passes appraisal.

    standard run release-checks \
  --input candidate=./service-api-2.14.0.tar.gz
→ operation 7f3c… running

  4. 04 · Receive and verify

    The permitted recipient receives the result. The CLI verifies Standard Proof before it writes anything.

    standard receive 7f3c… --out ./out
→ Standard Proof verified
→ report written to ./out/report.json

Same operations from every interface

  • MCP — Connect your existing agentLet your agent discover and request approved functions. Every request remains subject to current owner permissions, including bounded standing permissions for routine work.
    {
  "mcpServers": {
    "standard": {
      "type": "http",
      "url": "https://standardruntime.com/api/mcp"
    }
  }
}
    Client configuration keys vary; use your client’s remote Streamable HTTP configuration.
  • API and SDK — Call from your applicationRequest the same operations from applications, backend services and CI/CD. The SDK verifies Standard Proof in the recipient’s environment before returning a result.
    import { Standard } from '@standardruntime/sdk';

const standard = new Standard();
const operation = await standard.run('release-checks', {
  inputs: { candidate: './service-api-2.14.0.tar.gz' },
});
const { report, proof } = await operation.receive();
  • ConsoleSee every operation, attempt and release. Execution, delivery, evidence and cleanup are separate states, so a result that is still awaiting release never reads as delivered.
    Examplerelease-checks · operation 7f3c… · attempt 2
    Execution
    Executed
    Delivery
    Awaiting release
    Evidence
    Available
    Cleanup
    Pending

    Attempt timeline

    1. AdmittedRelease owner approval recorded
    2. ExecutingAttested runtime · measured image
    3. ExecutedReport sealed · sha256:9f2c…07b3
    4. Awaiting releaseOutput contract report → release agent

    Last observation Erasure is not verified. External copies are excluded and have not been recalled.

    • Every state change, per attemptAdmitted, executing, executed, awaiting release, released, withheld, failed or cancelled. Each attempt keeps its own timeline.
    • Evidence per operationStandard Proof is listed beside the operation that produced it. Verification stays in the CLI and SDK, in your environment.
    • Usage and limits per SpaceOperations, execution time and permitted outputs against the Space’s limits, on the Billing view.
    • Failures you can locateA refusal keeps its correlation ID, stage and error class, so you can find the boundary that failed without a log dump.
    • The same facts from the terminalCheck an operation, an attempt or your connection from the CLI and from the API without opening the Console.
Run your first taskSee pricing

The execution lifecycle

Define. Authorize. Execute. Release. Verify.

Explore the operation lifecycle
MANAGED CONFIDENTIAL RUNTIME

One operation through the runtime

Five stages, one operation

  1. DefineRegister an approved WebAssembly function, its accepted inputs, capabilities, and execution limits.
  2. AuthorizeThe requesting agent asks for the operation. Each required owner controls use of its assets, approved execution, and permitted release; a grant names the exact connected source, the operation and the recipient.
  3. ExecuteStandard runs the accepted function inside an attested confidential environment. Protected inputs reach it directly from the owner’s connected sources under the grant; nothing passes through the agent or Standard’s coordination services.
  4. ReleaseOnly the permitted result reaches its authorized recipient. Successful computation alone does not authorize disclosure.
  5. VerifyThe receiving system checks Standard Proof against its independently accepted references before relying on the result.

Cryptographic execution evidence

Don’t just receive a result. Verify the execution.

Verification reference

Standard Proof binds the accepted workload, relevant input commitments, recorded owner authority, execution environment, and released result.

Receiving systems can verify supported execution claims independently of the requesting application or agent.

Verify the evidence. Evaluate the result. Apply your own next-action policy.

Proof does not establish that source data was truthful, that a function was logically correct, or that the next action is authorized.

Select a scenario, or alter a signed field below.

Example · Software release verification

Standard Proof

What ran
Release verification
Who authorized
Release owner
What was permitted
Validation report to release agent
Recipient checks
Available for verification
runtimeattested runtime · measured image
signedstd-runtime-key-07 · 18:23Z
workload outcomeapproved tests passed
Signed by the runtime. The release owner’s authority, approved workload, exact candidate, and released report are bound together.
Verify evidence → evaluate the result → check next-action authority
Release agent · recipientVerifies the proof itself, then applies its own deployment policy
  • Evidence accepted against the recipient’s references
  • Workload outcome: approved checks passed
  • Next-action policy: deployment permitted
DecisionDeployment permitted by recipient policyThe report is delivered and verified. In this example, the recipient’s own deployment policy also permits the next action.

Bring your agent’s first sensitive function to Standard

Begin with one function, one private source and a defined result. Work with us to establish the supported workload, owner permissions and recipient verification.

Request accessSee how it works