End-to-end encryption: scope, guarantees, and limits
Explains which Duale AI exchanges end-to-end encryption protects, what it guarantees, what it relies on, and what remains visible to a network observer.
This page covers which exchanges end-to-end encryption protects, its guarantees, trust dependencies, visible metadata, and what falls outside its scope.
- Protected exchanges between SDK, Dashboard, and Duale AI.
- Where encryption starts and ends in the request flow.
- Guarantees including authentication, replay refusal, and secret handling.
- Trust dependencies on HTTPS, key fetching, and forward secrecy.
- Visible metadata and traffic outside this protection.
Summaries were generated by AI.
Duale AI adds end-to-end encryption to protected Tenant operations, on top of HTTPS. Your SDK process or browser encrypts each request before it crosses the network, and Duale AI encrypts each response. This page shows which exchanges the encryption protects, what it guarantees, what it relies on, and what stays visible, so you can assess it for your integration.
Which exchanges are protected
| Client and exchange | Protected between |
|---|---|
| Python SDK Task submissions, Task responses, live Task events, Tool Results, Stop requests, and Agent Identity Tool registration and heartbeats | Your SDK process and Duale AI |
| Python SDK Library management and document requests | Your SDK process and Duale AI |
| Dashboard Tenant operations, including identity and access administration | Your browser and Duale AI |
- Client and exchange
- Python SDK Task submissions, Task responses, live Task events, Tool Results, Stop requests, and Agent Identity Tool registration and heartbeats
- Protected between
- Your SDK process and Duale AI
- Client and exchange
- Python SDK Library management and document requests
- Protected between
- Your SDK process and Duale AI
- Client and exchange
- Dashboard Tenant operations, including identity and access administration
- Protected between
- Your browser and Duale AI
The protected Library requests include creating an upload session and recording a completed document. The file parts themselves go to time-limited signed HTTPS upload URLs, outside this protection.
Where protection starts and ends
Your client first exchanges its credential for a short-lived platform token over HTTPS. Both sides then derive the same secret from that exchange, and your client uses it to encrypt each protected request. Duale AI decrypts the request, then checks the permission of the caller for the requested Tenant and resource. Decrypting a request does not authorize it.
What the protection guarantees
- The method, address, headers, and body of each request are encrypted and authenticated. So are the status, headers, and body of each response.
- Your client accepts a complete response only after it authenticates the whole response.
- The SDK authenticates each live Task event before it delivers the event to your code, so you receive checked events as they arrive.
- Duale AI normally refuses a replayed encrypted request. While the store that remembers recent requests is unavailable or short of memory, a replayed request can pass. Treat this refusal as a safety net, not as idempotency for your business operation. If a request that changes state loses its response, check the result of the operation before you send a new request.
- The derived secret never crosses the network. The issuance request and response carry only public values.
What it relies on
- Issuance trusts HTTPS. A party that can terminate HTTPS between your client and Duale AI can substitute the public values of the exchange and derive the secret for later protected requests. The SDK does not authenticate issuance independently of HTTPS.
- The public key of Duale AI is fetched at run time. Your client fetches it over HTTPS, and the SDK does not pin it. A party that controls that HTTPS response can change which key your client trusts. A key change therefore needs no SDK release.
- Issuance has no forward secrecy. A party that records an issuance exchange and later obtains the issuing key of Duale AI can derive the secret of that platform token.
- The Dashboard code arrives over HTTPS. A party that can change that traffic controls the code that performs the encryption. The SDK runs code that you installed.
What stays visible
| Visible to a network observer | Encrypted |
|---|---|
| That a client contacts Duale AI, the endpoint, message sizes and timing, a key identifier, a random session identifier tied to one platform token, and outer transport errors | The address, request and response headers, body, authenticated status, and Task event content |
- Visible to a network observer
- That a client contacts Duale AI, the endpoint, message sizes and timing, a key identifier, a random session identifier tied to one platform token, and outer transport errors
- Encrypted
- The address, request and response headers, body, authenticated status, and Task event content
An observer can link the exchanges that carry one session identifier, across Task and Library requests, for as long as that platform token lives. Each new platform token has a new random identifier, so the link ends there. Encryption does not hide that a client contacts Duale AI, the amount or timing of traffic, or an outer failure. This is not a zero-knowledge service: Duale AI decrypts your data to process it, and later authorized processing can send data to the destinations you configure.
What stays outside this protection
Platform-token issuance, file parts sent to signed upload URLs, SDK telemetry export, and traffic from Duale AI to model providers, websites, and Tools use other protection. Data protection maps those paths and the separate protection for stored data.
For the supported client workflow, start with Install the SDK or Manage a Library. For Library storage, access, and deletion, read Security and data handling.