Security model
What confidentiality, enforcement and verification protect, who must be trusted and what the guarantees do not cover.
Standard combines execution integrity, scoped authority, and confidentiality for managed confidential execution. This page defines the protection boundaries and the assumptions behind Standard Proof.
Execution integrity
Runtime attestation identifies the accepted execution environment. Execution evidence binds the relevant workload, authority, inputs, and result within that environment. A recipient verifies those bindings against references it accepts independently of the producing agent.
Signed evidence is tamper-evident: changing signed contents must invalidate their verification. The strength of a claim depends on the evidence source, its binding to the result, and the accepted trust roots. A signature on an untrusted statement alone does not establish that the statement is true.
For agent-written code, the verifier, tests, and acceptance policy must remain outside the producing agent's authority. An attested run of weakened tests is still a run of weakened tests. Check the accepted versions as well as the result.
Scoped authority and release
Standard enforces the applicable operation, resource, and release rules. Permission to execute does not automatically authorize additional disclosure or a downstream action. Standing permissions allow routine autonomous work; missing authority blocks the request or release.
A Space can contain agents and resources within one organization or across independent owners. Each resource's policy still applies.
Confidentiality
- Protected inputs are encrypted before they are contributed and are uploaded for the accepted protected runtime.
- Decryption occurs inside the confidential runtime after the required access and attestation conditions are met.
- Hardware-based isolation is designed to keep plaintext inputs and working state from Standard's operators and the hosting infrastructure.
- Agents receive permitted outputs and the references they are authorized to use.
- Protected results are encrypted for their intended recipients, who decrypt them with keys they hold.
The approved workload processes plaintext inside the protected environment. Workload selection and output policy therefore remain part of the security model.
Questions customers ask
Who speaks for each owner? An accepted, Standard-issued identity anchored to the participant's own signing keys, acting under bounded delegation. 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.
Where is plaintext? At the owner’s source and preparation endpoints; inside the accepted confidential execution environment, including its host, approved workload and release gate as needed for processing; and at authorized recipient endpoints after permitted outputs are decrypted. Protected input contents stay out of routine coordination, agent prompts and operator-visible logs. Operational metadata remains outside this protected-input confidentiality claim.