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
| Scope | What it establishes |
|---|---|
| Caller | Which identity may request the operation. |
| Workload | Which approved code, model, or supported operation may run. |
| Resources | Which inputs and capabilities the execution may use. |
| Release | What 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.