Check the workload
Appraise the software evidence against your accepted measurements, signer and security policy, and bind it to the protected session.
Applications & solutions
Put the trust boundary
where it belongs.
Use Canopy’s development and confidential-computing components to build around the information, operations and software your deployment needs to protect.
Zero-trust networks & applications
Make access depend on evidence and authority.
Being on the network should not be sufficient to trust a caller or a workload. Canopy can support a zero-trust architecture by combining protected sessions and workload evidence with application-defined identity, permissions and release policy.
Limit the authority
Validate the caller’s identity and expose only the operations and data it is permitted to use. Keep these decisions in the application’s policy.
Canopy supplies components for this architecture. Identity issuance, authorisation, session lifecycle and operational enforcement must be composed and tested for the deployment.
This follows the resource-focused principle of NIST’s zero-trust architecture: network location alone does not confer trust.
Application policy
Control which operations a caller can use.
Generated service contracts expose named interfaces and methods. Applications can build gateways that bind a validated principal to a narrow set of capabilities and enforce resource-specific authority.
Cerberus demonstrates application-owned authorisation and bounded advisory interfaces. A customer gateway must define its own identity source, permissions, audit policy and protected execution boundary.
Controlled disclosure
Share the information needed for the purpose.
A partner may need an assessed track without every raw observation. Define the recipient, permitted event types and release policy before deciding what crosses the boundary.
Cerberus has event filtering, duplicate handling and bounded replay with supporting in-process tests. Its track-only sharing profile is illustrative; general field redaction and a complete protected regional exchange need separate implementation and evidence. Repeated observations may still reveal information indirectly.
Read the controlled-disclosure briefing (PDF) →AI authority
Define what an adviser is permitted to do.
Publish a bounded, read-only tool surface and validate its outputs. Keep operations such as authorisation and tasking outside that advisory interface.
Cerberus separates its adviser from an explicitly authorised synthetic controller that can act on validated model outputs. The external model is outside the attested application boundary. Hardware evidence can identify the controls being run; it does not certify every answer as correct or safe.
Read the AI authority briefing (PDF) →Confidential joint processing · Deployment architecture
A shared answer. Private inputs.
Some questions can only be answered by combining information that organisations cannot disclose to one another. Canopy can be used to build a confidential “dark pool” for that computation: participants contribute secrets to agreed code in a protected environment and receive only the approved result.
Participant APrivate input A
Participant BPrivate input B
Protected contributions ↓
Agreed computationAttested enclave · defined input and output policy
Approved release ↓
The shared answerEach participant receives the permitted result, not the other’s raw input.
For example, two organisations could check whether their private records overlap and release only an agreed aggregate. Neither needs to publish its records or give the other direct access to them.
Each party verifies the workload and release policy before contributing. The protected code processes the inputs internally; hardware isolation is used to protect them from the host within the supported platform’s threat model.
The answer itself can reveal information. Output rules, repeated-query limits and inference risks need assessment. This is an application design enabled by the components, not a claim of a ready-made, inference-proof service or a cryptographic multi-party-computation protocol.
Proposed application
Release valuable assets to an approved workload.
Model or content owners may require accepted workload evidence before releasing a decryption key. The application must define what the protected code may reveal and how keys, updates and recipients are managed.
Hardware isolation can reduce trust in the host within the supported platform’s threat model. It does not provide an unconditional guarantee against extraction or misuse, and a deployment must be tested against its intended threats.
Proposed integration
Make software evidence a condition of admission.
Attestation-gated issuance would require a verifier’s accepted evidence before an issuer grants a workload credential. It can fit alongside an existing network and message broker, with agreed identity and session policies.
Explore the proposed issuer path →