diff --git a/docs/auth/authentication/oidc.mdx b/docs/auth/authentication/oidc.mdx
index 5fe7d076102..4ccecf51d61 100644
--- a/docs/auth/authentication/oidc.mdx
+++ b/docs/auth/authentication/oidc.mdx
@@ -61,7 +61,19 @@ auth:
  # groups_claim: "groups"
 ```
 
-### Step 3: Configure Scopes (Optional)
+### Step 3: Seed Auth Role Bindings
+
+The `auth.admin_email` setting identifies the bootstrap admin, but the role binding is created by the platform seed task. Docker quickstart runs platform seed automatically, and Helm deployments run the platform-seed Job by default. For source installs, start services with `platform.seed_on_startup: true` or `NMP_SEED_ON_STARTUP=true`; if services are already running, run the seed task manually after services are healthy:
+
+```bash
+# Set NMP_BASE_URL first if services are not on http://localhost:8080.
+curl -sf http://localhost:8080/health/ready
+uv run python -m nmp.platform_seed
+```
+
+The seed task creates the **PlatformAdmin** binding for `auth.admin_email`, plus the default wildcard bindings used for authenticated access. Without this step, OIDC login can succeed while admin operations return `403 Forbidden`.
+
+### Step 4: Configure Scopes (Optional)
 
 This step is only needed if you created custom API scopes in Step 1. If you skip scopes, NeMo Platform still enforces RBAC — scopes add an additional token-level restriction on top. See [API Scopes](/documentation/access-control/authorization/api-scopes).
 
@@ -81,7 +93,7 @@ auth:
  scope_prefix: "api://your-client-id/"
 ```
 
-### Step 4: Verify
+### Step 5: Verify
 
 After deploying the configuration:
 
diff --git a/docs/auth/deployment/configuration.mdx b/docs/auth/deployment/configuration.mdx
index 1e36421a290..0b4e0c2bedc 100644
--- a/docs/auth/deployment/configuration.mdx
+++ b/docs/auth/deployment/configuration.mdx
@@ -29,7 +29,7 @@ When `auth.enabled` is `false` (the default), all API requests are allowed witho
 
 ### Bootstrap Admin
 
-When authorization is enabled, a platform administrator can be configured. Setting **`admin_email`** gives that identity the **PlatformAdmin** role at platform start. Use it to create the first workspaces and grant roles to other users. After bootstrap, manage access via workspaces and members as described in [Managing Access](/documentation/access-control/authorization/managing-access).
+When authorization is enabled, a platform administrator can be configured. Setting **`admin_email`** tells platform seed which identity should receive the **PlatformAdmin** role. Use it to create the first workspaces and grant roles to other users. After bootstrap, manage access via workspaces and members as described in [Managing Access](/documentation/access-control/authorization/managing-access).
 
 ```yaml
 auth:
@@ -37,6 +37,8 @@ auth:
  admin_email: "your-admin@company.com"
 ```
 
+The binding is created by `platform-seed`, not by auth service startup alone. Helm deployments run the platform-seed Job by default. For source installs, set `platform.seed_on_startup: true`, export `NMP_SEED_ON_STARTUP=true` before `nemo services run`, or run `uv run python -m nmp.platform_seed` after services are healthy. If platform seed has not run, `admin_email` users can authenticate but still receive `403 Forbidden` because their PlatformAdmin binding does not exist.
+
 This page covers the auth-specific configuration fields you need to enable and operate authorization. Auth-related values are found under `platformConfig.auth` in the values file.
 
 For OIDC-specific fields (`auth.oidc`), see [OIDC Setup](/documentation/access-control/authentication/oidc-setup).
diff --git a/docs/get-started/setup.mdx b/docs/get-started/setup.mdx
index d3463b3992f..322e65b5587 100644
--- a/docs/get-started/setup.mdx
+++ b/docs/get-started/setup.mdx
@@ -53,6 +53,27 @@ The wizard walks through each stage:
 
 Each stage is idempotent — you can re-run `nemo setup` at any time to add more providers or update your configuration.
 
+### Auth and OIDC source installs
+
+`nemo setup` and `nemo services run` do not create authorization role bindings by themselves. If you enable auth in source config with `auth.enabled: true` and set `auth.admin_email`, run the platform seed task so the bootstrap IAM bindings exist.
+
+For local single-process source runs, enable startup seeding before starting services:
+
+```bash
+export NMP_SEED_ON_STARTUP=true
+nemo services run
+```
+
+You can set `platform.seed_on_startup: true` in platform config instead. If services are already running, wait for readiness and run the seed task manually from the repository root:
+
+```bash
+# Set NMP_BASE_URL first if services are not on http://localhost:8080.
+curl -sf http://localhost:8080/health/ready
+uv run python -m nmp.platform_seed
+```
+
+`uv run nemo-platform run task --task nmp.platform_seed` is equivalent. The seed task is idempotent. It creates the **PlatformAdmin** binding in the `system` workspace for `auth.admin_email`, the wildcard **Editor** binding for the default workspace, and the wildcard **Viewer** binding for the `system` workspace. Without this step, OIDC login can succeed but admin operations may still return `403 Forbidden` because the RBAC bindings are missing.
+
 When setup completes, try chatting with the model you selected. Use the model name shown at the end of setup (or find it with `nemo models list`):
 
 ```bash