docs(secrets-manager): document org-wide WI scope and per-kickoff fetch behavior

Adds a "Visibility & Scope" section to the Secrets Manager overview
(en/pt-BR/ko/ar) calling out that Workload Identity configs are
organization-wide today and that every automation kickoff runs the
WI secret-fetch phase regardless of whether the automation references
any WI-backed env var. Temporary disclosure pending per-automation
scoping (tracked separately in CON-201).

Refs CON-203

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

@@ -53,6 +53,17 @@ sidebarTitle: نظرة عامة
 2. **يُشير المسؤول (أو عضو مصرَّح له) إلى سر في متغير بيئة.** من صفحة متغيرات البيئة، يختار المستخدم بيانات اعتماد المزود ويُحدّد اسم السر. راجع [استخدام مدير الأسرار](/ar/enterprise/features/secrets-manager/usage#referencing-secrets-in-environment-variables).
 3. **تتلقى الأتمتة القيمة المحلولة وقت التشغيل.** عندما يعمل طاقم أو أتمتة، تجلب CrewAI Platform السر من مزوّدك وتحقنه كقيمة لمتغير البيئة. مع Workload Identity، يحدث هذا الجلب في كل إطلاق (مراعٍ للتدوير). مع بيانات الاعتماد الثابتة، يحدث الجلب وقت النشر وتُدمج القيمة في صورة النشر.
 
+## الرؤية والنطاق
+
+<Warning>
+تكوينات Workload Identity هي اليوم **عامة على مستوى المنظمة في كل نشر** — لا يوجد ربط لكل أتمتة. توجد نتيجتان جديرتان بالمعرفة قبل تبنّي مسار Workload Identity على نطاق واسع.
+</Warning>
+
+- **يُشغّل كل إطلاق أتمتة مرحلة جلب الأسرار**، بصرف النظر عمّا إذا كانت الأتمتة تُشير إلى أي متغير بيئة مدعوم بـ WI. في كل إطلاق لـ crew أو flow أو training أو test أو checkpoint-restore، يقوم وقت التشغيل بجلب جميع متغيرات البيئة المدعومة بـ WI المُكوَّنة للنشر ويكتبها في بيئة العملية. التكلفة: تأخّر إضافي بسيط لكل إطلاق بالإضافة إلى إدخال واحد في سجل تدقيق السحابة لكل متغير بيئة مدعوم بـ WI.
+- **ترى جميع الأتمتات في النشر كل متغيرات البيئة المحلولة بواسطة WI.** لا يمكنك اليوم تقييد تكوين Workload Identity محدد (أو الأسرار التي يحلّها) لأتمتة بعينها. اعتبر الأسرار المدعومة بـ WI متاحة لكل أتمتة في المنظمة.
+
+تحديد النطاق لكل أتمتة موجود في خارطة الطريق. حتى ذلك الحين، خطّط لاستخدام Workload Identity على مستوى المنظمة، وليس لكل سير عمل — واقصُر متغيرات البيئة المدعومة بـ WI على الأسرار التي يحقّ لكل أتمتة في المنظمة قراءتها.
+
 ## الأذونات
 
 تتحكم ميزتان في CrewAI Platform بالوصول إلى مدير الأسرار:

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

@@ -53,6 +53,17 @@ Setting up Secrets Manager is a three-step flow that involves both your cloud pr
 2. **An admin (or a permitted member) references a secret in an environment variable.** From the Environment Variables page, the user picks a provider credential and selects the secret name. See [Using the Secrets Manager](/en/enterprise/features/secrets-manager/usage#referencing-secrets-in-environment-variables).
 3. **The automation receives the resolved value at runtime.** When a crew or automation runs, CrewAI Platform fetches the secret from your provider and injects it as the environment variable's value. With Workload Identity, this fetch happens on every kickoff (rotation-aware). With static credentials, this fetch happens at deploy time and the value is baked into the deployment image.
 
+## 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>
+
+- **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.
+
 ## Permissions
 
 Two CrewAI Platform features control access to Secrets Manager:

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

@@ -53,6 +53,17 @@ Secrets Manager 설정은 클라우드 공급자와 CrewAI Platform 양쪽 모
 2. **관리자(또는 권한이 부여된 멤버)가 환경 변수에서 시크릿을 참조합니다.** Environment Variables 페이지에서 공급자 자격 증명을 선택하고 시크릿 이름을 선택합니다. [Secrets Manager 사용하기](/ko/enterprise/features/secrets-manager/usage#referencing-secrets-in-environment-variables)를 참조하세요.
 3. **자동화가 런타임에 해석된 값을 받습니다.** Crew 또는 자동화가 실행될 때, CrewAI Platform이 공급자에서 시크릿을 가져와 환경 변수 값으로 주입합니다. Workload Identity의 경우 이 가져오기는 매 kickoff마다 수행됩니다(로테이션 인식). 정적 자격 증명의 경우 이 가져오기는 배포 시점에 수행되고 값이 배포 이미지에 박힙니다.
 
+## 가시성 및 범위
+
+<Warning>
+Workload Identity 구성은 현재 각 배포에서 **조직 전체에 적용됩니다** — 자동화별 바인딩은 없습니다. Workload Identity 경로를 광범위하게 도입하기 전에 알아둘 만한 두 가지 결과가 있습니다.
+</Warning>
+
+- **모든 자동화 kickoff가 시크릿 가져오기 단계를 실행합니다.** 자동화가 WI 기반 환경 변수를 참조하는지 여부와 관계없이 실행됩니다. 매 crew, flow, training, test, 또는 checkpoint-restore kickoff마다, 런타임은 배포에 구성된 모든 WI 기반 환경 변수를 가져와 프로세스 환경에 기록합니다. 비용: kickoff당 약간의 추가 지연 시간과, WI 기반 환경 변수당 하나의 클라우드 측 audit log 항목.
+- **배포의 모든 자동화가 WI로 해석된 모든 환경 변수를 볼 수 있습니다.** 오늘날에는 특정 Workload Identity 구성(또는 그것이 해석하는 시크릿)을 특정 자동화로 제한할 수 없습니다. WI 기반 시크릿은 조직 내 모든 자동화에서 사용할 수 있다고 간주하세요.
+
+자동화별 범위 지정은 로드맵에 있습니다. 그때까지는 Workload Identity 사용을 워크플로별이 아닌 조직 수준에서 계획하고 — WI 기반 환경 변수는 조직 내 모든 자동화가 읽을 수 있는 시크릿으로만 제한하세요.
+
 ## 권한
 
 Secrets Manager 접근을 제어하는 두 가지 CrewAI Platform 기능:

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

@@ -53,6 +53,17 @@ Configurar o Secrets Manager é um fluxo de três passos que envolve tanto o seu
 2. **Um admin (ou um membro autorizado) referencia um segredo em uma variável de ambiente.** Na página de Variáveis de Ambiente, o usuário escolhe uma credencial de provedor e seleciona o nome do segredo. Veja [Usando o Secrets Manager](/pt-BR/enterprise/features/secrets-manager/usage#referencing-secrets-in-environment-variables).
 3. **A automação recebe o valor resolvido em runtime.** Quando um crew ou automação executa, a CrewAI Platform busca o segredo do seu provedor e o injeta como o valor da variável de ambiente. Com Workload Identity, essa busca acontece a cada kickoff (consciente de rotação). Com credenciais estáticas, essa busca acontece no momento do deploy e o valor é incorporado à imagem do deployment.
 
+## 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>
+
+- **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.
+
 ## Permissões
 
 Duas features da CrewAI Platform controlam o acesso ao Secrets Manager: