docs(secrets-manager): WI env vars now follow deployment assignment

Rewrite the Visibility & Scope section in the Secrets Manager overview
(en/ar/ko/pt-BR) to reflect the per-deployment scoping shipped in
crewAIInc/crewai-plus#3205: WI-backed env vars now resolve only when
explicitly assigned to a deployment, matching the assignment model that
plaintext env vars have always used. Per-kickoff cost is reframed as
proportional to assigned WI-backed variables rather than the entire
organization's WI footprint.

Refs CON-205

docs/ar/enterprise/features/secrets-manager/overview.mdx

@@ -56,14 +56,9 @@ icon: "book-open"
 
 ## الرؤية والنطاق
 
-<Warning>
-تكوينات Workload Identity هي اليوم **عامة على مستوى المنظمة في كل نشر** — لا يوجد ربط لكل أتمتة. توجد نتيجتان جديرتان بالمعرفة قبل تبنّي مسار Workload Identity على نطاق واسع.
-</Warning>
+تتّبع متغيرات البيئة المدعومة بـ WI نفس نموذج الإسناد الذي تتّبعه متغيرات البيئة العادية: لا تحلّ الأتمتة سوى متغيرات البيئة المدعومة بـ WI المُسنَدة إليها صراحةً. أَسنِد متغير WI إلى أتمتة من صفحة متغيرات البيئة الخاصة بتلك الأتمتة؛ المتغيرات المُعرَّفة على مستوى المنظمة أو في مشروع Studio لا تُحلّ عند الإطلاق حتى تُسنِدها.
 
-- **يُشغّل كل إطلاق أتمتة مرحلة جلب الأسرار**، بصرف النظر عمّا إذا كانت الأتمتة تُشير إلى أي متغير بيئة مدعوم بـ WI. في كل إطلاق لـ crew أو flow أو training أو test أو checkpoint-restore، يقوم وقت التشغيل بجلب جميع متغيرات البيئة المدعومة بـ WI المُكوَّنة للنشر ويكتبها في بيئة العملية. التكلفة: تأخّر إضافي بسيط لكل إطلاق بالإضافة إلى إدخال واحد في سجل تدقيق السحابة لكل متغير بيئة مدعوم بـ WI.
-- **ترى جميع الأتمتات في النشر كل متغيرات البيئة المحلولة بواسطة WI.** لا يمكنك اليوم تقييد تكوين Workload Identity محدد (أو الأسرار التي يحلّها) لأتمتة بعينها. اعتبر الأسرار المدعومة بـ WI متاحة لكل أتمتة في المنظمة.
-
-تحديد النطاق لكل أتمتة موجود في خارطة الطريق. حتى ذلك الحين، خطّط لاستخدام Workload Identity على مستوى المنظمة، وليس لكل سير عمل — واقصُر متغيرات البيئة المدعومة بـ WI على الأسرار التي يحقّ لكل أتمتة في المنظمة قراءتها.
+لا يزال كل إطلاق يُشغّل مرحلة جلب الأسرار. في كل إطلاق لـ crew أو flow أو training أو test أو checkpoint-restore، يقوم وقت التشغيل بجلب متغيرات البيئة المدعومة بـ WI المُسنَدة إلى تلك الأتمتة ويكتبها في بيئة العملية. التكلفة متناسبة مع عدد متغيرات WI المُسنَدة: تأخّر إضافي بسيط لكل إطلاق بالإضافة إلى إدخال واحد في سجل تدقيق السحابة لكل متغير مُسنَد.
 
 ## الأذونات
 

docs/en/enterprise/features/secrets-manager/overview.mdx

@@ -56,14 +56,9 @@ Setting up Secrets Manager is a three-step flow that involves both your cloud pr
 
 ## Visibility & Scope
 
-<Warning>
-Workload Identity configurations are **organization-wide on each deployment** today — there is no per-automation binding. Two consequences worth knowing before you adopt the Workload Identity path broadly.
-</Warning>
+WI-backed environment variables follow the same assignment model as plaintext environment variables: an automation resolves only the WI-backed variables explicitly assigned to it. Assign a WI-backed variable to an automation from the Environment Variables page on that automation; variables defined at the organization level or in a Studio project are not resolved at kickoff until you assign them.
 
-- **Every automation kickoff runs the secret-fetch phase**, regardless of whether the automation references any WI-backed environment variable. On every crew, flow, training, test, or checkpoint-restore kickoff, the runtime fetches all WI-backed environment variables configured for the deployment and writes them into the process environment. Cost: a small added latency per kickoff plus one cloud-side audit-log entry per WI-backed environment variable.
-- **All automations on the deployment see all WI-resolved environment variables.** You cannot today restrict a specific Workload Identity configuration (or the secrets it resolves) to a specific automation. Treat WI-backed secrets as available to every automation in the organization.
-
-Per-automation scoping is on the roadmap. Until then, plan Workload Identity usage at the organization level, not per workflow — and keep WI-backed environment variables limited to secrets every automation in the organization is allowed to read.
+Each kickoff still runs the secret-fetch phase. On every crew, flow, training, test, or checkpoint-restore kickoff, the runtime fetches the WI-backed environment variables assigned to that automation and writes them into the process environment. Cost is proportional to the number of assigned WI-backed variables: a small added latency per kickoff plus one cloud-side audit-log entry per assigned variable.
 
 ## Permissions
 

docs/ko/enterprise/features/secrets-manager/overview.mdx

@@ -56,14 +56,9 @@ Secrets Manager 설정은 클라우드 공급자와 CrewAI Platform 양쪽 모
 
 ## 가시성 및 범위
 
-<Warning>
-Workload Identity 구성은 현재 각 배포에서 **조직 전체에 적용됩니다** — 자동화별 바인딩은 없습니다. Workload Identity 경로를 광범위하게 도입하기 전에 알아둘 만한 두 가지 결과가 있습니다.
-</Warning>
+WI 기반 환경 변수는 평문 환경 변수와 동일한 할당 모델을 따릅니다: 자동화는 명시적으로 할당된 WI 기반 변수만 해석합니다. 해당 자동화의 Environment Variables 페이지에서 WI 기반 변수를 자동화에 할당하세요; 조직 수준 또는 Studio 프로젝트에 정의된 변수는 할당하기 전까지 kickoff에서 해석되지 않습니다.
 
-- **모든 자동화 kickoff가 시크릿 가져오기 단계를 실행합니다.** 자동화가 WI 기반 환경 변수를 참조하는지 여부와 관계없이 실행됩니다. 매 crew, flow, training, test, 또는 checkpoint-restore kickoff마다, 런타임은 배포에 구성된 모든 WI 기반 환경 변수를 가져와 프로세스 환경에 기록합니다. 비용: kickoff당 약간의 추가 지연 시간과, WI 기반 환경 변수당 하나의 클라우드 측 audit log 항목.
-- **배포의 모든 자동화가 WI로 해석된 모든 환경 변수를 볼 수 있습니다.** 오늘날에는 특정 Workload Identity 구성(또는 그것이 해석하는 시크릿)을 특정 자동화로 제한할 수 없습니다. WI 기반 시크릿은 조직 내 모든 자동화에서 사용할 수 있다고 간주하세요.
-
-자동화별 범위 지정은 로드맵에 있습니다. 그때까지는 Workload Identity 사용을 워크플로별이 아닌 조직 수준에서 계획하고 — WI 기반 환경 변수는 조직 내 모든 자동화가 읽을 수 있는 시크릿으로만 제한하세요.
+각 kickoff는 여전히 시크릿 가져오기 단계를 실행합니다. 매 crew, flow, training, test, 또는 checkpoint-restore kickoff마다, 런타임은 해당 자동화에 할당된 WI 기반 환경 변수를 가져와 프로세스 환경에 기록합니다. 비용은 할당된 WI 기반 변수 수에 비례합니다: kickoff당 약간의 추가 지연 시간과, 할당된 변수당 하나의 클라우드 측 audit log 항목.
 
 ## 권한
 

docs/pt-BR/enterprise/features/secrets-manager/overview.mdx

@@ -56,14 +56,9 @@ Configurar o Secrets Manager é um fluxo de três passos que envolve tanto o seu
 
 ## Visibilidade & Escopo
 
-<Warning>
-As configurações de Workload Identity são hoje **abrangentes a toda a organização em cada deployment** — não existe vinculação por automação. Duas consequências que vale conhecer antes de adotar o caminho de Workload Identity de forma ampla.
-</Warning>
+Variáveis de ambiente atreladas a WI seguem o mesmo modelo de atribuição das variáveis de ambiente em texto puro: uma automação resolve apenas as variáveis atreladas a WI explicitamente atribuídas a ela. Atribua uma variável atrelada a WI a uma automação pela página de Variáveis de Ambiente dessa automação; variáveis definidas no nível da organização ou em um projeto Studio não são resolvidas em kickoff até que você as atribua.
 
-- **Todo kickoff de automação executa a fase de busca de segredos**, independentemente de a automação referenciar ou não alguma variável de ambiente atrelada a WI. Em todo kickoff de crew, flow, training, test ou checkpoint-restore, o runtime busca todas as variáveis de ambiente atreladas a WI configuradas para o deployment e as grava no ambiente do processo. Custo: uma pequena latência adicional por kickoff mais uma entrada no audit log do lado da nuvem por variável de ambiente atrelada a WI.
-- **Todas as automações no deployment enxergam todas as variáveis de ambiente resolvidas por WI.** Hoje você não pode restringir uma configuração específica de Workload Identity (ou os segredos que ela resolve) a uma automação específica. Trate os segredos atrelados a WI como disponíveis para toda automação da organização.
-
-Escopo por automação está no roadmap. Até lá, planeje o uso de Workload Identity no nível da organização, não por workflow — e mantenha as variáveis de ambiente atreladas a WI limitadas a segredos que toda automação da organização tem permissão de ler.
+Cada kickoff ainda executa a fase de busca de segredos. Em todo kickoff de crew, flow, training, test ou checkpoint-restore, o runtime busca as variáveis de ambiente atreladas a WI atribuídas àquela automação e as grava no ambiente do processo. O custo é proporcional ao número de variáveis atreladas a WI atribuídas: uma pequena latência adicional por kickoff mais uma entrada no audit log do lado da nuvem por variável atribuída.
 
 ## Permissões