From ebb9688fc52d516726e928c6d07ad2ba898626d6 Mon Sep 17 00:00:00 2001
From: devin distefano <devin.distefano@smartcontract.com>
Date: Thu, 26 Mar 2026 15:08:06 -0500
Subject: [PATCH 1/4] tenant config docs

---
 src/content/cre/account/cli-login.mdx         |  4 +-
 src/content/cre/account/managing-auth.mdx     |  6 +-
 src/content/cre/llms-full-go.txt              | 58 +++++++++++++++----
 src/content/cre/llms-full-ts.txt              | 58 +++++++++++++++----
 .../cre/reference/cli/authentication.mdx      | 42 ++++++++++++--
 src/content/cre/reference/cli/index.mdx       |  6 +-
 6 files changed, 141 insertions(+), 33 deletions(-)

diff --git a/src/content/cre/account/cli-login.mdx b/src/content/cre/account/cli-login.mdx
index 054586cd2d4..457d66b822f 100644
--- a/src/content/cre/account/cli-login.mdx
+++ b/src/content/cre/account/cli-login.mdx
@@ -5,7 +5,7 @@ title: "Logging in with the CLI"
 metadata:
   description: "Learn how to log in to the CRE CLI: authenticate through your browser, complete 2FA verification, and start using CLI commands."
   datePublished: "2025-11-04"
-  lastModified: "2026-02-12"
+  lastModified: "2026-03-26"
 ---
 
 import { Aside, ClickToZoom } from "@components"
@@ -80,3 +80,5 @@ Login completed successfully
 ```
 
 Your CLI session is authenticated and ready to use.
+
+In the terminal, the CLI may show **“Fetching user context…”** while it downloads your organization’s tenant configuration from the platform. It then writes **`~/.cre/context.yaml`** (registry manifest: vault gateway URL, registries, secrets auth flows, and related fields). That file is separate from your credentials file (`cre.yaml`). For details and a sanitized example, see [Tenant context cache](/cre/reference/cli/authentication#tenant-context-cache).
diff --git a/src/content/cre/account/managing-auth.mdx b/src/content/cre/account/managing-auth.mdx
index 8b36ba573a4..a9b6a5e8a11 100644
--- a/src/content/cre/account/managing-auth.mdx
+++ b/src/content/cre/account/managing-auth.mdx
@@ -5,7 +5,7 @@ title: "Managing Authentication"
 metadata:
   description: "Manage your CRE CLI sessions: check if you're logged in, handle expired sessions, and securely log out when needed."
   datePublished: "2025-11-04"
-  lastModified: "2026-02-12"
+  lastModified: "2026-03-26"
 ---
 
 import { Aside } from "@components"
@@ -18,6 +18,8 @@ To authenticate your CLI with your CRE account, use the `cre login` command. Thi
 
 For detailed login instructions, see the [Logging in with the CLI](/cre/account/cli-login) guide.
 
+Browser login stores **`~/.cre/cre.yaml`** (credentials) and **`~/.cre/context.yaml`** (cached **tenant context**: registry manifest from the platform, including vault gateway URL and related settings). **`cre logout`** removes both. For a full description and a sample `context.yaml` shape, see [Tenant context cache](/cre/reference/cli/authentication#tenant-context-cache).
+
 ## API key authentication
 
 {/* prettier-ignore */}
@@ -70,7 +72,7 @@ To check your deploy access status or submit a request, see [Requesting Deploy A
 
 ## Logging out
 
-To explicitly end your CLI session and remove your stored credentials, use the `cre logout` command:
+To explicitly end your CLI session and remove your stored credentials **and cached tenant context** (`context.yaml`), use the `cre logout` command:
 
 ```bash
 cre logout
diff --git a/src/content/cre/llms-full-go.txt b/src/content/cre/llms-full-go.txt
index 4a339826160..597ab12914f 100644
--- a/src/content/cre/llms-full-go.txt
+++ b/src/content/cre/llms-full-go.txt
@@ -6886,7 +6886,7 @@ Once your account is created:
 
 # Logging in with the CLI
 Source: https://docs.chain.link/cre/account/cli-login
-Last Updated: 2026-02-12
+Last Updated: 2026-03-26
 
 To deploy and manage workflows with the CRE CLI, you need to authenticate your CLI session with your CRE account. This guide walks you through the browser-based login process.
 
@@ -6947,11 +6947,13 @@ Login completed successfully
 
 Your CLI session is authenticated and ready to use.
 
+In the terminal, the CLI may show **“Fetching user context…”** while it downloads your organization’s tenant configuration from the platform. It then writes **`~/.cre/context.yaml`** (registry manifest: vault gateway URL, registries, secrets auth flows, and related fields). That file is separate from your credentials file (`cre.yaml`). For details and a sanitized example, see [Tenant context cache](/cre/reference/cli/authentication#tenant-context-cache).
+
 ---
 
 # Managing Authentication
 Source: https://docs.chain.link/cre/account/managing-auth
-Last Updated: 2026-02-12
+Last Updated: 2026-03-26
 
 This guide covers how to manage your CLI authentication, including browser-based login, API key authentication, checking your status, handling session expiration, and logging out.
 
@@ -6961,6 +6963,8 @@ To authenticate your CLI with your CRE account, use the `cre login` command. Thi
 
 For detailed login instructions, see the [Logging in with the CLI](/cre/account/cli-login) guide.
 
+Browser login stores **`~/.cre/cre.yaml`** (credentials) and **`~/.cre/context.yaml`** (cached **tenant context**: registry manifest from the platform, including vault gateway URL and related settings). **`cre logout`** removes both. For a full description and a sample `context.yaml` shape, see [Tenant context cache](/cre/reference/cli/authentication#tenant-context-cache).
+
 ## API key authentication
 
 
@@ -7013,7 +7017,7 @@ To check your deploy access status or submit a request, see [Requesting Deploy A
 
 ## Logging out
 
-To explicitly end your CLI session and remove your stored credentials, use the `cre logout` command:
+To explicitly end your CLI session and remove your stored credentials **and cached tenant context** (`context.yaml`), use the `cre logout` command:
 
 ```bash
 cre logout
@@ -8026,7 +8030,7 @@ See the [repository README](https://github.com/smartcontractkit/cre-gcp-predicti
 
 # CLI Reference
 Source: https://docs.chain.link/cre/reference/cli
-Last Updated: 2026-03-17
+Last Updated: 2026-03-26
 
 <Aside type="note" title="Required CLI Version: v1.5.0">
   To ensure compatibility with the guides and examples in this documentation, please use version `v1.5.0` of the CRE
@@ -8054,8 +8058,8 @@ These flags can be used with any `cre` command.
 
 Manage your authentication and account credentials.
 
-- **`cre login`** — Authenticate with the CRE UI and save credentials locally
-- **`cre logout`** — Revoke authentication tokens and remove local credentials
+- **`cre login`** — Authenticate with the CRE UI, save credentials locally, and cache tenant context (`context.yaml`)
+- **`cre logout`** — Revoke authentication tokens and remove local credentials and cached tenant context
 - **`cre whoami`** — Show your current account details
 
 [View authentication commands →](/cre/reference/cli/authentication)
@@ -8159,7 +8163,7 @@ The typical workflow development process uses these commands in sequence:
 
 # Authentication Commands
 Source: https://docs.chain.link/cre/reference/cli/authentication
-Last Updated: 2026-02-12
+Last Updated: 2026-03-26
 
 The CRE CLI supports two authentication methods:
 
@@ -8170,7 +8174,7 @@ The CRE CLI supports two authentication methods:
 
 ### `cre login`
 
-Starts the interactive authentication flow. This command opens your browser for user login and saves your credentials locally.
+Starts the interactive authentication flow. This command opens your browser for user login, saves your credentials locally to `~/.cre/cre.yaml`, and **fetches your tenant context** from the CRE platform. That response is cached per CRE environment (for example `PRODUCTION`) in **`~/.cre/context.yaml`** — a registry manifest that includes items such as your vault gateway URL, workflow registries, and which secrets authentication flows each registry supports. See [Tenant context cache](#tenant-context-cache) below.
 
 **Usage:**
 
@@ -8184,13 +8188,13 @@ cre login
 2. Enter your account email address
 3. Enter your account password
 4. Enter your one-time password (OTP) from your authenticator app
-5. The CLI automatically captures and saves your credentials locally
+5. The CLI automatically captures and saves your credentials locally, then fetches and caches tenant context (you may see **“Fetching user context…”** in the terminal)
 
 For a detailed walkthrough with screenshots, see [Logging in with the CLI](/cre/account/cli-login).
 
 ### `cre logout`
 
-Revokes authentication tokens and removes local credentials. This invalidates the current authentication tokens and deletes stored credentials from your machine.
+Revokes authentication tokens and removes **local credentials** (`~/.cre/cre.yaml`) **and the cached tenant context file** (`~/.cre/context.yaml`). This invalidates the current session tokens and clears the CLI-side copy of your tenant registry manifest.
 
 **Usage:**
 
@@ -8244,10 +8248,42 @@ export CRE_API_KEY="your-api-key"
 cre whoami
 ```
 
-When `CRE_API_KEY` is set, the CLI skips the browser-based login flow entirely. All commands that require authentication (deploying, managing workflows, etc.) will use the API key.
+When `CRE_API_KEY` is set, the CLI skips the browser-based login flow entirely. All commands that require authentication (deploying, managing workflows, etc.) will use the API key. The CLI still **ensures tenant context** is available (fetching or refreshing `~/.cre/context.yaml` as needed) so your session matches the platform configuration for that key.
 
 In a CI/CD pipeline, configure `CRE_API_KEY` as a secret environment variable in your platform and run CLI commands as usual.
 
+## Tenant context cache
+
+After a successful browser login — and when using an API key for commands that load credentials — the CLI stores **tenant context** at **`~/.cre/context.yaml`**. This file comes from the platform’s **`getTenantConfig`** data: a **registry manifest** for your organization so the CLI knows your CRE environment layout (for example vault gateway URL, registries, and allowed secrets auth flows per registry). Values are grouped under your CRE environment name (such as `PRODUCTION`).
+
+
+<Aside type="note" title="Credentials vs tenant context">
+  **`cre.yaml`** holds authentication tokens for your session. **`context.yaml`** holds **tenant configuration** returned by the platform, not secrets. **`cre logout`** removes both files from your machine.
+</Aside>
+
+The following example is **illustrative** only; your registries, addresses, and flow lists depend on your organization and environment.
+
+```yaml
+PRODUCTION:
+  tenant_id: "<tenant-id>"
+  default_don_family: zone-a
+  vault_gateway_url: https://01.gateway.zone-a.cre.chain.link
+  registries:
+    - id: onchain:ethereum-mainnet
+      label: ethereum-mainnet (0x1234...abcd)
+      type: on-chain
+      chain_selector: "<chain-selector>"
+      address: "0x0000000000000000000000000000000000000000"
+      secrets_auth_flows:
+        - browser
+        - owner-key-signing
+    - id: private
+      label: Private (Chainlink-hosted)
+      type: off-chain
+      secrets_auth_flows:
+        - browser
+```
+
 ## Authentication methods summary
 
 | Method        | Best for                              | How it works                                         |
diff --git a/src/content/cre/llms-full-ts.txt b/src/content/cre/llms-full-ts.txt
index 71c4a8f67c1..ac0c7cf1914 100644
--- a/src/content/cre/llms-full-ts.txt
+++ b/src/content/cre/llms-full-ts.txt
@@ -6001,7 +6001,7 @@ Once your account is created:
 
 # Logging in with the CLI
 Source: https://docs.chain.link/cre/account/cli-login
-Last Updated: 2026-02-12
+Last Updated: 2026-03-26
 
 To deploy and manage workflows with the CRE CLI, you need to authenticate your CLI session with your CRE account. This guide walks you through the browser-based login process.
 
@@ -6062,11 +6062,13 @@ Login completed successfully
 
 Your CLI session is authenticated and ready to use.
 
+In the terminal, the CLI may show **“Fetching user context…”** while it downloads your organization’s tenant configuration from the platform. It then writes **`~/.cre/context.yaml`** (registry manifest: vault gateway URL, registries, secrets auth flows, and related fields). That file is separate from your credentials file (`cre.yaml`). For details and a sanitized example, see [Tenant context cache](/cre/reference/cli/authentication#tenant-context-cache).
+
 ---
 
 # Managing Authentication
 Source: https://docs.chain.link/cre/account/managing-auth
-Last Updated: 2026-02-12
+Last Updated: 2026-03-26
 
 This guide covers how to manage your CLI authentication, including browser-based login, API key authentication, checking your status, handling session expiration, and logging out.
 
@@ -6076,6 +6078,8 @@ To authenticate your CLI with your CRE account, use the `cre login` command. Thi
 
 For detailed login instructions, see the [Logging in with the CLI](/cre/account/cli-login) guide.
 
+Browser login stores **`~/.cre/cre.yaml`** (credentials) and **`~/.cre/context.yaml`** (cached **tenant context**: registry manifest from the platform, including vault gateway URL and related settings). **`cre logout`** removes both. For a full description and a sample `context.yaml` shape, see [Tenant context cache](/cre/reference/cli/authentication#tenant-context-cache).
+
 ## API key authentication
 
 
@@ -6128,7 +6132,7 @@ To check your deploy access status or submit a request, see [Requesting Deploy A
 
 ## Logging out
 
-To explicitly end your CLI session and remove your stored credentials, use the `cre logout` command:
+To explicitly end your CLI session and remove your stored credentials **and cached tenant context** (`context.yaml`), use the `cre logout` command:
 
 ```bash
 cre logout
@@ -7196,7 +7200,7 @@ See the [repository README](https://github.com/smartcontractkit/cre-gcp-predicti
 
 # CLI Reference
 Source: https://docs.chain.link/cre/reference/cli
-Last Updated: 2026-03-17
+Last Updated: 2026-03-26
 
 <Aside type="note" title="Required CLI Version: v1.5.0">
   To ensure compatibility with the guides and examples in this documentation, please use version `v1.5.0` of the CRE
@@ -7224,8 +7228,8 @@ These flags can be used with any `cre` command.
 
 Manage your authentication and account credentials.
 
-- **`cre login`** — Authenticate with the CRE UI and save credentials locally
-- **`cre logout`** — Revoke authentication tokens and remove local credentials
+- **`cre login`** — Authenticate with the CRE UI, save credentials locally, and cache tenant context (`context.yaml`)
+- **`cre logout`** — Revoke authentication tokens and remove local credentials and cached tenant context
 - **`cre whoami`** — Show your current account details
 
 [View authentication commands →](/cre/reference/cli/authentication)
@@ -7329,7 +7333,7 @@ The typical workflow development process uses these commands in sequence:
 
 # Authentication Commands
 Source: https://docs.chain.link/cre/reference/cli/authentication
-Last Updated: 2026-02-12
+Last Updated: 2026-03-26
 
 The CRE CLI supports two authentication methods:
 
@@ -7340,7 +7344,7 @@ The CRE CLI supports two authentication methods:
 
 ### `cre login`
 
-Starts the interactive authentication flow. This command opens your browser for user login and saves your credentials locally.
+Starts the interactive authentication flow. This command opens your browser for user login, saves your credentials locally to `~/.cre/cre.yaml`, and **fetches your tenant context** from the CRE platform. That response is cached per CRE environment (for example `PRODUCTION`) in **`~/.cre/context.yaml`** — a registry manifest that includes items such as your vault gateway URL, workflow registries, and which secrets authentication flows each registry supports. See [Tenant context cache](#tenant-context-cache) below.
 
 **Usage:**
 
@@ -7354,13 +7358,13 @@ cre login
 2. Enter your account email address
 3. Enter your account password
 4. Enter your one-time password (OTP) from your authenticator app
-5. The CLI automatically captures and saves your credentials locally
+5. The CLI automatically captures and saves your credentials locally, then fetches and caches tenant context (you may see **“Fetching user context…”** in the terminal)
 
 For a detailed walkthrough with screenshots, see [Logging in with the CLI](/cre/account/cli-login).
 
 ### `cre logout`
 
-Revokes authentication tokens and removes local credentials. This invalidates the current authentication tokens and deletes stored credentials from your machine.
+Revokes authentication tokens and removes **local credentials** (`~/.cre/cre.yaml`) **and the cached tenant context file** (`~/.cre/context.yaml`). This invalidates the current session tokens and clears the CLI-side copy of your tenant registry manifest.
 
 **Usage:**
 
@@ -7414,10 +7418,42 @@ export CRE_API_KEY="your-api-key"
 cre whoami
 ```
 
-When `CRE_API_KEY` is set, the CLI skips the browser-based login flow entirely. All commands that require authentication (deploying, managing workflows, etc.) will use the API key.
+When `CRE_API_KEY` is set, the CLI skips the browser-based login flow entirely. All commands that require authentication (deploying, managing workflows, etc.) will use the API key. The CLI still **ensures tenant context** is available (fetching or refreshing `~/.cre/context.yaml` as needed) so your session matches the platform configuration for that key.
 
 In a CI/CD pipeline, configure `CRE_API_KEY` as a secret environment variable in your platform and run CLI commands as usual.
 
+## Tenant context cache
+
+After a successful browser login — and when using an API key for commands that load credentials — the CLI stores **tenant context** at **`~/.cre/context.yaml`**. This file comes from the platform’s **`getTenantConfig`** data: a **registry manifest** for your organization so the CLI knows your CRE environment layout (for example vault gateway URL, registries, and allowed secrets auth flows per registry). Values are grouped under your CRE environment name (such as `PRODUCTION`).
+
+
+<Aside type="note" title="Credentials vs tenant context">
+  **`cre.yaml`** holds authentication tokens for your session. **`context.yaml`** holds **tenant configuration** returned by the platform, not secrets. **`cre logout`** removes both files from your machine.
+</Aside>
+
+The following example is **illustrative** only; your registries, addresses, and flow lists depend on your organization and environment.
+
+```yaml
+PRODUCTION:
+  tenant_id: "<tenant-id>"
+  default_don_family: zone-a
+  vault_gateway_url: https://01.gateway.zone-a.cre.chain.link
+  registries:
+    - id: onchain:ethereum-mainnet
+      label: ethereum-mainnet (0x1234...abcd)
+      type: on-chain
+      chain_selector: "<chain-selector>"
+      address: "0x0000000000000000000000000000000000000000"
+      secrets_auth_flows:
+        - browser
+        - owner-key-signing
+    - id: private
+      label: Private (Chainlink-hosted)
+      type: off-chain
+      secrets_auth_flows:
+        - browser
+```
+
 ## Authentication methods summary
 
 | Method        | Best for                              | How it works                                         |
diff --git a/src/content/cre/reference/cli/authentication.mdx b/src/content/cre/reference/cli/authentication.mdx
index 59fd31be2a5..e9bb3fd3ac8 100644
--- a/src/content/cre/reference/cli/authentication.mdx
+++ b/src/content/cre/reference/cli/authentication.mdx
@@ -5,7 +5,7 @@ title: "Authentication Commands"
 metadata:
   description: "Manage your CLI authentication: browser-based login, API key authentication for CI/CD, and session management commands."
   datePublished: "2025-11-04"
-  lastModified: "2026-02-12"
+  lastModified: "2026-03-26"
 ---
 
 import { Aside } from "@components"
@@ -19,7 +19,7 @@ The CRE CLI supports two authentication methods:
 
 ### `cre login`
 
-Starts the interactive authentication flow. This command opens your browser for user login and saves your credentials locally.
+Starts the interactive authentication flow. This command opens your browser for user login, saves your credentials locally to `~/.cre/cre.yaml`, and **fetches your tenant context** from the CRE platform. That response is cached per CRE environment (for example `PRODUCTION`) in **`~/.cre/context.yaml`** — a registry manifest that includes items such as your vault gateway URL, workflow registries, and which secrets authentication flows each registry supports. See [Tenant context cache](#tenant-context-cache) below.
 
 **Usage:**
 
@@ -33,13 +33,13 @@ cre login
 1. Enter your account email address
 1. Enter your account password
 1. Enter your one-time password (OTP) from your authenticator app
-1. The CLI automatically captures and saves your credentials locally
+1. The CLI automatically captures and saves your credentials locally, then fetches and caches tenant context (you may see **“Fetching user context…”** in the terminal)
 
 For a detailed walkthrough with screenshots, see [Logging in with the CLI](/cre/account/cli-login).
 
 ### `cre logout`
 
-Revokes authentication tokens and removes local credentials. This invalidates the current authentication tokens and deletes stored credentials from your machine.
+Revokes authentication tokens and removes **local credentials** (`~/.cre/cre.yaml`) **and the cached tenant context file** (`~/.cre/context.yaml`). This invalidates the current session tokens and clears the CLI-side copy of your tenant registry manifest.
 
 **Usage:**
 
@@ -93,10 +93,42 @@ export CRE_API_KEY="your-api-key"
 cre whoami
 ```
 
-When `CRE_API_KEY` is set, the CLI skips the browser-based login flow entirely. All commands that require authentication (deploying, managing workflows, etc.) will use the API key.
+When `CRE_API_KEY` is set, the CLI skips the browser-based login flow entirely. All commands that require authentication (deploying, managing workflows, etc.) will use the API key. The CLI still **ensures tenant context** is available (fetching or refreshing `~/.cre/context.yaml` as needed) so your session matches the platform configuration for that key.
 
 In a CI/CD pipeline, configure `CRE_API_KEY` as a secret environment variable in your platform and run CLI commands as usual.
 
+## Tenant context cache
+
+After a successful browser login — and when using an API key for commands that load credentials — the CLI stores **tenant context** at **`~/.cre/context.yaml`**. This file comes from the platform’s **`getTenantConfig`** data: a **registry manifest** for your organization so the CLI knows your CRE environment layout (for example vault gateway URL, registries, and allowed secrets auth flows per registry). Values are grouped under your CRE environment name (such as `PRODUCTION`).
+
+{/* prettier-ignore */}
+<Aside type="note" title="Credentials vs tenant context">
+  **`cre.yaml`** holds authentication tokens for your session. **`context.yaml`** holds **tenant configuration** returned by the platform, not secrets. **`cre logout`** removes both files from your machine.
+</Aside>
+
+The following example is **illustrative** only; your registries, addresses, and flow lists depend on your organization and environment.
+
+```yaml
+PRODUCTION:
+  tenant_id: "<tenant-id>"
+  default_don_family: zone-a
+  vault_gateway_url: https://01.gateway.zone-a.cre.chain.link
+  registries:
+    - id: onchain:ethereum-mainnet
+      label: ethereum-mainnet (0x1234...abcd)
+      type: on-chain
+      chain_selector: "<chain-selector>"
+      address: "0x0000000000000000000000000000000000000000"
+      secrets_auth_flows:
+        - browser
+        - owner-key-signing
+    - id: private
+      label: Private (Chainlink-hosted)
+      type: off-chain
+      secrets_auth_flows:
+        - browser
+```
+
 ## Authentication methods summary
 
 | <div style="width: 100px;">Method</div> | Best for                              | How it works                                         |
diff --git a/src/content/cre/reference/cli/index.mdx b/src/content/cre/reference/cli/index.mdx
index ba84f54e564..fcfcaf1aea4 100644
--- a/src/content/cre/reference/cli/index.mdx
+++ b/src/content/cre/reference/cli/index.mdx
@@ -6,7 +6,7 @@ isIndex: true
 metadata:
   description: "Explore all CRE CLI commands: complete reference for project setup, workflow deployment, account management, and development tools."
   datePublished: "2025-11-04"
-  lastModified: "2026-03-17"
+  lastModified: "2026-03-26"
 ---
 
 import { Aside } from "@components"
@@ -37,8 +37,8 @@ These flags can be used with any `cre` command.
 
 Manage your authentication and account credentials.
 
-- **`cre login`** — Authenticate with the CRE UI and save credentials locally
-- **`cre logout`** — Revoke authentication tokens and remove local credentials
+- **`cre login`** — Authenticate with the CRE UI, save credentials locally, and cache tenant context (`context.yaml`)
+- **`cre logout`** — Revoke authentication tokens and remove local credentials and cached tenant context
 - **`cre whoami`** — Show your current account details
 
 [View authentication commands →](/cre/reference/cli/authentication)

From 06d9aa132971784efaaaa7deeca01dab6538102e Mon Sep 17 00:00:00 2001
From: devin distefano <devin.distefano@smartcontract.com>
Date: Thu, 26 Mar 2026 15:46:28 -0500
Subject: [PATCH 2/4] note about production cre: linked workflow owner vault
 auth

---
 src/content/cre/guides/workflow/secrets/index.mdx | 4 +++-
 src/content/cre/llms-full-go.txt                  | 7 +++++--
 src/content/cre/llms-full-ts.txt                  | 7 +++++--
 src/content/cre/reference/cli/secrets.mdx         | 3 ++-
 4 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/src/content/cre/guides/workflow/secrets/index.mdx b/src/content/cre/guides/workflow/secrets/index.mdx
index f2c8947533b..a273c158a7b 100644
--- a/src/content/cre/guides/workflow/secrets/index.mdx
+++ b/src/content/cre/guides/workflow/secrets/index.mdx
@@ -5,7 +5,7 @@ date: Last Modified
 metadata:
   description: "Secure your API keys and credentials: learn how to manage secrets safely in CRE for both simulated and deployed workflows."
   datePublished: "2025-11-04"
-  lastModified: "2025-11-04"
+  lastModified: "2026-03-26"
 ---
 
 import { Aside, CodeHighlightBlockMulti } from "@components"
@@ -42,6 +42,8 @@ Your workflow environment determines how you manage secrets:
 - Your workflow retrieves secrets from the Vault at runtime
 - **Vault DON required**
 
+**Production CRE** supports **only** the **linked workflow owner** authorization model for `cre secrets`. Alternate vault authorization is **not** available in production and currently exist only in **non-production** environments.
+
 **→ Follow this guide:** [Using Secrets with Deployed Workflows](/cre/guides/workflow/secrets/using-secrets-deployed)
 
 ### 3. Secure secret management (Best practice)
diff --git a/src/content/cre/llms-full-go.txt b/src/content/cre/llms-full-go.txt
index 597ab12914f..68e052b03c4 100644
--- a/src/content/cre/llms-full-go.txt
+++ b/src/content/cre/llms-full-go.txt
@@ -4330,7 +4330,7 @@ For a conceptual overview of what Confidential HTTP is and how it differs from t
 
 # Managing Secrets
 Source: https://docs.chain.link/cre/guides/workflow/secrets
-Last Updated: 2025-11-04
+Last Updated: 2026-03-26
 
 Secrets are sensitive values like API keys, private keys, database URLs, and authentication tokens that your workflow needs to access at runtime. CRE provides different approaches for managing secrets depending on whether you're developing locally or running workflows in production.
 
@@ -4364,6 +4364,8 @@ Your workflow environment determines how you manage secrets:
 - Your workflow retrieves secrets from the Vault at runtime
 - **Vault DON required**
 
+**Production CRE** supports **only** the **linked workflow owner** authorization model for `cre secrets`. Alternate vault authorization is **not** available in production and currently exist only in **non-production** environments.
+
 **→ Follow this guide:** [Using Secrets with Deployed Workflows](/cre/guides/workflow/secrets/using-secrets-deployed)
 
 ### 3. Secure secret management (Best practice)
@@ -8968,7 +8970,7 @@ The typical workflow lifecycle uses these commands in sequence:
 
 # Secrets Management Commands
 Source: https://docs.chain.link/cre/reference/cli/secrets
-Last Updated: 2025-11-04
+Last Updated: 2026-03-26
 
 <Aside type="note" title="Authentication required">
   Running the commands on this page requires you to be logged in with the CRE CLI. Run `cre whoami` in your terminal to
@@ -8986,6 +8988,7 @@ Secrets are organized into **namespaces**, which act as logical groupings (e.g.,
 <Aside type="note" title="Prerequisites">
   - You must be logged in with `cre login`
   - Your `workflow-owner-address` must be configured in your project
+  - **Production CRE:** only **linked workflow owner** vault authorization is supported for these commands. See ([Using Secrets with Deployed Workflows](/cre/guides/workflow/secrets/using-secrets-deployed))
   - For comprehensive guides on using secrets, see [Managing Secrets](/cre/guides/workflow/secrets)
 </Aside>
 
diff --git a/src/content/cre/llms-full-ts.txt b/src/content/cre/llms-full-ts.txt
index ac0c7cf1914..ba6041e2c66 100644
--- a/src/content/cre/llms-full-ts.txt
+++ b/src/content/cre/llms-full-ts.txt
@@ -3666,7 +3666,7 @@ For a conceptual overview of what Confidential HTTP is and how it differs from t
 
 # Managing Secrets
 Source: https://docs.chain.link/cre/guides/workflow/secrets
-Last Updated: 2025-11-04
+Last Updated: 2026-03-26
 
 Secrets are sensitive values like API keys, private keys, database URLs, and authentication tokens that your workflow needs to access at runtime. CRE provides different approaches for managing secrets depending on whether you're developing locally or running workflows in production.
 
@@ -3700,6 +3700,8 @@ Your workflow environment determines how you manage secrets:
 - Your workflow retrieves secrets from the Vault at runtime
 - **Vault DON required**
 
+**Production CRE** supports **only** the **linked workflow owner** authorization model for `cre secrets`. Alternate vault authorization is **not** available in production and currently exist only in **non-production** environments.
+
 **→ Follow this guide:** [Using Secrets with Deployed Workflows](/cre/guides/workflow/secrets/using-secrets-deployed)
 
 ### 3. Secure secret management (Best practice)
@@ -8138,7 +8140,7 @@ The typical workflow lifecycle uses these commands in sequence:
 
 # Secrets Management Commands
 Source: https://docs.chain.link/cre/reference/cli/secrets
-Last Updated: 2025-11-04
+Last Updated: 2026-03-26
 
 <Aside type="note" title="Authentication required">
   Running the commands on this page requires you to be logged in with the CRE CLI. Run `cre whoami` in your terminal to
@@ -8156,6 +8158,7 @@ Secrets are organized into **namespaces**, which act as logical groupings (e.g.,
 <Aside type="note" title="Prerequisites">
   - You must be logged in with `cre login`
   - Your `workflow-owner-address` must be configured in your project
+  - **Production CRE:** only **linked workflow owner** vault authorization is supported for these commands. See ([Using Secrets with Deployed Workflows](/cre/guides/workflow/secrets/using-secrets-deployed))
   - For comprehensive guides on using secrets, see [Managing Secrets](/cre/guides/workflow/secrets)
 </Aside>
 
diff --git a/src/content/cre/reference/cli/secrets.mdx b/src/content/cre/reference/cli/secrets.mdx
index e328b02ced3..f88d6462129 100644
--- a/src/content/cre/reference/cli/secrets.mdx
+++ b/src/content/cre/reference/cli/secrets.mdx
@@ -5,7 +5,7 @@ date: Last Modified
 metadata:
   description: "Manage production secrets with CLI: reference for creating, updating, and deleting secrets in the Vault DON."
   datePublished: "2025-11-04"
-  lastModified: "2025-11-04"
+  lastModified: "2026-03-26"
 ---
 
 import { Aside } from "@components"
@@ -26,6 +26,7 @@ Secrets are organized into **namespaces**, which act as logical groupings (e.g.,
 <Aside type="note" title="Prerequisites">
   - You must be logged in with `cre login`
   - Your `workflow-owner-address` must be configured in your project
+  - **Production CRE:** only **linked workflow owner** vault authorization is supported for these commands. See ([Using Secrets with Deployed Workflows](/cre/guides/workflow/secrets/using-secrets-deployed))
   - For comprehensive guides on using secrets, see [Managing Secrets](/cre/guides/workflow/secrets)
 </Aside>
 

From b7423a6ded154a218071635e0175fabcb430f2fb Mon Sep 17 00:00:00 2001
From: devin distefano <devin.distefano@smartcontract.com>
Date: Thu, 26 Mar 2026 16:14:12 -0500
Subject: [PATCH 3/4] scriptable init + templates & release notes

---
 public/changelog.json                         |  7 ++
 .../part-1-project-setup-go.mdx               |  7 +-
 .../part-1-project-setup-ts.mdx               |  7 +-
 src/content/cre/llms-full-go.txt              | 69 +++++++++++++------
 src/content/cre/llms-full-ts.txt              | 69 +++++++++++++------
 src/content/cre/reference/cli/index.mdx       |  4 +-
 .../cre/reference/cli/project-setup-go.mdx    | 30 +++++---
 .../cre/reference/cli/project-setup-ts.mdx    | 30 +++++---
 src/content/cre/reference/cli/templates.mdx   | 11 +--
 src/content/cre/release-notes.mdx             | 17 ++++-
 10 files changed, 179 insertions(+), 72 deletions(-)

diff --git a/public/changelog.json b/public/changelog.json
index 7ebde73f512..d7f77918655 100644
--- a/public/changelog.json
+++ b/public/changelog.json
@@ -398,6 +398,13 @@
     }
   },
   "data": [
+    {
+      "category": "release",
+      "date": "2026-03-26",
+      "description": "CRE CLI version 1.8.0 is now available. This release adds a tenant context cache (`~/.cre/context.yaml`) after login, scriptable `cre init` for CI pipelines, and `cre templates list --json` for machine-readable template listings.\n\nUpdate your CLI by running `cre update` when prompted, or follow the [CLI Installation guide](https://docs.chain.link/cre/getting-started/cli-installation) for fresh installations.\n\n[See all changes on GitHub](https://github.com/smartcontractkit/cre-cli/compare/v1.7.0...v1.8.0)",
+      "title": "CRE CLI v1.8.0 — Tenant Context and Scriptable Init",
+      "topic": "CRE"
+    },
     {
       "category": "release",
       "date": "2026-03-26",
diff --git a/src/content/cre/getting-started/part-1-project-setup-go.mdx b/src/content/cre/getting-started/part-1-project-setup-go.mdx
index 9f8bb8b0794..87452c132af 100644
--- a/src/content/cre/getting-started/part-1-project-setup-go.mdx
+++ b/src/content/cre/getting-started/part-1-project-setup-go.mdx
@@ -7,7 +7,7 @@ pageId: "getting-started-part-1"
 metadata:
   description: "Getting started Part 1 (Go): set up your first CRE project, explore the structure, and run a successful workflow simulation."
   datePublished: "2025-11-04"
-  lastModified: "2026-01-14"
+  lastModified: "2026-03-26"
 ---
 
 import { Aside, CopyText, CodeHighlightBlock } from "@components"
@@ -89,6 +89,11 @@ The CRE CLI provides an `init` command to scaffold a new project. It's an intera
 
 The CLI will then create a new `onchain-calculator` directory and initialize your first workflow within it.
 
+{/* prettier-ignore */}
+<Aside type="note" title="Scriptable init">
+  Prefer a **non-interactive** or **CI** flow? The CLI supports **`cre init --non-interactive`** and related flags—see [Project setup commands](/cre/reference/cli/project-setup).
+</Aside>
+
 ## Step 3: Explore the generated files
 
 The `init` command creates a directory with a standard structure and generates your first workflow code. Let's explore what was created.
diff --git a/src/content/cre/getting-started/part-1-project-setup-ts.mdx b/src/content/cre/getting-started/part-1-project-setup-ts.mdx
index 7c96dc090d4..74837dc30fb 100644
--- a/src/content/cre/getting-started/part-1-project-setup-ts.mdx
+++ b/src/content/cre/getting-started/part-1-project-setup-ts.mdx
@@ -7,7 +7,7 @@ pageId: "getting-started-part-1"
 metadata:
   description: "Getting started Part 1 (TypeScript): set up your first CRE project, explore the structure, and run a successful workflow simulation."
   datePublished: "2025-11-04"
-  lastModified: "2026-01-20"
+  lastModified: "2026-03-26"
 ---
 
 import { Aside, CopyText, CodeHighlightBlock } from "@components"
@@ -89,6 +89,11 @@ The CRE CLI provides an `init` command to scaffold a new project. It's an intera
 
 The CLI will then create a new `onchain-calculator` directory and initialize your first workflow within it.
 
+{/* prettier-ignore */}
+<Aside type="note" title="Scriptable init">
+  Prefer a **non-interactive** or **CI** flow? The CLI supports **`cre init --non-interactive`** and related flags—see [Project setup commands](/cre/reference/cli/project-setup).
+</Aside>
+
 ## Step 3: Explore the generated files
 
 The `init` command creates a directory with a standard structure and generates your first workflow code. Let's explore what was created.
diff --git a/src/content/cre/llms-full-go.txt b/src/content/cre/llms-full-go.txt
index 68e052b03c4..e24b7df4af0 100644
--- a/src/content/cre/llms-full-go.txt
+++ b/src/content/cre/llms-full-go.txt
@@ -448,10 +448,25 @@ To help us assist you faster, please include:
 
 # Release Notes
 Source: https://docs.chain.link/cre/release-notes
-Last Updated: 2026-03-23
+Last Updated: 2026-03-26
 
 This page provides detailed release notes for CRE. It includes information on new features, significant changes, and known limitations.
 
+## CLI v1.8.0 - March 26, 2026
+
+**<a href="https://github.com/smartcontractkit/cre-cli/releases/tag/v1.8.0" target="_blank">CRE CLI version 1.8.0</a> is now available.**
+
+- **Tenant context cache**: The [**Authentication**](/cre/reference/cli/authentication#tenant-context-cache) reference documents **`~/.cre/context.yaml`**, which the CLI updates after login so your local session reflects the platform’s registry manifest.
+- **Scriptable `cre init`**: [**Project setup**](/cre/reference/cli/project-setup) covers **`cre init --non-interactive`** and related flags for CI and automation without prompts.
+- **`cre templates list --json`**: Use [**Template sources**](/cre/reference/cli/templates) for **`--json`** output when you need machine-readable template listings in scripts.
+
+**How to update:**
+
+- **Automatic update**: When you run any CRE command, the CLI will automatically detect if a newer version is available and prompt you to update. Simply run `cre update` to install the latest version.
+- **Fresh installation**: If you're installing the CLI for the first time, follow the [CLI Installation guide](/cre/getting-started/cli-installation).
+
+[See all changes on GitHub](https://github.com/smartcontractkit/cre-cli/compare/v1.7.0...v1.8.0)
+
 ## CLI v1.7.0 - March 23, 2026
 
 **<a href="https://github.com/smartcontractkit/cre-cli/releases/tag/v1.7.0" target="_blank">CRE CLI version 1.7.0</a> is now available.**
@@ -8072,7 +8087,7 @@ Manage your authentication and account credentials.
 
 Initialize projects and generate contract bindings (Go only).
 
-- **`cre init`** — Initialize a new CRE project with an interactive setup guide
+- [**`cre init`**](/cre/reference/cli/project-setup) — Initialize a new CRE project (interactive wizard or **`--non-interactive`** with flags for CI/CD)
 - **`cre generate-bindings`** (Go only) — Generate Go bindings from contract ABI files for type-safe contract interactions
 
 [View project setup commands →](/cre/reference/cli/project-setup)
@@ -8126,7 +8141,7 @@ Manage secrets stored in the Vault DON for use in your workflows.
 
 Manage the GitHub repositories that `cre init` uses to discover templates.
 
-- **`cre templates list`** — List all templates available from configured sources
+- **`cre templates list`** — List templates (human output includes required networks; **`--json`** for scripts)
 - **`cre templates add`** — Add a custom or third-party template repository
 - **`cre templates remove`** — Remove a template repository source
 
@@ -9227,7 +9242,7 @@ For details, see [Using Multi-sig Wallets](/cre/guides/operations/using-multisig
 
 # Template Sources
 Source: https://docs.chain.link/cre/reference/cli/templates
-Last Updated: 2026-02-26
+Last Updated: 2026-03-26
 
 The `cre templates` commands manage the GitHub repository sources that `cre init` uses to discover workflow templates.
 
@@ -9250,11 +9265,12 @@ cre templates list [flags]
 
 **Flags:**
 
-| Flag        | Description                                             |
-| ----------- | ------------------------------------------------------- |
-| `--refresh` | Bypass the local cache and fetch fresh data from GitHub |
+| Flag        | Description                                               |
+| ----------- | --------------------------------------------------------- |
+| `--json`    | Print the template list as **JSON** (for scripts and CI). |
+| `--refresh` | Bypass the local cache and fetch fresh data from GitHub   |
 
-Each entry shows the template title, ID, language, and a short description. Use the ID with `cre init --template=<id>` to scaffold a project from that template.
+Each entry shows the template title, ID, language, a short description, and **required networks** (chains you must supply RPCs for when using `cre init`, especially with **`--non-interactive`**). Use the template name with **`cre init --template=<name>`** to scaffold a project.
 
 For the current list of available templates, run `cre templates list` or visit [docs.chain.link/cre-templates](https://docs.chain.link/cre-templates).
 
@@ -9911,7 +9927,7 @@ I want to build: [describe your use case]
 
 # Part 1: Project Setup & Simulation
 Source: https://docs.chain.link/cre/getting-started/part-1-project-setup-go
-Last Updated: 2026-01-14
+Last Updated: 2026-03-26
 
 <Aside type="note" title="SDK Language: Go">
   You're viewing the **Go** version of this guide. If you prefer TypeScript, use the language selector in the left
@@ -9989,6 +10005,11 @@ The CRE CLI provides an `init` command to scaffold a new project. It's an intera
 
 The CLI will then create a new `onchain-calculator` directory and initialize your first workflow within it.
 
+
+<Aside type="note" title="Scriptable init">
+  Prefer a **non-interactive** or **CI** flow? The CLI supports **`cre init --non-interactive`** and related flags—see [Project setup commands](/cre/reference/cli/project-setup).
+</Aside>
+
 ## Step 3: Explore the generated files
 
 The `init` command creates a directory with a standard structure and generates your first workflow code. Let's explore what was created.
@@ -15329,7 +15350,7 @@ Or explore the SDK reference for detailed API documentation:
 
 # Project Setup Commands
 Source: https://docs.chain.link/cre/reference/cli/project-setup-go
-Last Updated: 2026-03-17
+Last Updated: 2026-03-26
 
 The project setup commands include `cre init` to initialize new CRE projects or add workflows, and `cre generate-bindings` to generate contract bindings for type-safe contract interactions.
 
@@ -15359,11 +15380,16 @@ cre init [flags]
 
 **Flags:**
 
-| Flag                  | Description                        |
-| --------------------- | ---------------------------------- |
-| `-p, --project-name`  | Name for the new project           |
-| `-t, --template-id`   | ID of the workflow template to use |
-| `-w, --workflow-name` | Name for the new workflow          |
+| Flag                  | Description                                                                                                                               |
+| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
+| `--non-interactive`   | Fail instead of prompting; supply all inputs via flags (for **CI/CD** and non-TTY environments).                                          |
+| `-p, --project-name`  | Name for the new project (required for a new project when using `--non-interactive`).                                                     |
+| `-t, --template`      | Template name to use (for example `hello-world-go`). Run `cre templates list` to see IDs and required networks.                           |
+| `-w, --workflow-name` | Name for the new workflow.                                                                                                                |
+| `--refresh`           | Bypass the template cache and fetch fresh data from GitHub.                                                                               |
+| `--rpc-url`           | RPC endpoint for a chain, repeatable. Format: `chain-name=url`. Often **required** with `--non-interactive` when the template needs RPCs. |
+
+Inherited [global flags](/cre/reference/cli#global-flags) include **`-R, --project-root`**, which `cre init` uses as the directory where the project is created when you pass it explicitly.
 
 **Interactive mode (recommended):**
 
@@ -15386,19 +15412,22 @@ Running `cre init` without flags starts an interactive setup that guides you thr
 cre init
 ```
 
-**Non-interactive mode:**
+**Non-interactive mode (scripting / CI):**
+
+Pass **`--non-interactive`** plus the flags your template needs. Use **`cre templates list`** (or **`cre templates list --json`**) to see **required networks** and choose **`--rpc-url`** values.
 
 ```bash
-# Create a new project with initial workflow
 cre init \
+  --non-interactive \
   --project-name my-cre-project \
   --workflow-name my-workflow \
-  --template-id 1
+  --template hello-world-go \
+  --rpc-url sepolia=https://sepolia.infura.io/v3/YOUR_KEY
 ```
 
+
 <Aside type="note" title="Interactive vs. non-interactive">
-  For most users, running `cre init` without flags (interactive mode) is the easiest way to set up a project. The CLI
-  will guide you through the setup process with clear prompts.
+  For most users, `cre init` without flags is easiest. With **`--non-interactive`**, the CLI does not prompt; if RPC URLs are required and there is no TTY, you get a clear error—pass the needed **`--rpc-url`** flags up front.
 </Aside>
 
 For a detailed walkthrough, see [Part 1 of the Getting Started guide](/cre/getting-started/part-1-project-setup).
diff --git a/src/content/cre/llms-full-ts.txt b/src/content/cre/llms-full-ts.txt
index ba6041e2c66..48c2956a852 100644
--- a/src/content/cre/llms-full-ts.txt
+++ b/src/content/cre/llms-full-ts.txt
@@ -448,10 +448,25 @@ To help us assist you faster, please include:
 
 # Release Notes
 Source: https://docs.chain.link/cre/release-notes
-Last Updated: 2026-03-23
+Last Updated: 2026-03-26
 
 This page provides detailed release notes for CRE. It includes information on new features, significant changes, and known limitations.
 
+## CLI v1.8.0 - March 26, 2026
+
+**<a href="https://github.com/smartcontractkit/cre-cli/releases/tag/v1.8.0" target="_blank">CRE CLI version 1.8.0</a> is now available.**
+
+- **Tenant context cache**: The [**Authentication**](/cre/reference/cli/authentication#tenant-context-cache) reference documents **`~/.cre/context.yaml`**, which the CLI updates after login so your local session reflects the platform’s registry manifest.
+- **Scriptable `cre init`**: [**Project setup**](/cre/reference/cli/project-setup) covers **`cre init --non-interactive`** and related flags for CI and automation without prompts.
+- **`cre templates list --json`**: Use [**Template sources**](/cre/reference/cli/templates) for **`--json`** output when you need machine-readable template listings in scripts.
+
+**How to update:**
+
+- **Automatic update**: When you run any CRE command, the CLI will automatically detect if a newer version is available and prompt you to update. Simply run `cre update` to install the latest version.
+- **Fresh installation**: If you're installing the CLI for the first time, follow the [CLI Installation guide](/cre/getting-started/cli-installation).
+
+[See all changes on GitHub](https://github.com/smartcontractkit/cre-cli/compare/v1.7.0...v1.8.0)
+
 ## CLI v1.7.0 - March 23, 2026
 
 **<a href="https://github.com/smartcontractkit/cre-cli/releases/tag/v1.7.0" target="_blank">CRE CLI version 1.7.0</a> is now available.**
@@ -7242,7 +7257,7 @@ Manage your authentication and account credentials.
 
 Initialize projects and generate contract bindings (Go only).
 
-- **`cre init`** — Initialize a new CRE project with an interactive setup guide
+- [**`cre init`**](/cre/reference/cli/project-setup) — Initialize a new CRE project (interactive wizard or **`--non-interactive`** with flags for CI/CD)
 - **`cre generate-bindings`** (Go only) — Generate Go bindings from contract ABI files for type-safe contract interactions
 
 [View project setup commands →](/cre/reference/cli/project-setup)
@@ -7296,7 +7311,7 @@ Manage secrets stored in the Vault DON for use in your workflows.
 
 Manage the GitHub repositories that `cre init` uses to discover templates.
 
-- **`cre templates list`** — List all templates available from configured sources
+- **`cre templates list`** — List templates (human output includes required networks; **`--json`** for scripts)
 - **`cre templates add`** — Add a custom or third-party template repository
 - **`cre templates remove`** — Remove a template repository source
 
@@ -8397,7 +8412,7 @@ For details, see [Using Multi-sig Wallets](/cre/guides/operations/using-multisig
 
 # Template Sources
 Source: https://docs.chain.link/cre/reference/cli/templates
-Last Updated: 2026-02-26
+Last Updated: 2026-03-26
 
 The `cre templates` commands manage the GitHub repository sources that `cre init` uses to discover workflow templates.
 
@@ -8420,11 +8435,12 @@ cre templates list [flags]
 
 **Flags:**
 
-| Flag        | Description                                             |
-| ----------- | ------------------------------------------------------- |
-| `--refresh` | Bypass the local cache and fetch fresh data from GitHub |
+| Flag        | Description                                               |
+| ----------- | --------------------------------------------------------- |
+| `--json`    | Print the template list as **JSON** (for scripts and CI). |
+| `--refresh` | Bypass the local cache and fetch fresh data from GitHub   |
 
-Each entry shows the template title, ID, language, and a short description. Use the ID with `cre init --template=<id>` to scaffold a project from that template.
+Each entry shows the template title, ID, language, a short description, and **required networks** (chains you must supply RPCs for when using `cre init`, especially with **`--non-interactive`**). Use the template name with **`cre init --template=<name>`** to scaffold a project.
 
 For the current list of available templates, run `cre templates list` or visit [docs.chain.link/cre-templates](https://docs.chain.link/cre-templates).
 
@@ -9388,7 +9404,7 @@ I want to build: [describe your use case]
 
 # Part 1: Project Setup & Simulation
 Source: https://docs.chain.link/cre/getting-started/part-1-project-setup-ts
-Last Updated: 2026-01-20
+Last Updated: 2026-03-26
 
 <Aside type="note" title="SDK Language: TypeScript">
   You're viewing the **TypeScript** version of this guide. If you prefer Go, use the language selector in the left
@@ -9466,6 +9482,11 @@ The CRE CLI provides an `init` command to scaffold a new project. It's an intera
 
 The CLI will then create a new `onchain-calculator` directory and initialize your first workflow within it.
 
+
+<Aside type="note" title="Scriptable init">
+  Prefer a **non-interactive** or **CI** flow? The CLI supports **`cre init --non-interactive`** and related flags—see [Project setup commands](/cre/reference/cli/project-setup).
+</Aside>
+
 ## Step 3: Explore the generated files
 
 The `init` command creates a directory with a standard structure and generates your first workflow code. Let's explore what was created.
@@ -14849,7 +14870,7 @@ Or explore the SDK reference for detailed API documentation:
 
 # Project Setup Commands
 Source: https://docs.chain.link/cre/reference/cli/project-setup-ts
-Last Updated: 2026-02-26
+Last Updated: 2026-03-26
 
 The project setup command `cre init` initializes new CRE projects or adds workflows to existing projects.
 
@@ -14879,11 +14900,16 @@ cre init [flags]
 
 **Flags:**
 
-| Flag                  | Description                        |
-| --------------------- | ---------------------------------- |
-| `-p, --project-name`  | Name for the new project           |
-| `-t, --template-id`   | ID of the workflow template to use |
-| `-w, --workflow-name` | Name for the new workflow          |
+| Flag                  | Description                                                                                                                               |
+| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
+| `--non-interactive`   | Fail instead of prompting; supply all inputs via flags (for **CI/CD** and non-TTY environments).                                          |
+| `-p, --project-name`  | Name for the new project (required for a new project when using `--non-interactive`).                                                     |
+| `-t, --template`      | Template name to use (for example `hello-world-ts`). Run `cre templates list` to see IDs and required networks.                           |
+| `-w, --workflow-name` | Name for the new workflow.                                                                                                                |
+| `--refresh`           | Bypass the template cache and fetch fresh data from GitHub.                                                                               |
+| `--rpc-url`           | RPC endpoint for a chain, repeatable. Format: `chain-name=url`. Often **required** with `--non-interactive` when the template needs RPCs. |
+
+Inherited [global flags](/cre/reference/cli#global-flags) include **`-R, --project-root`**, which `cre init` uses as the directory where the project is created when you pass it explicitly.
 
 **Interactive mode (recommended):**
 
@@ -14906,19 +14932,22 @@ Running `cre init` without flags starts an interactive setup that guides you thr
 cre init
 ```
 
-**Non-interactive mode:**
+**Non-interactive mode (scripting / CI):**
+
+Pass **`--non-interactive`** plus the flags your template needs. Use **`cre templates list`** (or **`cre templates list --json`**) to see **required networks** and choose **`--rpc-url`** values.
 
 ```bash
-# Create a new project with initial workflow
 cre init \
+  --non-interactive \
   --project-name my-cre-project \
   --workflow-name my-workflow \
-  --template-id 1
+  --template hello-world-ts \
+  --rpc-url sepolia=https://sepolia.infura.io/v3/YOUR_KEY
 ```
 
+
 <Aside type="note" title="Interactive vs. non-interactive">
-  For most users, running `cre init` without flags (interactive mode) is the easiest way to set up a project. The CLI
-  will guide you through the setup process with clear prompts.
+  For most users, `cre init` without flags is easiest. With **`--non-interactive`**, the CLI does not prompt; if RPC URLs are required and there is no TTY, you get a clear error—pass the needed **`--rpc-url`** flags up front.
 </Aside>
 
 For a detailed walkthrough, see [Part 1 of the Getting Started guide](/cre/getting-started/part-1-project-setup).
diff --git a/src/content/cre/reference/cli/index.mdx b/src/content/cre/reference/cli/index.mdx
index fcfcaf1aea4..53928dd0fff 100644
--- a/src/content/cre/reference/cli/index.mdx
+++ b/src/content/cre/reference/cli/index.mdx
@@ -49,7 +49,7 @@ Manage your authentication and account credentials.
 
 Initialize projects and generate contract bindings (Go only).
 
-- **`cre init`** — Initialize a new CRE project with an interactive setup guide
+- [**`cre init`**](/cre/reference/cli/project-setup) — Initialize a new CRE project (interactive wizard or **`--non-interactive`** with flags for CI/CD)
 - **`cre generate-bindings`** (Go only) — Generate Go bindings from contract ABI files for type-safe contract interactions
 
 [View project setup commands →](/cre/reference/cli/project-setup)
@@ -103,7 +103,7 @@ Manage secrets stored in the Vault DON for use in your workflows.
 
 Manage the GitHub repositories that `cre init` uses to discover templates.
 
-- **`cre templates list`** — List all templates available from configured sources
+- **`cre templates list`** — List templates (human output includes required networks; **`--json`** for scripts)
 - **`cre templates add`** — Add a custom or third-party template repository
 - **`cre templates remove`** — Remove a template repository source
 
diff --git a/src/content/cre/reference/cli/project-setup-go.mdx b/src/content/cre/reference/cli/project-setup-go.mdx
index fff6be07113..3f030dfcbd2 100644
--- a/src/content/cre/reference/cli/project-setup-go.mdx
+++ b/src/content/cre/reference/cli/project-setup-go.mdx
@@ -7,7 +7,7 @@ pageId: "cli-project-setup"
 metadata:
   description: "Initialize Go projects with CLI: complete reference for cre init and generate-bindings commands to start building workflows."
   datePublished: "2025-11-04"
-  lastModified: "2026-03-17"
+  lastModified: "2026-03-26"
 ---
 
 import { Aside } from "@components"
@@ -40,11 +40,16 @@ cre init [flags]
 
 **Flags:**
 
-| Flag                  | Description                        |
-| --------------------- | ---------------------------------- |
-| `-p, --project-name`  | Name for the new project           |
-| `-t, --template-id`   | ID of the workflow template to use |
-| `-w, --workflow-name` | Name for the new workflow          |
+| Flag                  | Description                                                                                                                               |
+| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
+| `--non-interactive`   | Fail instead of prompting; supply all inputs via flags (for **CI/CD** and non-TTY environments).                                          |
+| `-p, --project-name`  | Name for the new project (required for a new project when using `--non-interactive`).                                                     |
+| `-t, --template`      | Template name to use (for example `hello-world-go`). Run `cre templates list` to see IDs and required networks.                           |
+| `-w, --workflow-name` | Name for the new workflow.                                                                                                                |
+| `--refresh`           | Bypass the template cache and fetch fresh data from GitHub.                                                                               |
+| `--rpc-url`           | RPC endpoint for a chain, repeatable. Format: `chain-name=url`. Often **required** with `--non-interactive` when the template needs RPCs. |
+
+Inherited [global flags](/cre/reference/cli#global-flags) include **`-R, --project-root`**, which `cre init` uses as the directory where the project is created when you pass it explicitly.
 
 **Interactive mode (recommended):**
 
@@ -67,19 +72,22 @@ Running `cre init` without flags starts an interactive setup that guides you thr
 cre init
 ```
 
-**Non-interactive mode:**
+**Non-interactive mode (scripting / CI):**
+
+Pass **`--non-interactive`** plus the flags your template needs. Use **`cre templates list`** (or **`cre templates list --json`**) to see **required networks** and choose **`--rpc-url`** values.
 
 ```bash
-# Create a new project with initial workflow
 cre init \
+  --non-interactive \
   --project-name my-cre-project \
   --workflow-name my-workflow \
-  --template-id 1
+  --template hello-world-go \
+  --rpc-url sepolia=https://sepolia.infura.io/v3/YOUR_KEY
 ```
 
+{/* prettier-ignore */}
 <Aside type="note" title="Interactive vs. non-interactive">
-  For most users, running `cre init` without flags (interactive mode) is the easiest way to set up a project. The CLI
-  will guide you through the setup process with clear prompts.
+  For most users, `cre init` without flags is easiest. With **`--non-interactive`**, the CLI does not prompt; if RPC URLs are required and there is no TTY, you get a clear error—pass the needed **`--rpc-url`** flags up front.
 </Aside>
 
 For a detailed walkthrough, see [Part 1 of the Getting Started guide](/cre/getting-started/part-1-project-setup).
diff --git a/src/content/cre/reference/cli/project-setup-ts.mdx b/src/content/cre/reference/cli/project-setup-ts.mdx
index 7421dbbea84..88a5e9fb0fb 100644
--- a/src/content/cre/reference/cli/project-setup-ts.mdx
+++ b/src/content/cre/reference/cli/project-setup-ts.mdx
@@ -7,7 +7,7 @@ pageId: "cli-project-setup"
 metadata:
   description: "Initialize TypeScript projects with CLI: complete reference for cre init command to start building workflows."
   datePublished: "2025-11-04"
-  lastModified: "2026-02-26"
+  lastModified: "2026-03-26"
 ---
 
 import { Aside } from "@components"
@@ -40,11 +40,16 @@ cre init [flags]
 
 **Flags:**
 
-| Flag                  | Description                        |
-| --------------------- | ---------------------------------- |
-| `-p, --project-name`  | Name for the new project           |
-| `-t, --template-id`   | ID of the workflow template to use |
-| `-w, --workflow-name` | Name for the new workflow          |
+| Flag                  | Description                                                                                                                               |
+| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
+| `--non-interactive`   | Fail instead of prompting; supply all inputs via flags (for **CI/CD** and non-TTY environments).                                          |
+| `-p, --project-name`  | Name for the new project (required for a new project when using `--non-interactive`).                                                     |
+| `-t, --template`      | Template name to use (for example `hello-world-ts`). Run `cre templates list` to see IDs and required networks.                           |
+| `-w, --workflow-name` | Name for the new workflow.                                                                                                                |
+| `--refresh`           | Bypass the template cache and fetch fresh data from GitHub.                                                                               |
+| `--rpc-url`           | RPC endpoint for a chain, repeatable. Format: `chain-name=url`. Often **required** with `--non-interactive` when the template needs RPCs. |
+
+Inherited [global flags](/cre/reference/cli#global-flags) include **`-R, --project-root`**, which `cre init` uses as the directory where the project is created when you pass it explicitly.
 
 **Interactive mode (recommended):**
 
@@ -67,19 +72,22 @@ Running `cre init` without flags starts an interactive setup that guides you thr
 cre init
 ```
 
-**Non-interactive mode:**
+**Non-interactive mode (scripting / CI):**
+
+Pass **`--non-interactive`** plus the flags your template needs. Use **`cre templates list`** (or **`cre templates list --json`**) to see **required networks** and choose **`--rpc-url`** values.
 
 ```bash
-# Create a new project with initial workflow
 cre init \
+  --non-interactive \
   --project-name my-cre-project \
   --workflow-name my-workflow \
-  --template-id 1
+  --template hello-world-ts \
+  --rpc-url sepolia=https://sepolia.infura.io/v3/YOUR_KEY
 ```
 
+{/* prettier-ignore */}
 <Aside type="note" title="Interactive vs. non-interactive">
-  For most users, running `cre init` without flags (interactive mode) is the easiest way to set up a project. The CLI
-  will guide you through the setup process with clear prompts.
+  For most users, `cre init` without flags is easiest. With **`--non-interactive`**, the CLI does not prompt; if RPC URLs are required and there is no TTY, you get a clear error—pass the needed **`--rpc-url`** flags up front.
 </Aside>
 
 For a detailed walkthrough, see [Part 1 of the Getting Started guide](/cre/getting-started/part-1-project-setup).
diff --git a/src/content/cre/reference/cli/templates.mdx b/src/content/cre/reference/cli/templates.mdx
index 4cb179050cb..729a24bebd6 100644
--- a/src/content/cre/reference/cli/templates.mdx
+++ b/src/content/cre/reference/cli/templates.mdx
@@ -5,7 +5,7 @@ title: "Template Sources"
 metadata:
   description: "Manage the GitHub repository sources that cre init uses to discover workflow templates."
   datePublished: "2026-02-26"
-  lastModified: "2026-02-26"
+  lastModified: "2026-03-26"
 ---
 
 import { Aside } from "@components"
@@ -31,11 +31,12 @@ cre templates list [flags]
 
 **Flags:**
 
-| Flag        | Description                                             |
-| ----------- | ------------------------------------------------------- |
-| `--refresh` | Bypass the local cache and fetch fresh data from GitHub |
+| Flag        | Description                                               |
+| ----------- | --------------------------------------------------------- |
+| `--json`    | Print the template list as **JSON** (for scripts and CI). |
+| `--refresh` | Bypass the local cache and fetch fresh data from GitHub   |
 
-Each entry shows the template title, ID, language, and a short description. Use the ID with `cre init --template=<id>` to scaffold a project from that template.
+Each entry shows the template title, ID, language, a short description, and **required networks** (chains you must supply RPCs for when using `cre init`, especially with **`--non-interactive`**). Use the template name with **`cre init --template=<name>`** to scaffold a project.
 
 For the current list of available templates, run `cre templates list` or visit [docs.chain.link/cre-templates](https://docs.chain.link/cre-templates).
 
diff --git a/src/content/cre/release-notes.mdx b/src/content/cre/release-notes.mdx
index 4af6d554734..700b2edff34 100644
--- a/src/content/cre/release-notes.mdx
+++ b/src/content/cre/release-notes.mdx
@@ -5,13 +5,28 @@ date: Last Modified
 metadata:
   description: "Discover what's new in CRE: latest features, changes, and improvements in each release of the Chainlink Runtime Environment."
   datePublished: "2025-11-04"
-  lastModified: "2026-03-23"
+  lastModified: "2026-03-26"
 ---
 
 import { Aside } from "@components"
 
 This page provides detailed release notes for CRE. It includes information on new features, significant changes, and known limitations.
 
+## CLI v1.8.0 - March 26, 2026
+
+**<a href="https://github.com/smartcontractkit/cre-cli/releases/tag/v1.8.0" target="_blank">CRE CLI version 1.8.0</a> is now available.**
+
+- **Tenant context cache**: The [**Authentication**](/cre/reference/cli/authentication#tenant-context-cache) reference documents **`~/.cre/context.yaml`**, which the CLI updates after login so your local session reflects the platform’s registry manifest.
+- **Scriptable `cre init`**: [**Project setup**](/cre/reference/cli/project-setup) covers **`cre init --non-interactive`** and related flags for CI and automation without prompts.
+- **`cre templates list --json`**: Use [**Template sources**](/cre/reference/cli/templates) for **`--json`** output when you need machine-readable template listings in scripts.
+
+**How to update:**
+
+- **Automatic update**: When you run any CRE command, the CLI will automatically detect if a newer version is available and prompt you to update. Simply run `cre update` to install the latest version.
+- **Fresh installation**: If you're installing the CLI for the first time, follow the [CLI Installation guide](/cre/getting-started/cli-installation).
+
+[See all changes on GitHub](https://github.com/smartcontractkit/cre-cli/compare/v1.7.0...v1.8.0)
+
 ## CLI v1.7.0 - March 23, 2026
 
 **<a href="https://github.com/smartcontractkit/cre-cli/releases/tag/v1.7.0" target="_blank">CRE CLI version 1.7.0</a> is now available.**

From 7dde749bc4b65c765489145535a222bb41f1a8b9 Mon Sep 17 00:00:00 2001
From: devin distefano <devin.distefano@smartcontract.com>
Date: Thu, 26 Mar 2026 16:36:11 -0500
Subject: [PATCH 4/4] added warnings about confidential http request + secrets

---
 .../cre/capabilities/confidential-http-go.mdx |  7 +++
 .../cre/capabilities/confidential-http-ts.mdx |  7 +++
 .../using-confidential-http-client/index.mdx  |  6 +-
 .../making-requests-go.mdx                    | 14 +++--
 .../making-requests-ts.mdx                    | 38 +++--------
 src/content/cre/llms-full-go.txt              | 37 +++++++----
 src/content/cre/llms-full-ts.txt              | 63 ++++++++-----------
 .../sdk/confidential-http-client-go.mdx       | 12 ++--
 .../sdk/confidential-http-client-ts.mdx       | 12 ++--
 9 files changed, 102 insertions(+), 94 deletions(-)

diff --git a/src/content/cre/capabilities/confidential-http-go.mdx b/src/content/cre/capabilities/confidential-http-go.mdx
index 5d076d7a06d..035eb01916f 100644
--- a/src/content/cre/capabilities/confidential-http-go.mdx
+++ b/src/content/cre/capabilities/confidential-http-go.mdx
@@ -47,6 +47,13 @@ This approach ensures:
 | **Request body**               | Template-based injection: secrets referenced in the request body (e.g., `{{.myApiKey}}`) are resolved inside the enclave, so sensitive values never appear in workflow memory. |
 | **Response body**              | Optionally encrypted. When `EncryptOutput` is enabled, the full response is [AES-GCM](https://en.wikipedia.org/wiki/Galois/Counter_Mode) encrypted before leaving the enclave. |
 
+<Aside type="caution" title="Do not inject sensitive values into the request as plain workflow strings">
+  **Credentials:** List sensitive values in **`VaultDonSecrets`** and reference them only with **`{{.key}}` placeholders**. Secrets read via **`runtime.GetSecret()`** (or any string you build in workflow code) and pasted into headers or body are handled in **Workflow DON** execution, not enclave-only. See [Making Confidential Requests (Go)](/cre/guides/workflow/using-confidential-http-client/making-requests-go#step-4-implement-the-request-logic).
+
+**Scope:** The enclave executes the **outbound HTTP request** and template resolution—not arbitrary workflow logic. Using `confidentialhttp.Client` does not make the rest of your workflow confidential compute.
+
+</Aside>
+
 ## Use cases
 
 ### Credential isolation
diff --git a/src/content/cre/capabilities/confidential-http-ts.mdx b/src/content/cre/capabilities/confidential-http-ts.mdx
index b8f3f64a68f..f895d364484 100644
--- a/src/content/cre/capabilities/confidential-http-ts.mdx
+++ b/src/content/cre/capabilities/confidential-http-ts.mdx
@@ -47,6 +47,13 @@ This approach ensures:
 | **Request body**               | Template-based injection: secrets referenced in the request body (e.g., `{{.myApiKey}}`) are resolved inside the enclave, so sensitive values never appear in workflow memory. |
 | **Response body**              | Optionally encrypted. When `EncryptOutput` is enabled, the full response is [AES-GCM](https://en.wikipedia.org/wiki/Galois/Counter_Mode) encrypted before leaving the enclave. |
 
+<Aside type="caution" title="Do not inject sensitive values into the request as plain workflow strings">
+  **Credentials:** List sensitive values in **`vaultDonSecrets`** and reference them only with **`{{.key}}` placeholders**. Secrets read via **`runtime.getSecret()`** (or any string you build in workflow code) and pasted into headers or body are handled in **Workflow DON** execution, not enclave-only. See [Making Confidential Requests (TypeScript)](/cre/guides/workflow/using-confidential-http-client/making-requests-ts#step-4-implement-the-request-and-wire-it-into-your-workflow).
+
+**Scope:** The enclave executes the **outbound HTTP request** and template resolution—not arbitrary workflow logic. Using `ConfidentialHTTPClient` does not make the rest of your workflow confidential compute.
+
+</Aside>
+
 ## Use cases
 
 ### Credential isolation
diff --git a/src/content/cre/guides/workflow/using-confidential-http-client/index.mdx b/src/content/cre/guides/workflow/using-confidential-http-client/index.mdx
index 8145a6afa1f..82c64454be4 100644
--- a/src/content/cre/guides/workflow/using-confidential-http-client/index.mdx
+++ b/src/content/cre/guides/workflow/using-confidential-http-client/index.mdx
@@ -13,7 +13,11 @@ import { Aside } from "@components"
 
 The CRE SDK provides a Confidential HTTP client that allows your workflows to interact with external APIs while keeping sensitive data private. Requests execute inside a secure enclave, secrets are injected via templates, and responses can optionally be encrypted.
 
-For a conceptual overview of what Confidential HTTP is and how it differs from the regular HTTP capability, see [The Confidential HTTP Capability](/cre/capabilities/confidential-http).
+<Aside type="caution" title="Read this before putting sensitive data in Confidential HTTP requests">
+  **Confidential HTTP does not automatically protect credentials you load with `runtime.getSecret()` / `runtime.GetSecret()`** and then paste into headers or body as plaintext. For Vault DON–style isolation, use **`vaultDonSecrets` / `VaultDonSecrets`** and **`{{.key}}` templates** only. The step-by-step guide below explains the correct pattern and common mistakes.
+</Aside>
+
+For **why** you might need Confidential HTTP—what stays off Workflow DON nodes, and [when to use it vs. regular HTTP](/cre/capabilities/confidential-http#when-to-use-confidential-http-vs-regular-http)—see [The Confidential HTTP capability](/cre/capabilities/confidential-http#whats-kept-confidential).
 
 ## Guides
 
diff --git a/src/content/cre/guides/workflow/using-confidential-http-client/making-requests-go.mdx b/src/content/cre/guides/workflow/using-confidential-http-client/making-requests-go.mdx
index e72fbccb64e..3bc662f8ba8 100644
--- a/src/content/cre/guides/workflow/using-confidential-http-client/making-requests-go.mdx
+++ b/src/content/cre/guides/workflow/using-confidential-http-client/making-requests-go.mdx
@@ -12,12 +12,12 @@ metadata:
 
 import { Aside } from "@components"
 
-The `confidentialhttp.Client` is the SDK's interface for the underlying [Confidential HTTP Capability](/cre/capabilities/confidential-http). It allows your workflow to make privacy-preserving API calls where secrets are injected inside a secure enclave and responses can be optionally encrypted.
+`confidentialhttp.Client` implements the [Confidential HTTP capability](/cre/capabilities/confidential-http-go). Use it when an outbound call should carry [sensitive credentials or request fields](/cre/capabilities/confidential-http-go#whats-kept-confidential) without assembling them as plain strings in workflow code on every node—see [when to use Confidential vs. regular HTTP](/cre/capabilities/confidential-http-go#when-to-use-confidential-http-vs-regular-http). For those values, use **`VaultDonSecrets`** with **`{{.key}}`** placeholders only; **`runtime.GetSecret()`** in headers or body follows a different trust boundary.
 
 Unlike the regular [`http.Client`](/cre/reference/sdk/http-client), the Confidential HTTP client:
 
 - Executes the request in a secure **enclave** (not on each node individually)
-- Injects secrets from the **Vault DON** using template syntax
+- Resolves **`VaultDonSecrets`** into the request via **Vault DON** template syntax
 - Optionally **encrypts the response** before returning it to your workflow
 
 ## Prerequisites
@@ -139,9 +139,11 @@ func makeConfidentialRequest(config Config, runtime cre.Runtime) (Result, error)
 }
 ```
 
-<Aside type="note" title="Alphabetic secret ordering required">
-  When using multiple secrets, pass them into `VaultDonSecrets` in alphabetical order by key. The Vault DON processes
-  secrets in a canonical order to ensure consistent behavior across nodes during execution.
+<Aside type="caution" title="Do not assemble sensitive request data in workflow code">
+  Register API credentials in the Vault DON, add them to **`VaultDonSecrets`**, and reference them **only** with **`{{.key}}` placeholders** in headers or body—not with plaintext from **`runtime.GetSecret()`** or other workflow-built strings (those run in **Workflow DON** execution on every node). See [Using secrets with deployed workflows](/cre/guides/workflow/secrets/using-secrets-deployed).
+
+With **multiple** secrets, list **`VaultDonSecrets`** keys in **alphabetical order** (Vault DON canonical ordering).
+
 </Aside>
 
 ### Step 5: Wire it into your workflow
@@ -188,7 +190,7 @@ headers := map[string]*confidentialhttp.HeaderValues{
 }
 ```
 
-The template placeholders are resolved inside the enclave. The actual secret values never appear in your workflow code or in node memory.
+The template placeholders are resolved inside the enclave. The actual secret values never appear in your workflow code or in node memory. Credentials must be wired through **`VaultDonSecrets`** as in Step 4—not interpolated from **`runtime.GetSecret()`**.
 
 ## Response encryption
 
diff --git a/src/content/cre/guides/workflow/using-confidential-http-client/making-requests-ts.mdx b/src/content/cre/guides/workflow/using-confidential-http-client/making-requests-ts.mdx
index 8326dee76a8..dfc714bd00c 100644
--- a/src/content/cre/guides/workflow/using-confidential-http-client/making-requests-ts.mdx
+++ b/src/content/cre/guides/workflow/using-confidential-http-client/making-requests-ts.mdx
@@ -12,12 +12,12 @@ metadata:
 
 import { Aside } from "@components"
 
-The `ConfidentialHTTPClient` is the SDK's interface for the underlying [Confidential HTTP Capability](/cre/capabilities/confidential-http). It allows your workflow to make privacy-preserving API calls where secrets are injected inside a secure enclave and responses can be optionally encrypted.
+`ConfidentialHTTPClient` implements the [Confidential HTTP capability](/cre/capabilities/confidential-http-ts). Use it when an outbound call should carry [sensitive credentials or request fields](/cre/capabilities/confidential-http-ts#whats-kept-confidential) without assembling them as plain strings in workflow code on every node—see [when to use Confidential vs. regular HTTP](/cre/capabilities/confidential-http-ts#when-to-use-confidential-http-vs-regular-http). For those values, use **`vaultDonSecrets`** with **`{{.key}}`** placeholders only; **`runtime.getSecret()`** in headers or body follows a different trust boundary.
 
 Unlike the regular [`HTTPClient`](/cre/reference/sdk/http-client), the Confidential HTTP client:
 
 - Executes the request in a secure **enclave** (not on each node individually)
-- Injects secrets from the **Vault DON** using template syntax
+- Resolves **`vaultDonSecrets`** into the request via **Vault DON** template syntax
 - Optionally **encrypts the response** before returning it to your workflow
 
 ## Prerequisites
@@ -121,36 +121,12 @@ const onCronTrigger = (runtime: Runtime<Config>): TransactionResult => {
 }
 ```
 
-<Aside type="note" title="Alphabetic secret ordering required">
-  When using multiple secrets, pass them into `vaultDonSecrets` in alphabetical order by key. The Vault DON processes
-  secrets in a canonical order to ensure consistent behavior across nodes during execution.
-</Aside>
-
-In your trigger handler, call `confHTTPClient.sendRequest()` with your fetch function and a consensus method:
-
-```typescript
-import {
-  CronCapability,
-  ConfidentialHTTPClient,
-  handler,
-  consensusIdenticalAggregation,
-  type Runtime,
-  Runner,
-} from "@chainlink/cre-sdk"
-
-const onCronTrigger = (runtime: Runtime<Config>): string => {
-  const confHTTPClient = new ConfidentialHTTPClient()
+<Aside type="caution" title="Do not assemble sensitive request data in workflow code">
+  Register API credentials in the Vault DON, add them to **`vaultDonSecrets`**, and reference them **only** with **`{{.key}}` placeholders** in headers or body—not with plaintext from **`runtime.getSecret()`** or other workflow-built strings (those run in **Workflow DON** execution on every node). See [Using secrets with deployed workflows](/cre/guides/workflow/secrets/using-secrets-deployed).
 
-  const result = confHTTPClient
-    .sendRequest(runtime, fetchTransaction, consensusIdenticalAggregation<TransactionResult>())(runtime.config)
-    .result()
+With **multiple** secrets, list **`vaultDonSecrets`** keys in **alphabetical order** (Vault DON canonical ordering).
 
-=======
-  const result = json(response) as TransactionResult
-  runtime.log(`Transaction result: ${result.transactionId} — ${result.status}`)
-  return result
-}
-```
+</Aside>
 
 ### Step 5: Simulate
 
@@ -178,7 +154,7 @@ multiHeaders: {
 }
 ```
 
-The template placeholders are resolved inside the enclave. The actual secret values never appear in your workflow code or in node memory.
+The template placeholders are resolved inside the enclave. The actual secret values never appear in your workflow code or in node memory. Credentials must be wired through **`vaultDonSecrets`** as in Step 4—not interpolated from **`runtime.getSecret()`**.
 
 ## Response encryption
 
diff --git a/src/content/cre/llms-full-go.txt b/src/content/cre/llms-full-go.txt
index e24b7df4af0..6db54550e53 100644
--- a/src/content/cre/llms-full-go.txt
+++ b/src/content/cre/llms-full-go.txt
@@ -4335,7 +4335,11 @@ Last Updated: 2026-02-06
 
 The CRE SDK provides a Confidential HTTP client that allows your workflows to interact with external APIs while keeping sensitive data private. Requests execute inside a secure enclave, secrets are injected via templates, and responses can optionally be encrypted.
 
-For a conceptual overview of what Confidential HTTP is and how it differs from the regular HTTP capability, see [The Confidential HTTP Capability](/cre/capabilities/confidential-http).
+<Aside type="caution" title="Read this before putting sensitive data in Confidential HTTP requests">
+  **Confidential HTTP does not automatically protect credentials you load with `runtime.getSecret()` / `runtime.GetSecret()`** and then paste into headers or body as plaintext. For Vault DON–style isolation, use **`vaultDonSecrets` / `VaultDonSecrets`** and **`{{.key}}` templates** only. The step-by-step guide below explains the correct pattern and common mistakes.
+</Aside>
+
+For **why** you might need Confidential HTTP—what stays off Workflow DON nodes, and [when to use it vs. regular HTTP](/cre/capabilities/confidential-http#when-to-use-confidential-http-vs-regular-http)—see [The Confidential HTTP capability](/cre/capabilities/confidential-http#whats-kept-confidential).
 
 ## Guides
 
@@ -9465,6 +9469,12 @@ This approach ensures:
 | **Request body**               | Template-based injection: secrets referenced in the request body (e.g., `{{.myApiKey}}`) are resolved inside the enclave, so sensitive values never appear in workflow memory. |
 | **Response body**              | Optionally encrypted. When `EncryptOutput` is enabled, the full response is [AES-GCM](https://en.wikipedia.org/wiki/Galois/Counter_Mode) encrypted before leaving the enclave. |
 
+<Aside type="caution" title="Do not inject sensitive values into the request as plain workflow strings">
+  **Credentials:** List sensitive values in **`VaultDonSecrets`** and reference them only with **`{{.key}}` placeholders**. Secrets read via **`runtime.GetSecret()`** (or any string you build in workflow code) and pasted into headers or body are handled in **Workflow DON** execution, not enclave-only. See [Making Confidential Requests (Go)](/cre/guides/workflow/using-confidential-http-client/making-requests-go#step-4-implement-the-request-logic).
+
+  **Scope:** The enclave executes the **outbound HTTP request** and template resolution—not arbitrary workflow logic. Using `confidentialhttp.Client` does not make the rest of your workflow confidential compute.
+</Aside>
+
 ## Use cases
 
 ### Credential isolation
@@ -11634,12 +11644,12 @@ New DON timestamps are produced continuously (multiple per second). Treat it as
 Source: https://docs.chain.link/cre/guides/workflow/using-confidential-http-client/making-requests-go
 Last Updated: 2026-02-10
 
-The `confidentialhttp.Client` is the SDK's interface for the underlying [Confidential HTTP Capability](/cre/capabilities/confidential-http). It allows your workflow to make privacy-preserving API calls where secrets are injected inside a secure enclave and responses can be optionally encrypted.
+`confidentialhttp.Client` implements the [Confidential HTTP capability](/cre/capabilities/confidential-http-go). Use it when an outbound call should carry [sensitive credentials or request fields](/cre/capabilities/confidential-http-go#whats-kept-confidential) without assembling them as plain strings in workflow code on every node—see [when to use Confidential vs. regular HTTP](/cre/capabilities/confidential-http-go#when-to-use-confidential-http-vs-regular-http). For those values, use **`VaultDonSecrets`** with **`{{.key}}`** placeholders only; **`runtime.GetSecret()`** in headers or body follows a different trust boundary.
 
 Unlike the regular [`http.Client`](/cre/reference/sdk/http-client), the Confidential HTTP client:
 
 - Executes the request in a secure **enclave** (not on each node individually)
-- Injects secrets from the **Vault DON** using template syntax
+- Resolves **`VaultDonSecrets`** into the request via **Vault DON** template syntax
 - Optionally **encrypts the response** before returning it to your workflow
 
 ## Prerequisites
@@ -11761,9 +11771,10 @@ func makeConfidentialRequest(config Config, runtime cre.Runtime) (Result, error)
 }
 ```
 
-<Aside type="note" title="Alphabetic secret ordering required">
-  When using multiple secrets, pass them into `VaultDonSecrets` in alphabetical order by key. The Vault DON processes
-  secrets in a canonical order to ensure consistent behavior across nodes during execution.
+<Aside type="caution" title="Do not assemble sensitive request data in workflow code">
+  Register API credentials in the Vault DON, add them to **`VaultDonSecrets`**, and reference them **only** with **`{{.key}}` placeholders** in headers or body—not with plaintext from **`runtime.GetSecret()`** or other workflow-built strings (those run in **Workflow DON** execution on every node). See [Using secrets with deployed workflows](/cre/guides/workflow/secrets/using-secrets-deployed).
+
+  With **multiple** secrets, list **`VaultDonSecrets`** keys in **alphabetical order** (Vault DON canonical ordering).
 </Aside>
 
 ### Step 5: Wire it into your workflow
@@ -11810,7 +11821,7 @@ headers := map[string]*confidentialhttp.HeaderValues{
 }
 ```
 
-The template placeholders are resolved inside the enclave. The actual secret values never appear in your workflow code or in node memory.
+The template placeholders are resolved inside the enclave. The actual secret values never appear in your workflow code or in node memory. Credentials must be wired through **`VaultDonSecrets`** as in Step 4—not interpolated from **`runtime.GetSecret()`**.
 
 ## Response encryption
 
@@ -15994,6 +16005,10 @@ The [Confidential HTTP](/cre/capabilities/confidential-http-go) Client lets you
 - For use cases and a conceptual overview, see [The Confidential HTTP Capability](/cre/capabilities/confidential-http-go)
 - **Guide:** [Making Confidential Requests](/cre/guides/workflow/using-confidential-http-client/making-requests-go)
 
+<Aside type="caution" title="Do not assume sensitive values are always enclave-resolved">
+  **Credential isolation** applies when sensitive values are listed in **`VaultDonSecrets`** and referenced only with **`{{.secretName}}` placeholders**, so plaintext is resolved inside the enclave. Values you interpolate into headers or body as ordinary workflow strings—including from **`runtime.GetSecret()`** and similar APIs—are resolved in **Workflow DON** execution and follow a different trust boundary. See [Making Confidential Requests](/cre/guides/workflow/using-confidential-http-client/making-requests-go#step-4-implement-the-request-logic) for the intended pattern.
+</Aside>
+
 ## Quick reference
 
 | Method                                     | Description                        |
@@ -16006,10 +16021,10 @@ The [Confidential HTTP](/cre/capabilities/confidential-http-go) Client lets you
 
 The top-level request type that combines an HTTP request with Vault DON secrets and encryption settings.
 
-| Field             | Type                  | Description                                                                                                                                 |
-| ----------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
-| `Request`         | `*HTTPRequest`        | The HTTP request to execute inside the enclave. See [`HTTPRequest`](#confidentialhttphttprequest).                                          |
-| `VaultDonSecrets` | `[]*SecretIdentifier` | List of secrets to fetch from the Vault DON and make available in the enclave. See [`SecretIdentifier`](#confidentialhttpsecretidentifier). |
+| Field             | Type                  | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          |
+| ----------------- | --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Request`         | `*HTTPRequest`        | The HTTP request to execute inside the enclave. See [`HTTPRequest`](#confidentialhttphttprequest).                                                                                                                                                                                                                                                                                                                                                                                                                                                                   |
+| `VaultDonSecrets` | `[]*SecretIdentifier` | Vault DON secrets for enclave-only `{{.key}}` substitution in the request ([`SecretIdentifier`](#confidentialhttpsecretidentifier)). Use this when credentials or other sensitive template values must stay out of Workflow DON execution—not replaceable by pasting `runtime.GetSecret()` output into headers or body. See [what stays confidential](/cre/capabilities/confidential-http-go#whats-kept-confidential) and [Making Confidential Requests](/cre/guides/workflow/using-confidential-http-client/making-requests-go#step-4-implement-the-request-logic). |
 
 ### `confidentialhttp.HTTPRequest`
 
diff --git a/src/content/cre/llms-full-ts.txt b/src/content/cre/llms-full-ts.txt
index 48c2956a852..369a52c6b04 100644
--- a/src/content/cre/llms-full-ts.txt
+++ b/src/content/cre/llms-full-ts.txt
@@ -3671,7 +3671,11 @@ Last Updated: 2026-02-06
 
 The CRE SDK provides a Confidential HTTP client that allows your workflows to interact with external APIs while keeping sensitive data private. Requests execute inside a secure enclave, secrets are injected via templates, and responses can optionally be encrypted.
 
-For a conceptual overview of what Confidential HTTP is and how it differs from the regular HTTP capability, see [The Confidential HTTP Capability](/cre/capabilities/confidential-http).
+<Aside type="caution" title="Read this before putting sensitive data in Confidential HTTP requests">
+  **Confidential HTTP does not automatically protect credentials you load with `runtime.getSecret()` / `runtime.GetSecret()`** and then paste into headers or body as plaintext. For Vault DON–style isolation, use **`vaultDonSecrets` / `VaultDonSecrets`** and **`{{.key}}` templates** only. The step-by-step guide below explains the correct pattern and common mistakes.
+</Aside>
+
+For **why** you might need Confidential HTTP—what stays off Workflow DON nodes, and [when to use it vs. regular HTTP](/cre/capabilities/confidential-http#when-to-use-confidential-http-vs-regular-http)—see [The Confidential HTTP capability](/cre/capabilities/confidential-http#whats-kept-confidential).
 
 ## Guides
 
@@ -8772,6 +8776,12 @@ This approach ensures:
 | **Request body**               | Template-based injection: secrets referenced in the request body (e.g., `{{.myApiKey}}`) are resolved inside the enclave, so sensitive values never appear in workflow memory. |
 | **Response body**              | Optionally encrypted. When `EncryptOutput` is enabled, the full response is [AES-GCM](https://en.wikipedia.org/wiki/Galois/Counter_Mode) encrypted before leaving the enclave. |
 
+<Aside type="caution" title="Do not inject sensitive values into the request as plain workflow strings">
+  **Credentials:** List sensitive values in **`vaultDonSecrets`** and reference them only with **`{{.key}}` placeholders**. Secrets read via **`runtime.getSecret()`** (or any string you build in workflow code) and pasted into headers or body are handled in **Workflow DON** execution, not enclave-only. See [Making Confidential Requests (TypeScript)](/cre/guides/workflow/using-confidential-http-client/making-requests-ts#step-4-implement-the-request-and-wire-it-into-your-workflow).
+
+  **Scope:** The enclave executes the **outbound HTTP request** and template resolution—not arbitrary workflow logic. Using `ConfidentialHTTPClient` does not make the rest of your workflow confidential compute.
+</Aside>
+
 ## Use cases
 
 ### Credential isolation
@@ -11110,12 +11120,12 @@ New DON timestamps are produced continuously (multiple per second). Treat it as
 Source: https://docs.chain.link/cre/guides/workflow/using-confidential-http-client/making-requests-ts
 Last Updated: 2026-02-10
 
-The `ConfidentialHTTPClient` is the SDK's interface for the underlying [Confidential HTTP Capability](/cre/capabilities/confidential-http). It allows your workflow to make privacy-preserving API calls where secrets are injected inside a secure enclave and responses can be optionally encrypted.
+`ConfidentialHTTPClient` implements the [Confidential HTTP capability](/cre/capabilities/confidential-http-ts). Use it when an outbound call should carry [sensitive credentials or request fields](/cre/capabilities/confidential-http-ts#whats-kept-confidential) without assembling them as plain strings in workflow code on every node—see [when to use Confidential vs. regular HTTP](/cre/capabilities/confidential-http-ts#when-to-use-confidential-http-vs-regular-http). For those values, use **`vaultDonSecrets`** with **`{{.key}}`** placeholders only; **`runtime.getSecret()`** in headers or body follows a different trust boundary.
 
 Unlike the regular [`HTTPClient`](/cre/reference/sdk/http-client), the Confidential HTTP client:
 
 - Executes the request in a secure **enclave** (not on each node individually)
-- Injects secrets from the **Vault DON** using template syntax
+- Resolves **`vaultDonSecrets`** into the request via **Vault DON** template syntax
 - Optionally **encrypts the response** before returning it to your workflow
 
 ## Prerequisites
@@ -11219,36 +11229,11 @@ const onCronTrigger = (runtime: Runtime<Config>): TransactionResult => {
 }
 ```
 
-<Aside type="note" title="Alphabetic secret ordering required">
-  When using multiple secrets, pass them into `vaultDonSecrets` in alphabetical order by key. The Vault DON processes
-  secrets in a canonical order to ensure consistent behavior across nodes during execution.
-</Aside>
-
-In your trigger handler, call `confHTTPClient.sendRequest()` with your fetch function and a consensus method:
+<Aside type="caution" title="Do not assemble sensitive request data in workflow code">
+  Register API credentials in the Vault DON, add them to **`vaultDonSecrets`**, and reference them **only** with **`{{.key}}` placeholders** in headers or body—not with plaintext from **`runtime.getSecret()`** or other workflow-built strings (those run in **Workflow DON** execution on every node). See [Using secrets with deployed workflows](/cre/guides/workflow/secrets/using-secrets-deployed).
 
-```typescript
-import {
-  CronCapability,
-  ConfidentialHTTPClient,
-  handler,
-  consensusIdenticalAggregation,
-  type Runtime,
-  Runner,
-} from "@chainlink/cre-sdk"
-
-const onCronTrigger = (runtime: Runtime<Config>): string => {
-  const confHTTPClient = new ConfidentialHTTPClient()
-
-  const result = confHTTPClient
-    .sendRequest(runtime, fetchTransaction, consensusIdenticalAggregation<TransactionResult>())(runtime.config)
-    .result()
-
-=======
-  const result = json(response) as TransactionResult
-  runtime.log(`Transaction result: ${result.transactionId} — ${result.status}`)
-  return result
-}
-```
+  With **multiple** secrets, list **`vaultDonSecrets`** keys in **alphabetical order** (Vault DON canonical ordering).
+</Aside>
 
 ### Step 5: Simulate
 
@@ -11276,7 +11261,7 @@ multiHeaders: {
 }
 ```
 
-The template placeholders are resolved inside the enclave. The actual secret values never appear in your workflow code or in node memory.
+The template placeholders are resolved inside the enclave. The actual secret values never appear in your workflow code or in node memory. Credentials must be wired through **`vaultDonSecrets`** as in Step 4—not interpolated from **`runtime.getSecret()`**.
 
 ## Response encryption
 
@@ -15454,6 +15439,10 @@ The [Confidential HTTP](/cre/capabilities/confidential-http-ts) Client lets you
 - For use cases and a conceptual overview, see [The Confidential HTTP Capability](/cre/capabilities/confidential-http-ts)
 - **Guide:** [Making Confidential Requests](/cre/guides/workflow/using-confidential-http-client/making-requests-ts)
 
+<Aside type="caution" title="Do not assume sensitive values are always enclave-resolved">
+  **Credential isolation** applies when sensitive values are listed in **`vaultDonSecrets`** and referenced only with **`{{.secretName}}` placeholders**, so plaintext is resolved inside the enclave. Values you interpolate into headers or body as ordinary workflow strings—including from **`runtime.getSecret()`** and similar APIs—are resolved in **Workflow DON** execution and follow a different trust boundary. See [Making Confidential Requests](/cre/guides/workflow/using-confidential-http-client/making-requests-ts#step-4-implement-the-request-and-wire-it-into-your-workflow) for the intended pattern.
+</Aside>
+
 ## Quick reference
 
 | Method                        | Description                        |
@@ -15471,10 +15460,10 @@ The [Confidential HTTP](/cre/capabilities/confidential-http-ts) Client lets you
 
 The top-level request type that combines an HTTP request with Vault DON secrets and encryption settings.
 
-| Field             | Type                                             | Description                                                                                                                                       |
-| ----------------- | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `request`         | `HTTPRequest` \| `HTTPRequestJson`               | The HTTP request to execute inside the enclave. See [`HTTPRequest`](#httprequest--httprequestjson).                                               |
-| `vaultDonSecrets` | `SecretIdentifier[]` \| `SecretIdentifierJson[]` | List of secrets to fetch from the Vault DON and make available in the enclave. See [`SecretIdentifier`](#secretidentifier--secretidentifierjson). |
+| Field             | Type                                             | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
+| ----------------- | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `request`         | `HTTPRequest` \| `HTTPRequestJson`               | The HTTP request to execute inside the enclave. See [`HTTPRequest`](#httprequest--httprequestjson).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
+| `vaultDonSecrets` | `SecretIdentifier[]` \| `SecretIdentifierJson[]` | Vault DON secrets for enclave-only `{{.key}}` substitution in the request ([`SecretIdentifier`](#secretidentifier--secretidentifierjson)). Use this when credentials or other sensitive template values must stay out of Workflow DON execution—not replaceable by pasting `runtime.getSecret()` output into headers or body. See [what stays confidential](/cre/capabilities/confidential-http-ts#whats-kept-confidential) and [Making Confidential Requests](/cre/guides/workflow/using-confidential-http-client/making-requests-ts#step-4-implement-the-request-and-wire-it-into-your-workflow). |
 
 ### `HTTPRequest` / `HTTPRequestJson`
 
diff --git a/src/content/cre/reference/sdk/confidential-http-client-go.mdx b/src/content/cre/reference/sdk/confidential-http-client-go.mdx
index 967d655e7fa..1ffb88d6b3c 100644
--- a/src/content/cre/reference/sdk/confidential-http-client-go.mdx
+++ b/src/content/cre/reference/sdk/confidential-http-client-go.mdx
@@ -17,6 +17,10 @@ The [Confidential HTTP](/cre/capabilities/confidential-http-go) Client lets you
 - For use cases and a conceptual overview, see [The Confidential HTTP Capability](/cre/capabilities/confidential-http-go)
 - **Guide:** [Making Confidential Requests](/cre/guides/workflow/using-confidential-http-client/making-requests-go)
 
+<Aside type="caution" title="Do not assume sensitive values are always enclave-resolved">
+  **Credential isolation** applies when sensitive values are listed in **`VaultDonSecrets`** and referenced only with **`{{.secretName}}` placeholders**, so plaintext is resolved inside the enclave. Values you interpolate into headers or body as ordinary workflow strings—including from **`runtime.GetSecret()`** and similar APIs—are resolved in **Workflow DON** execution and follow a different trust boundary. See [Making Confidential Requests](/cre/guides/workflow/using-confidential-http-client/making-requests-go#step-4-implement-the-request-logic) for the intended pattern.
+</Aside>
+
 ## Quick reference
 
 | Method                                     | Description                        |
@@ -29,10 +33,10 @@ The [Confidential HTTP](/cre/capabilities/confidential-http-go) Client lets you
 
 The top-level request type that combines an HTTP request with Vault DON secrets and encryption settings.
 
-| <div style="width: 140px;">Field</div> | <div style="width: 200px;">Type</div> | Description                                                                                                                                 |
-| -------------------------------------- | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
-| `Request`                              | `*HTTPRequest`                        | The HTTP request to execute inside the enclave. See [`HTTPRequest`](#confidentialhttphttprequest).                                          |
-| `VaultDonSecrets`                      | `[]*SecretIdentifier`                 | List of secrets to fetch from the Vault DON and make available in the enclave. See [`SecretIdentifier`](#confidentialhttpsecretidentifier). |
+| <div style="width: 140px;">Field</div> | <div style="width: 200px;">Type</div> | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          |
+| -------------------------------------- | ------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Request`                              | `*HTTPRequest`                        | The HTTP request to execute inside the enclave. See [`HTTPRequest`](#confidentialhttphttprequest).                                                                                                                                                                                                                                                                                                                                                                                                                                                                   |
+| `VaultDonSecrets`                      | `[]*SecretIdentifier`                 | Vault DON secrets for enclave-only `{{.key}}` substitution in the request ([`SecretIdentifier`](#confidentialhttpsecretidentifier)). Use this when credentials or other sensitive template values must stay out of Workflow DON execution—not replaceable by pasting `runtime.GetSecret()` output into headers or body. See [what stays confidential](/cre/capabilities/confidential-http-go#whats-kept-confidential) and [Making Confidential Requests](/cre/guides/workflow/using-confidential-http-client/making-requests-go#step-4-implement-the-request-logic). |
 
 ### `confidentialhttp.HTTPRequest`
 
diff --git a/src/content/cre/reference/sdk/confidential-http-client-ts.mdx b/src/content/cre/reference/sdk/confidential-http-client-ts.mdx
index 01c0752e65d..0bc8b52aabf 100644
--- a/src/content/cre/reference/sdk/confidential-http-client-ts.mdx
+++ b/src/content/cre/reference/sdk/confidential-http-client-ts.mdx
@@ -17,6 +17,10 @@ The [Confidential HTTP](/cre/capabilities/confidential-http-ts) Client lets you
 - For use cases and a conceptual overview, see [The Confidential HTTP Capability](/cre/capabilities/confidential-http-ts)
 - **Guide:** [Making Confidential Requests](/cre/guides/workflow/using-confidential-http-client/making-requests-ts)
 
+<Aside type="caution" title="Do not assume sensitive values are always enclave-resolved">
+  **Credential isolation** applies when sensitive values are listed in **`vaultDonSecrets`** and referenced only with **`{{.secretName}}` placeholders**, so plaintext is resolved inside the enclave. Values you interpolate into headers or body as ordinary workflow strings—including from **`runtime.getSecret()`** and similar APIs—are resolved in **Workflow DON** execution and follow a different trust boundary. See [Making Confidential Requests](/cre/guides/workflow/using-confidential-http-client/making-requests-ts#step-4-implement-the-request-and-wire-it-into-your-workflow) for the intended pattern.
+</Aside>
+
 ## Quick reference
 
 | Method                        | Description                        |
@@ -34,10 +38,10 @@ The [Confidential HTTP](/cre/capabilities/confidential-http-ts) Client lets you
 
 The top-level request type that combines an HTTP request with Vault DON secrets and encryption settings.
 
-| <div style="width: 140px;">Field</div> | <div style="width: 230px;">Type</div>            | Description                                                                                                                                       |
-| -------------------------------------- | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `request`                              | `HTTPRequest` \| `HTTPRequestJson`               | The HTTP request to execute inside the enclave. See [`HTTPRequest`](#httprequest--httprequestjson).                                               |
-| `vaultDonSecrets`                      | `SecretIdentifier[]` \| `SecretIdentifierJson[]` | List of secrets to fetch from the Vault DON and make available in the enclave. See [`SecretIdentifier`](#secretidentifier--secretidentifierjson). |
+| <div style="width: 140px;">Field</div> | <div style="width: 230px;">Type</div>            | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
+| -------------------------------------- | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `request`                              | `HTTPRequest` \| `HTTPRequestJson`               | The HTTP request to execute inside the enclave. See [`HTTPRequest`](#httprequest--httprequestjson).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
+| `vaultDonSecrets`                      | `SecretIdentifier[]` \| `SecretIdentifierJson[]` | Vault DON secrets for enclave-only `{{.key}}` substitution in the request ([`SecretIdentifier`](#secretidentifier--secretidentifierjson)). Use this when credentials or other sensitive template values must stay out of Workflow DON execution—not replaceable by pasting `runtime.getSecret()` output into headers or body. See [what stays confidential](/cre/capabilities/confidential-http-ts#whats-kept-confidential) and [Making Confidential Requests](/cre/guides/workflow/using-confidential-http-client/making-requests-ts#step-4-implement-the-request-and-wire-it-into-your-workflow). |
 
 ### `HTTPRequest` / `HTTPRequestJson`