docs: note the privacy boundary of remote / delegated proving

docs/builder/faq.md

@@ -21,6 +21,8 @@ Miden's architecture separates concerns between:
 3. **Proving efficiency**:
 Delegated provers can use optimized hardware that wouldn't be available to end-user devices, specifically designed for the mathematical operations needed in STARK proof generation.
 
+That convenience has a privacy cost: a delegated / remote prover must receive the transaction witness (serialized transaction inputs), so it can see private account and note data that local proving would keep on the client. Choose delegated proving when you trust the prover operator; keep proving local when those inputs must stay private.
+
 ## What is the lifecycle of a transaction?
 
 ### 1. Transaction Creation

docs/builder/tools/clients/web-client/setup.md

@@ -118,6 +118,11 @@ See [Accounts](./accounts.md) for full examples covering wallets, contracts, and
 
 Local proving in the browser is CPU-intensive for larger transactions. Override globally via `ClientOptions.proverUrl`, or per transaction via the `prover` field:
 
+:::caution Privacy boundary
+A remote / delegated prover receives the transaction **witness** (the serialized transaction inputs), not only a digest. That payload can include account state, input notes, advice data, and other private execution context needed to build the proof. Prefer local proving (`proverUrl: "local"`) when those inputs must stay on-device; use a remote prover only when you trust that operator with the witness.
+:::
+
+
 ```typescript
 // Globally: every transaction uses the remote prover by default
 const client = await MidenClient.create({

docs/builder/tools/clients/web-client/transactions.md

@@ -316,6 +316,11 @@ await client.transactions.submit(wallet, request);
 
 Local proving is CPU-intensive. Offload globally via `ClientOptions.proverUrl`, or per-transaction via the `prover` field:
 
+:::caution Privacy boundary
+Remote proving sends witness data (serialized transaction inputs) to the prover endpoint. Treat the prover operator as trusted for those private inputs. Keep proving local when you need the witness to remain on the client.
+:::
+
+
 ```typescript
 // Global: every transaction uses the remote prover
 const client = await MidenClient.create({

docs/builder/tools/network.md

@@ -38,6 +38,10 @@ The same services exist on devnet under the `devnet` subdomain — e.g., `status
   </Card>
 </CardGrid>
 
+<Callout variant="caution" title="Privacy boundary">
+Delegated proving is a trust trade-off: the remote prover learns the transaction witness (account / note / advice inputs used to generate the proof). Use it for convenience on low-power clients; keep proving local when witness privacy matters.
+</Callout>
+
 <Callout variant="tip" title="Canonical URLs live on the status page">
 Hard-coding testnet URLs in client configs is fine for demos, but the Miden ops team moves endpoints as new nodes come online. For anything production-ish, keep your configuration loading the current URLs from [status.testnet.miden.io](https://status.testnet.miden.io/) or the client's default (which tracks the canonical testnet host).
 </Callout>