@tideorg/mcp 1.4.2 → 1.9.0

package/playbooks/protect-routes-nextjs.md

@@ -411,10 +411,12 @@ If route protection broken:
 
 1. **Verify auth works**:
    ```typescript
-   // Add to protected page
-   const { authenticated, user } = useTideCloak();
-   console.log('Auth:', authenticated, 'User:', user);
-   // Should log: Auth: true, User: {name: "...", ...}
+   // Add to protected page.
+   // Note: useTideCloak() has no `user` object — read claims via
+   // getValueFromIdToken / getValueFromToken.
+   const { authenticated, getValueFromIdToken } = useTideCloak();
+   console.log('Auth:', authenticated, 'User:', getValueFromIdToken('preferred_username'));
+   // Should log: Auth: true, User: "<username>"
    ```
 
 2. **Check provider wraps app**:
@@ -459,10 +461,10 @@ export async function GET() {
 
 ---
 
-### ❌ Do Not Use proxy.ts (or legacy middleware.ts) for Auth Checks
+### ❌ Do Not Hand-Roll a Cookie-Presence Check in proxy.ts / middleware.ts
 
 ```typescript
-// ❌ WRONG: Next.js proxy/middleware checks auth
+// ❌ WRONG: hand-written proxy/middleware that only checks a cookie exists
 // proxy.ts (or middleware.ts in legacy projects)
 import { NextResponse } from 'next/server';
 
@@ -474,14 +476,26 @@ export function middleware(req) {
 }
 ```
 
-**Why**:
-1. `proxy.ts` runs on the edge, cannot verify JWT signature (no access to adapter JSON)
-2. Checks cookie presence, not JWT validity
+**Why this hand-rolled version is wrong**:
+1. Checks cookie presence, not JWT validity
+2. No signature verification against the adapter's embedded `jwk`
 3. Not real authorization
 
+**Use the shipped helper instead.** `@tidecloak/nextjs/server` exports `createTideCloakProxy` (Next.js 16+, Node runtime) and `createTideCloakMiddleware` (Edge, legacy), which DO verify the token via `verifyTideCloakToken`:
+```typescript
+// proxy.ts (Next.js 16+)  — createTideCloakMiddleware for middleware.ts on ≤15
+import { createTideCloakProxy } from '@tidecloak/nextjs/server';
+import tcConfig from './data/tidecloak.json';
+
+export default createTideCloakProxy(tcConfig);
+export const config = { matcher: ['/dashboard/:path*', '/admin/:path*'] };
+```
+
+Even with a verifying proxy, keep server-side JWT verification inside API routes as the authoritative enforcement point (route interception governs page navigation, not direct API calls).
+
 **Version rule**: Next.js 16+ uses `proxy.ts`. Next.js 15 and earlier use `middleware.ts`. Check the installed version before creating or looking for this file. See [canon/framework-matrix.md](../canon/framework-matrix.md#request-interception--route-protection-ui-only).
 
-**Correct**: Client-side route guards for UX, server-side JWT verification for security.
+**Correct**: Client-side route guards (or `createTideCloakProxy`) for UX, server-side JWT verification for security.
 
 ---
 

package/playbooks/provision-tidecloak-skycloak.md

@@ -0,0 +1,213 @@
+# Provision Hosted TideCloak via Skycloak
+
+Provision a fully-managed TideCloak instance in Skycloak's cloud instead of self-hosting, then bootstrap the Tide realm on top of it. This is the hosted alternative to `deploy-tidecloak-docker`.
+
+Read `canon/hosting-options.md` first — it covers the self-host vs hosted decision, the trust model, and the honest caveats you must surface to the operator.
+
+---
+
+## When to Use
+
+- The team does not want to run auth infrastructure (containers, DB, upgrades, TLS, backups).
+- You want a managed TideCloak reachable at a stable URL with no ops burden.
+- You are prototyping and want an instance without local Docker.
+
+**Do not use** if:
+- The deployment must be air-gapped or fully self-controlled → `deploy-tidecloak-docker`.
+- You already have a running TideCloak → go straight to realm bootstrap / integration.
+- The operator has not confirmed a Skycloak account and API key exist (this playbook cannot create the account).
+
+---
+
+## Prerequisites
+
+- A Skycloak account with a workspace (dashboard at `skycloak.io`).
+- A Skycloak **API key** with scope `clusters:write` and `clusters:credentials:read`, created in Dashboard → Workspace → API keys. Shown once — capture it securely.
+- `curl` and `jq`.
+- Plan level sufficient for your region/size (non-US regions and larger sizes need Developer plan or higher; a `402 Payment Required` means the action isn't on the current plan).
+
+**Secret handling (AP-HOST-3):** The API key and any cluster automation-client secret are operator/bootstrap secrets. Keep them in the shell/CI environment. Never write them into application code, the repo, or `tidecloak.json`. Same rule as master admin credentials (AP-41).
+
+---
+
+## Overview of the flow
+
+```
+1. Create a TideCloak cluster        (Skycloak API)      → cluster id
+2. Poll until status = available     (Skycloak API)      → cluster URL
+3. Fetch automation-client creds     (Skycloak API)      → admin token source
+4. Bootstrap the Tide realm          (TideCloak admin API) → adapter JSON
+5. Wire the app                       (unchanged)          → same as self-hosted
+```
+
+Steps 1–3 are Skycloak-specific and covered here. Step 4 is the **same Tide-realm bootstrap** as the self-host path — reuse `bootstrap-realm-from-template` / the `deploy-tidecloak-docker` init sequence, pointed at the hosted URL with a token from the automation client instead of master admin creds. Step 5 is identical to any Tide app (`add-auth-nextjs-fresh` etc.).
+
+---
+
+## Step 1: Create a TideCloak cluster
+
+```bash
+export SKYCLOAK_API_KEY="<your-key>"
+API="https://api.skycloak.io"
+VER="2026-06-01.beta"
+
+# NOTE: exact request-body field names are INFERRED from the docs — if this 422s,
+# inspect the RFC 9457 error body (it lists the offending field) and adjust.
+curl -s -X POST "$API/clusters" \
+  -H "API-Key: $SKYCLOAK_API_KEY" \
+  -H "API-Version: $VER" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "identityPlatform": "TideCloak",
+    "name": "myapp-auth",
+    "size": "Small",
+    "region": "us-east"
+  }' | tee cluster-create.json | jq .
+```
+
+- **`identityPlatform: "TideCloak"`** is the field that makes this a Tide broker rather than plain Keycloak. Do not omit it.
+- `size`: `Small` (DEV), `Medium` (STAGING), `Large` (PROD).
+- Capture the returned cluster **id**: `CLUSTER_ID=$(jq -r '.id' cluster-create.json)`.
+- Creation is **asynchronous** — the response comes back before the cluster is ready.
+
+---
+
+## Step 2: Poll until available
+
+```bash
+for i in $(seq 1 40); do
+  STATUS=$(curl -s "$API/clusters/$CLUSTER_ID" \
+    -H "API-Key: $SKYCLOAK_API_KEY" -H "API-Version: $VER" | jq -r '.status')
+  echo "attempt $i: $STATUS"
+  case "$STATUS" in
+    available) echo "ready"; break ;;
+    failed)    echo "provisioning FAILED — check the Skycloak dashboard"; exit 1 ;;
+  esac
+  sleep 15
+done
+```
+
+Provisioning is typically 2–4 minutes; Skycloak also emails on completion. Do not proceed to bootstrap until status is `available`. The cluster is reachable at `https://<cluster-id>.app.skycloak.io`:
+
+```bash
+TIDECLOAK_URL="https://${CLUSTER_ID}.app.skycloak.io"
+curl -s -f "$TIDECLOAK_URL" > /dev/null && echo "TideCloak reachable" || echo "not reachable yet"
+```
+
+---
+
+## Step 3: Get an admin token (no master password exists)
+
+Skycloak does **not** issue a Keycloak admin username/password. Two ways to reach the admin API:
+
+**A. Admin Console SSO (interactive)** — for a human clicking through: open the cluster's "Go to Console" from the Skycloak dashboard, authenticated by your Skycloak account. Use this to eyeball the instance; it does not give a scriptable token.
+
+**B. Automation client (scriptable)** — each cluster has a confidential OAuth2 client `skycloak-automation-<cluster-id>` in the `master` realm for programmatic admin access. Fetch its credentials, then use client-credentials to mint admin tokens:
+
+```bash
+# Field names of the credentials response are INFERRED — inspect the actual JSON.
+curl -s "$API/clusters/$CLUSTER_ID/credentials" \
+  -H "API-Key: $SKYCLOAK_API_KEY" -H "API-Version: $VER" | tee cluster-creds.json | jq .
+
+CLIENT_ID=$(jq -r '.clientId // .automationClientId // empty' cluster-creds.json)
+CLIENT_SECRET=$(jq -r '.clientSecret // .secret // empty' cluster-creds.json)
+
+# Mint an admin token against the hosted instance's master realm:
+get_token() {
+  curl -s -X POST "$TIDECLOAK_URL/realms/master/protocol/openid-connect/token" \
+    -H "Content-Type: application/x-www-form-urlencoded" \
+    -d "grant_type=client_credentials&client_id=$CLIENT_ID&client_secret=$CLIENT_SECRET" \
+    | jq -r '.access_token'
+}
+TOKEN="$(get_token)"
+[ -n "$TOKEN" ] && [ "$TOKEN" != "null" ] && echo "admin token OK" || echo "token failed — check creds/scopes"
+```
+
+This `get_token` replaces the master-admin `get_token` in the self-host init script. Everything downstream (realm create, `setUpTideRealm`, IGA toggle, change-request authorize/commit, adapter export) is the same — just pointed at `$TIDECLOAK_URL` with this token.
+
+---
+
+## Step 4: Bootstrap the Tide realm
+
+Run the standard Tide-realm bootstrap against the hosted instance:
+
+1. `bootstrap-realm-from-template` — create the realm from the `realm.json` template (identical template to self-host; see `deploy-tidecloak-docker` Step 2), then `setUpTideRealm` + enable IGA.
+2. `initialize-admin-and-link-account` — create the admin user, assign `tide-realm-admin`, generate the Tide-account link, approve the change requests, export the adapter JSON.
+
+Use the `get_token()` from Step 3 (automation client) everywhere the self-host script uses the master-admin token. Point `TIDECLOAK_URL` at `https://<cluster-id>.app.skycloak.io`.
+
+> **VERIFY THIS ON THE LIVE INSTANCE (GAP-066).** The pack cannot yet confirm that a Skycloak-hosted TideCloak exposes the full Tide vendor surface (`setUpTideRealm`, `toggle-iga`, the change-request API, adapter export with `jwk`/`vendorId`/`homeOrkUrl`) or how Tide **licensing** is handled in the hosted context. Before promising a turnkey result:
+> - Probe `POST .../vendorResources/setUpTideRealm` and check for a 2xx + licensing JSON.
+> - After bootstrap, confirm the exported adapter JSON contains `jwk`, `vendorId`, `homeOrkUrl` (I-05, I-13).
+> - If those endpoints 404 or the adapter lacks Tide fields, **stop** — Skycloak is hosting the broker but Tide-realm provisioning/licensing needs the partner's Tide-specific path. Report this to the operator and raise with the Tide/Skycloak teams. Do not fabricate the adapter JSON.
+
+---
+
+## Step 5: Wire the app
+
+Identical to any Tide app — the hosting choice does not change integration. Adapter JSON goes to `data/tidecloak.json` (Next.js) or `public/tidecloak.json` (React/Vite), with `auth-server-url` pointing at the hosted URL. Continue with `add-auth-nextjs-fresh` / `add-auth-nextjs-existing`, then route/API protection.
+
+---
+
+## Verification Checklist
+
+```bash
+# Cluster available
+curl -s "$API/clusters/$CLUSTER_ID" -H "API-Key: $SKYCLOAK_API_KEY" -H "API-Version: $VER" | jq '.status'
+# → "available"
+
+# Hosted TideCloak reachable
+curl -s -f "https://${CLUSTER_ID}.app.skycloak.io" > /dev/null && echo reachable
+
+# Admin token from automation client works
+[ -n "$(get_token)" ] && echo "token OK"
+
+# After bootstrap: adapter has Tide extensions (the real turnkey test — GAP-066)
+jq 'has("jwk") and has("vendorId") and has("homeOrkUrl")' data/tidecloak.json
+# → true   (if false: GAP-066 — hosted Tide vendor surface not confirmed)
+
+# IGA enabled on the hosted realm
+curl -s "https://${CLUSTER_ID}.app.skycloak.io/admin/realms/myapp" \
+  -H "Authorization: Bearer $(get_token)" | jq '.attributes.isIGAEnabled'
+```
+
+---
+
+## Common Failures
+
+### `402 Payment Required` on create
+The chosen region/size isn't available on the current plan (e.g. a non-US region on a trial workspace). Use a US region / `Small` size, or upgrade the plan. The RFC 9457 body's `detail` states the constraint.
+
+### `403` "does not have the required scope"
+The API key lacks `clusters:write` (create) or `clusters:credentials:read` (Step 3). Create a key with the right scopes; note write includes read.
+
+### Missing `API-Version` header (AP-HOST-4)
+Every Skycloak call needs `-H "API-Version: 2026-06-01.beta"`. Omitting it fails the request.
+
+### `422` on create with a field complaint
+The request-body field names here are INFERRED from the docs. Read the `errors[]` array in the RFC 9457 response — it names the offending `field` — and adjust (`identityPlatform`/`size`/`region` spellings, enum values).
+
+### Cluster stuck in `provisioning` / went `failed`
+Provisioning is async and occasionally fails server-side. Check the Skycloak dashboard for the cluster's error detail; recreate if `failed`. Do not bootstrap against a non-`available` cluster.
+
+### Adapter JSON missing Tide fields after bootstrap (GAP-066)
+The hosted instance may not expose the Tide vendor surface, or licensing wasn't provisioned. Do not fall back to `createRemoteJWKSet` or hand-build the adapter (I-04). Stop and escalate — this is the open question the hosted path depends on.
+
+---
+
+## Anti-Patterns
+
+- **AP-HOST-2** — Telling the user the hosted Tide path is fully turnkey before GAP-066 is confirmed. Cluster provisioning is verified; the Tide-realm bootstrap on top is not.
+- **AP-HOST-3** — Putting `SKYCLOAK_API_KEY` or the `skycloak-automation-*` secret in app code, `tidecloak.json`, or the repo. Bootstrap secrets only.
+- **AP-HOST-4** — Omitting the `API-Version` header.
+- **Do not** fabricate `tidecloak.json` if the hosted vendor endpoints are absent. A missing adapter is a provisioning problem to escalate, not a file to invent (I-05, I-13).
+- **Do not** present hosting as either a security downgrade or a magic upgrade — state the real trust model from `canon/hosting-options.md` (availability + metadata + Tideless-IGA caveat).
+
+---
+
+## References
+
+- `canon/hosting-options.md` — decision, trust model, Skycloak API reference, GAP-066
+- Skycloak docs: `https://skycloak.io/docs/api/` (API-Version `2026-06-01.beta`)
+- `deploy-tidecloak-docker` — the self-host equivalent and the shared realm-bootstrap sequence
+- `bootstrap-realm-from-template`, `initialize-admin-and-link-account` — the Tide-realm steps reused in Step 4

package/playbooks/setup-forseti-e2ee.md

@@ -289,24 +289,27 @@ const executeTideRequest = async (request, waitForAll = false) => {
 WRONG:  GET /admin/realms/{realm}/tide-admin/realm-policy
         -> { status: "none" } (even when the policy exists)
 
-CORRECT: GET /realms/{realm}/tide-policy-resources/admin-policy
-         -> base64-encoded bytes (public, no auth required)
+WRONG:  GET /realms/{realm}/tide-policy-resources/admin-policy
+        -> does NOT exist on current main (the public policy endpoint was removed)
+
+CORRECT: GET /admin/realms/{realm}/iga/role-policies   (admin bearer required)
+         -> JSON; the signed admin policy bytes are in the `policy` field
 ```
 
-The correct endpoint does not require master admin credentials. Proxy through your backend.
+The correct endpoint is an admin API route and **requires an admin bearer token**. Proxy through your backend so the browser never holds the admin credential.
 
-**CORS: Browser cannot fetch this endpoint directly.** TideCloak and the app are on different origins. Direct browser fetch returns an opaque/blocked response. Create a same-origin API route that proxies the request server-side. VERIFIED (session-001).
+**CORS: Browser cannot fetch this endpoint directly.** TideCloak and the app are on different origins, and this is a privileged admin API. Direct browser fetch returns an opaque/blocked response (and would leak the admin bearer). Create a same-origin API route that proxies the request server-side with the admin token. VERIFIED (session-001).
 
 **If the proxy route is protected with `withAuth` (correct per I-03), the client must use authenticated fetch** (e.g., `appFetch` or `secureFetch` with Bearer header). A bare `fetch()` without Authorization returns 401. The resulting empty/error response produces undefined policy bytes, causing `PolicyAuthorizationFlowException: "Model does not have a policy passed with it"` at signing time. VERIFIED (LEARNINGS-batch-009 L-08).
 
 **There is no REST API for deploying Forseti contracts.** Do not try `PUT` or `POST` to `/tide-admin/forseti-contracts` — these endpoints do not exist on the dev image (404/405). Contract deployment happens via `PolicySignRequest.addForsetiContractToUpload(contractSource)` in the browser signing flow (Step 4). VERIFIED (session-001).
 
-**The response is base64-encoded, not raw binary.** You must decode before using:
+**The signed bytes arrive as a base64 string in the `policy` field, not raw binary.** Read the `policy` field and decode before using:
 
 ```js
-// Backend proxy
-const b64 = await tcRes.text();
-const raw = Buffer.from(b64, "base64");
+// Backend proxy (holds the admin bearer)
+const json = await tcRes.json();
+const raw = Buffer.from(json.policy, "base64");
 const bytes = Array.from(new Uint8Array(raw));
 res.json({ policyBytes: bytes });
 
@@ -315,12 +318,12 @@ const data = await res.json();
 const adminPolicyBytes = new Uint8Array(data.policyBytes);
 ```
 
-**Common mistake:** Treating the base64 string as raw bytes (passing each character's char code as a byte value). If admin policy bytes start with `[65, 81, 65, 65, ...]` (ASCII for "AQAA..."), you are passing base64 text as byte values instead of decoding it. The ORK will fail with `Index out of range` because the policy structure is garbage.
+**Common mistake:** Treating the base64 `policy` string as raw bytes (passing each character's char code as a byte value). If admin policy bytes start with `[65, 81, 65, 65, ...]` (ASCII for "AQAA..."), you are passing base64 text as byte values instead of decoding it. The ORK will fail with `Index out of range` because the policy structure is garbage.
 
-**Common mistake:** Malformed URL from trailing slash in `auth-server-url`. The adapter JSON `auth-server-url` may include a trailing slash (e.g., `http://localhost:8080/`). Constructing the admin policy URL without stripping it produces `http://localhost:8080//realms/...` (double slash), which returns HTML or 404 instead of policy bytes. Always normalize:
+**Common mistake:** Malformed URL from trailing slash in `auth-server-url`. The adapter JSON `auth-server-url` may include a trailing slash (e.g., `http://localhost:8080/`). Constructing the admin policy URL without stripping it produces `http://localhost:8080//admin/realms/...` (double slash), which returns HTML or 404 instead of policy bytes. Always normalize:
 ```js
 const baseUrl = config["auth-server-url"].replace(/\/+$/, "");
-const adminPolicyUrl = `${baseUrl}/realms/${config.realm}/tide-policy-resources/admin-policy`;
+const adminPolicyUrl = `${baseUrl}/admin/realms/${config.realm}/iga/role-policies`;
 ```
 
 ---
@@ -528,50 +531,29 @@ These are prep steps. None produce VVK-signed bytes.
 
 Role assignments that produce VVK-signed UserContexts MUST be manually approved through the approval enclave in the admin's browser. You cannot automate this from a backend script.
 
-What happens when you try to auto-approve:
-
-```
-POST /tide-admin/change-set/sign
-Response: { "requiresApprovalPopup": true, "changeSetDraftRequests": "base64..." }
-```
-
-The `requiresApprovalPopup: true` response means the backend CANNOT complete the signing. The VVK-signed UserContext binds a specific user's `tideUserKey` to specific roles. This signing must happen through the ORK threshold network via the Tide enclave running in the admin's browser.
-
-**Always use `/batch` endpoints for approval:**
+This is Tide MultiAdmin mode: the VVK-signed UserContext binds a specific user's `tideUserKey` to specific roles, and the signing must happen through the ORK threshold network via the Tide enclave in the admin's browser. The backend CANNOT complete it — a bare `authorize` on such a CR requires the two-phase `approval-model` enclave exchange. (Endpoints: current `/iga/change-requests/...` surface — see `canon/iga-change-requests-api.md`.)
 
 ```js
-// 1. Backend creates IGA draft (role assignment)
+// 1. Backend performs the governed change (role assignment) → 202, a CR is created
 POST /admin/realms/{realm}/users/{userId}/role-mappings/realm
 
-// 2. Frontend fetches pending requests
-GET /admin/realms/{realm}/tide-admin/change-set/users/requests
+// 2. Frontend fetches pending CRs
+GET /admin/realms/{realm}/iga/change-requests?status=PENDING   // objects keyed by `id`
 
-// 3. Frontend calls sign/batch (one call for all selected)
-POST /admin/realms/{realm}/tide-admin/change-set/sign/batch
-{ changeSets: [{ changeSetId, changeSetType, actionType, policyRoleId? }] }
+// 3. For each CR, fetch the enclave challenge (Tide MultiAdmin)
+GET /admin/realms/{realm}/iga/change-requests/{id}/approval-model
+//   → { changeRequestId, requestModel: "base64..." }
 
-// 4. Collect all that need enclave, pass to ONE approval popup
-const enclaveRequests = results
-  .filter(r => r.requiresApprovalPopup)
-  .map(r => ({ id: r.changesetId, request: base64ToBytes(r.changeSetDraftRequests) }));
+// 4. Collect the challenges, pass to ONE enclave approval popup
+const enclaveRequests = pending.map(cr => ({ id: cr.id, request: base64ToBytes(cr.requestModel) }));
 const approvals = await tc.requestTideOperatorApproval(enclaveRequests);
 
-// 5. Submit each signed review via add-review (FormData, NOT JSON)
-POST /admin/realms/{realm}/tideAdminResources/add-review
-
-// 6. Commit all in batch
-POST /admin/realms/{realm}/tide-admin/change-set/commit/batch
-{ changeSets: [{ changeSetId, changeSetType, actionType }] }
-```
+// 5. Submit each signed doken back to the same endpoint
+POST /admin/realms/{realm}/iga/change-requests/{id}/approval-model
+{ "requestModel": "<base64 doken>" }   // → { recorded, authCount, threshold }
 
-**The add-review endpoint uses FormData, not JSON:**
-
-```js
-const formData = new FormData();
-formData.append("changeSetId", id);
-formData.append("actionType", actionType);
-formData.append("changeSetType", changeSetType);
-formData.append("requests", btoa(String.fromCharCode(...signedBytes)));
+// 6. Commit each CR once ready (readyToCommit === true)
+POST /admin/realms/{realm}/iga/change-requests/{id}/commit   // 412 if still under threshold
 ```
 
 After commit: the user must refresh their token (or re-login) for the new role to appear in their doken. Use `IAMService.forceUpdateToken()` or `useTideCloak().forceRefreshToken()`.
@@ -656,8 +638,8 @@ The forseti-crypto-quickstart is the reference implementation that works against
 - [ ] `modelId` is `["PolicyEnabledEncryption:1", "PolicyEnabledDecryption:1"]` (array, not string)
 - [ ] `PolicySignRequest` imported from `heimdall-tide`
 - [ ] `BaseTideRequest.decode()` called on `createTideRequest` result before approval
-- [ ] Admin policy fetched from `GET /realms/{realm}/tide-policy-resources/admin-policy` (not the admin API endpoint)
-- [ ] Admin policy bytes are base64-decoded (not raw char codes)
+- [ ] Admin policy fetched (admin bearer) from `GET /admin/realms/{realm}/iga/role-policies`; signed bytes read from the `policy` field (the public `tide-policy-resources/admin-policy` endpoint does not exist on main)
+- [ ] Admin policy bytes are base64-decoded from the `policy` field (not raw char codes)
 - [ ] Approval popup opens and admin approves
 - [ ] `executeSignRequest` called with `waitForAll = true`
 - [ ] `policy.signature = signatures[0]` assigned before `policy.toBytes()`
@@ -701,8 +683,8 @@ The forseti-crypto-quickstart is the reference implementation that works against
 
 ### `{ status: "none" }` when fetching admin policy
 
-**Cause:** Using the wrong endpoint `GET /admin/realms/{realm}/tide-admin/realm-policy`.
-**Fix:** Use `GET /realms/{realm}/tide-policy-resources/admin-policy`.
+**Cause:** Using the wrong endpoint `GET /admin/realms/{realm}/tide-admin/realm-policy`. (The old public `GET /realms/{realm}/tide-policy-resources/admin-policy` endpoint no longer exists on main either.)
+**Fix:** Use `GET /admin/realms/{realm}/iga/role-policies` with an admin bearer token and read the signed bytes from the `policy` field.
 
 ### Admin policy bytes start with `[65, 81, 65, 65, ...]`