@frontmcp/skills 1.8.2 → 1.8.4

package/catalog/create-tool/references/availability.md

@@ -100,6 +100,8 @@ These are fine for ergonomic branching. For tools that **shouldn't exist at all*
 
 This is the safest way to expose internal-only tools that you want an agent / job to call but don't want a user to invoke from a chat UI.
 
+An MCP client (and the in-process client of a CLI build, surface `'cli'`) never sees such a tool: it is absent from `tools/list`, and `tools/call` answers `Tool "rotate_secrets" not found`, exactly as for a tool that doesn't exist. Resources, resource templates, prompts, agents and skills (including the skills HTTP endpoints, which count as `'mcp'`) follow the same rule, and CodeCall applies its caller's surface to the tools it reaches. An agent's model calls its tools on `'agent'` (and is only offered those its `surface` allows), a job's or workflow step's `this.callTool()` on `'job'`, and a `@Channel` handling a webhook on `'http-trigger'`. A tool, resource or prompt calling `this.callTool()` is in-process dispatch: that call carries no surface and is not restricted. Code reads its call's surface with `getCallSurface()`. The process-wide axes (`os`, `runtime`, ...) answer `EntryUnavailableError` instead.
+
 ## See also
 
 - [`21-tool-with-availability-constraints`](../examples/21-tool-with-availability-constraints.md)

package/catalog/frontmcp-auth-ui/references/custom-auth-ui.md

@@ -108,7 +108,7 @@ npm install @frontmcp/ui react react-dom
 
 ### React hooks + wrapper + client mount
 
-- **`useAuthFlow()`** — the flow-state fields above plus a `submitFinish` handler. `<form onSubmit={submitFinish}>` `preventDefault`s, serializes the form, attaches `pending_auth_id` + `csrf` + the slot marker, posts to the callback, and follows the OAuth redirect.
+- **`useAuthFlow()`** — the flow-state fields above plus a `submitFinish` handler. `<form onSubmit={submitFinish}>` `preventDefault`s, serializes the form, attaches `pending_auth_id` + `csrf` + the slot marker, and submits it to the callback as a real form navigation, so the browser follows the OAuth redirect.
 - **`useExtraField(name)`** — `{ onSubmit, result, pending }` for an `auth.extras` form. On success it merges the returned `addedItems` back into context.
 - **`useAddedItems(name)`** — the server-side accumulator for a named extra, reactively.
 - **`<AuthPageWrapper>`** — outer chrome that reads the injected state once, provides it via context, and (by default) renders the enclosing `<form>` with the `pending_auth_id` + `csrf` hidden fields so a no-JS submit still works. Pass `renderForm={false}` to supply your own forms.
@@ -131,7 +131,7 @@ There is **no `/oauth/ui/:slot.js` route** — the component is transpiled serve
 ## Security — the framework owns it
 
 - **CSRF**: the server mints a per-pending-authorization token, stores it (echoed into `csrfToken`), and verifies it on the finish submit and every `auth.extras` POST with a constant-time compare. Your component never generates or checks it.
-- **CSP + anti-clickjacking**: the auth-UI HTML ships with a strict CSP — `default-src 'self'; script-src 'self' 'unsafe-inline' https://esm.sh; connect-src 'self' https://esm.sh; style-src 'self' 'unsafe-inline' https://esm.sh; img-src 'self' data: https:; frame-ancestors 'none'; base-uri 'self'; form-action 'self'` — plus `X-Frame-Options: DENY`, `X-Content-Type-Options: nosniff`, `Referrer-Policy: no-referrer`. It allows `https://esm.sh` (deps) + `'unsafe-inline'` (the JSON-escaped state script) but **NOT `'unsafe-eval'`** — the transform is server-side, never in the browser.
+- **CSP + anti-clickjacking**: the auth-UI HTML ships with a strict CSP — `default-src 'self'; script-src 'self' 'unsafe-inline' https://esm.sh; connect-src 'self' https://esm.sh; style-src 'self' 'unsafe-inline' https://esm.sh; img-src 'self' data: https:; frame-ancestors 'none'; base-uri 'self'; form-action 'self' <redirect origin>` (the validated `redirect_uri`'s origin, plus the upstream authorization endpoints on the provider-selection page) — plus `X-Frame-Options: DENY`, `X-Content-Type-Options: nosniff`, `Referrer-Policy: same-origin` (a POST of the form carries its `Origin`, which the callback checks), `Cache-Control: no-store`. The finish submit is a POST (`submitMethod: 'POST'`). It allows `https://esm.sh` (deps) + `'unsafe-inline'` (the JSON-escaped state script) but **NOT `'unsafe-eval'`** — the transform is server-side, never in the browser.
 - **No PII**: the injected state carries OAuth client identifiers + control fields only.
 - **Fail-safe**: a component that can't be transpiled (missing / invalid `.tsx`) is logged (error cached so a broken file isn't retried each request) and **falls back to the built-in page** — a broken custom page can't take the server down.
 

package/catalog/frontmcp-authorities/SKILL.md

@@ -208,8 +208,9 @@ export default class SensitiveActionTool extends ToolContext { ... }
 
 For dynamic, async authorization that does not warrant a reusable custom evaluator, use the
 `guards` field. Each guard receives the same `AuthoritiesEvaluationContext` and returns
-`true` on grant, or `false`/a denial string on deny. Guards run in sequence and combine with
-other policy fields via `operator` (default AND).
+`true` on grant, or `false`/a denial string on deny. Only `true` grants: anything else
+(`undefined` from a guard that forgot to `return`, `null`, `0`, an object) denies. Guards run
+in sequence and combine with other policy fields via `operator` (default AND).
 
 ```typescript
 import type { AuthorityGuardFn } from '@frontmcp/auth';
@@ -293,8 +294,9 @@ authorities: {
 
 - **Deny on load/read** — loading a gated skill the caller can't access throws
   `AuthorityDeniedError` (MCP code `-32003`), the same as a denied `tools/call`.
-  Covers `skills/load` (MCP), `skill://<path>/SKILL.md` and `skill://<path>/<file>`
-  reads (SEP-2640), and `GET /skills/{id}` (HTTP).
+  Covers `skills/load` (MCP) and `skill://<path>/SKILL.md` and `skill://<path>/<file>`
+  reads (SEP-2640). Over HTTP, `GET /skills/{id}` answers 404 for such a skill, as
+  for an unknown one.
 - **Filter on discovery** — gated skills the caller can't access are removed from
   `skills/search` / `skills/list` (MCP), the `skill://index.json` discovery index and
   skill-path autocomplete (SEP-2640), and `GET /skills` (HTTP).
@@ -312,14 +314,35 @@ Two limitations to design around:
   filtering and will hide the skill from discovery. Use role/permission/claims
   authorities for discoverable skills; input-dependent policies still enforce at
   load time. (Same limitation applies to tools/resources/prompts.)
-- **HTTP skills discovery is fail-closed.** The Skills HTTP API uses a binary
-  api-key/bearer gate with no claims, so gated skills are hidden from `GET /skills`
-  and denied on `GET /skills/{id}` regardless of the bearer. Serve gated skills over
-  an MCP transport for claims-based access. Ungated skills are unaffected.
+- **HTTP skills discovery follows `skillsConfig.auth`.** With `'inherit'` (the default),
+  `GET /skills`, `/llm.txt` and `/llm_full.txt` run the server's own auth, and gated
+  skills are evaluated against the caller it verified. `'api-key'`, `'bearer'` and
+  `'public'` surface no claims, so there gated skills are left out of every listing and
+  `GET /skills/{id}` answers 404 for them. Ungated skills are unaffected.
 
 Boot-time fail-fast covers skills too: a `@Skill` with `authorities` but no configured
 authorities engine fails server startup with `AuthConfigurationError`, exactly like a
-tool/resource/prompt/agent.
+tool, resource, resource template, prompt, agent, or a tool declared inside an agent
+(hidden entries included).
+
+### Rules that check nothing are refused
+
+Startup fails with `AuthConfigurationError: Invalid authorities rule: …` when an entry's or a
+profile's rule checks nothing or isn't what it looks like, and `AuthoritiesEngine.evaluate()`
+denies such a rule if it runs anyway (even under `not`):
+
+- `{}`, `{ roles: {} }`, `{ roles: { all: [] } }`, `allOf: []`, `guards: []`
+- a misspelled field (`role:`), a profile name no profile has (`authorities: 'admn'`), a profile name inside
+  `allOf`/`anyOf`, an `operator` other than `'AND'`/`'OR'`
+- an ABAC condition with no `value`, or one the operator can't use: `exists` needs `true`/`false`;
+  `in`/`notIn` a non-empty list; `gt`/`gte`/`lt`/`lte` a number; `startsWith`/`endsWith`/`matches`
+  a string (a `{ fromInput }` / `{ fromClaims }` reference works for all but `exists`)
+
+To leave an entry open, remove its `authorities`. There is no opt-out.
+
+`@Agent({ authorities })` gates the agent's `invoke_<id>` tool like any tool (hidden from
+`tools/list`, refused on `tools/call`), and tools declared inside an agent are checked against
+the caller the agent runs for, also with `execution.useToolFlow: false`.
 
 ## Scenario Routing Table
 
@@ -379,7 +402,7 @@ tool/resource/prompt/agent.
 
 | Problem                                                                                   | Cause                                                                                                                                                                                     | Solution                                                                                                                                                                                     |
 | ----------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `profile 'admin' is not registered`                                                       | Profile used in decorator but not in `authorities.profiles` config                                                                                                                        | Add the profile to the `profiles` field in `@FrontMcp({ authorities })`                                                                                                                      |
+| Startup: `Invalid authorities rule: … names an unknown profile "admin"`                   | Profile used in decorator but not in `authorities.profiles` config                                                                                                                        | Fix the name, or add the profile to the `profiles` field in `@FrontMcp({ authorities })`                                                                                                     |
 | All users denied despite correct roles                                                    | `claimsMapping.roles` path does not match the actual JWT claim path                                                                                                                       | Decode a real JWT and verify the dot-path resolves to the roles array                                                                                                                        |
 | `authorities` field not recognized on decorator                                           | `@frontmcp/auth` not imported (metadata augmentation not active)                                                                                                                          | Add `import '@frontmcp/auth'` (or `import type ... from '@frontmcp/auth'`) anywhere in your project to activate the metadata augmentation. There is no `@frontmcp/auth/authorities` subpath. |
 | ABAC condition always fails                                                               | `{ fromInput: 'tenantId' }` but tool input field is named `tenant_id`                                                                                                                     | The `fromInput` key must exactly match the tool's input schema field name                                                                                                                    |

package/catalog/frontmcp-authorities/references/authority-profiles.md

@@ -62,7 +62,7 @@ export class MyServer {}
 
 ### Single Profile (String)
 
-The simplest form. The named profile's policy is evaluated. If the profile is not registered, the request is denied with `"profile 'name' is not registered"`.
+The simplest form. The named profile's policy is evaluated. A name no registered profile has stops the server at startup with `Invalid authorities rule: … names an unknown profile "name"`, alone or in a list of profiles.
 
 ```typescript
 @Tool({ name: 'delete_user', authorities: 'admin' })
@@ -253,7 +253,7 @@ The authorities system does not only enforce on execution. The built-in `filterB
 - `tools/list` only returns tools the current user is authorized to call
 - `resources/list` only returns resources the current user can read
 - `prompts/list` only returns prompts the current user can get
-- Skills are filtered on every discovery surface: `skills/search` / `skills/list`, the SEP-2640 `skill://index.json` index + skill-path autocomplete, and `GET /skills`. Loading a gated skill the caller can't access (via `skills/load`, a `skill://…` read, or `GET /skills/{id}`) is denied with `AuthorityDeniedError` (`-32003`).
+- Skills are filtered on every discovery surface: `skills/search` / `skills/list`, the SEP-2640 `skill://index.json` index + skill-path autocomplete, and `GET /skills`. Loading a gated skill the caller can't access via `skills/load` or a `skill://…` read is denied with `AuthorityDeniedError` (`-32003`); over HTTP, `GET /skills/{id}` answers 404, as for an unknown skill.
 
 This filtering happens automatically. No additional configuration is needed. Entries without an `authorities` field are always visible.
 
@@ -265,11 +265,17 @@ time, where input is available). For entries (especially **skills**) that must r
 discoverable, gate them with role/permission/claims-based authorities such as
 `authorities: 'admin'` or `{ roles: { any: ['admin'] } }`.
 
-**HTTP skills discovery is fail-closed.** The Skills HTTP API authenticates with a
-binary api-key/bearer gate that surfaces no JWT claims, so authority-gated skills are
-hidden from `GET /skills` and denied on `GET /skills/{id}` regardless of the bearer.
-Serve gated skills over an MCP transport (full claims context) for claims-based access;
-skills without `authorities` are served over HTTP unchanged.
+**HTTP skills discovery follows `skillsConfig.auth`.** With `'inherit'` (the default),
+`GET /skills`, `/llm.txt` and `/llm_full.txt` run the server's own auth, and gated skills
+are evaluated against the caller it verified. `'api-key'`, `'bearer'` and `'public'`
+surface no claims, so there authority-gated skills are left out of every listing and
+`GET /skills/{id}` answers 404 for them; skills without `authorities` are served over
+HTTP unchanged.
+
+**A profile must check something.** A profile whose rule checks nothing (`{}`,
+`{ roles: { all: [] } }`, a misspelled field, a profile name inside `anyOf`, an ABAC
+condition without a usable `value`) fails startup with `Invalid authorities rule: profile
+"<name>": …`, and the engine denies it.
 
 ## Profile Design Guidelines
 

package/catalog/frontmcp-authorities/references/rbac-abac-rebac.md

@@ -163,6 +163,8 @@ interface AbacCondition {
 
 An anonymous caller (public mode, `allowAnonymous`, or an `anon:` session) has no `user.sub`, even when `claimsMapping.userId` points at another claim, and a subject that is not a string counts as anonymous too, so `{ path: 'user.sub', op: 'exists', value: true }` admits signed-in callers only. A caller whose identity carries no `sub` at all gets the string `claimsMapping.userId` resolves to as its `user.sub`, when there is one, and so passes `exists`. When `claimsMapping.userId` resolves to something other than a string, a signed-in caller keeps its own `sub`. An expected value that resolves to nothing (for example a missing `fromInput` field) never satisfies `eq` or `match`, even when the actual value is missing too. A denied `tools/call` returns an error result with `_meta.code: 'AUTHORITY_DENIED'`.
 
+Every condition needs a `value` the operator can use: `exists` takes `true` or `false`, `in`/`notIn` a non-empty list, `gt`/`gte`/`lt`/`lte` a number, and `startsWith`/`endsWith`/`matches` a string; a `{ fromInput }` / `{ fromClaims }` reference works for all but `exists`. A condition without one (for example `{ path: 'user.sub', op: 'exists' }`, which would admit every caller without a `sub`) fails startup with `Invalid authorities rule`, and the engine denies it.
+
 ### Dynamic Value References
 
 Instead of hardcoding values, reference runtime data from tool input or JWT claims.

package/catalog/frontmcp-config/references/configure-auth-modes.md

@@ -86,9 +86,9 @@ Signing is **HS256 with a symmetric `JWT_SECRET`** (no key pair). Set a stable `
 
 Local mode also accepts `allowDefaultPublic` (default `false` — set `true` to admit tokenless requests as anonymous instead of returning 401), `anonymousScopes` (default `['anonymous']` — scopes for those anonymous sessions), and `expectedAudience` (reject tokens minted for a different `aud`).
 
-> **Client registration (security):** by default an unregistered `client_id` is accepted with whatever `redirect_uri` it presents. Set `requireRegisteredClients: true` (local/remote) to require every client to be registered (DCR / `dcr.clients`) or a CIMD client-id URL, so `redirect_uri` is exact-matched (OAuth 2.1) — this prevents auth-code interception via an attacker-chosen redirect. Confidential clients (`token_endpoint_auth_method: client_secret_basic`/`client_secret_post`) are authenticated with a constant-time `client_secret` check on both the code-exchange and refresh grants (Basic header or body param).
+> **Client registration (security):** `requireRegisteredClients` defaults to `true` (local/remote): every client must be registered (DCR / `dcr.clients`) or a CIMD client-id URL, so `redirect_uri` is exact-matched (OAuth 2.1) — this prevents auth-code interception via an attacker-chosen redirect. Set it to `false` only for local development. The server grants only the scopes in `allowedScopes` (default: the OpenID scopes). Confidential clients (`token_endpoint_auth_method: client_secret_basic`/`client_secret_post`) are authenticated with a constant-time `client_secret` check on both the code-exchange and refresh grants (Basic header or body param).
 
-> **Public origin (security):** pin `FRONTMCP_PUBLIC_URL` in production. The issuer / resource / OAuth-discovery URLs and the transparent expected audience derive from it rather than from request headers; `X-Forwarded-Host`/`X-Forwarded-Proto` are ignored unless `FRONTMCP_TRUST_PROXY=1` (a trusted proxy that strips client-supplied forwarded headers).
+> **Public origin (security):** pin `FRONTMCP_PUBLIC_URL` in production. The issuer / resource / OAuth-discovery URLs and the transparent expected audience derive from it rather than from request headers; `X-Forwarded-Host`/`X-Forwarded-Proto` are ignored unless `FRONTMCP_TRUST_PROXY=1` (a trusted proxy that strips client-supplied forwarded headers). The Web fetch handler (`createFetchHandler`, Workers) takes the address from the request URL, never from a `Host` header that disagrees with it.
 
 **Progressive / incremental authorization** (opt-in via `incrementalAuth`): when enabled, the minted token carries an `authorized_apps` claim and a `tools/call` for an app NOT in that claim resolves to a `CallToolResult` with `isError: true` and `_meta.code === 'AUTHORIZATION_REQUIRED'` (fields: `authorization_required: true`, `app`, `tool`, `auth_url`, `required_scopes`, `session_mode`, `supports_incremental`). The client declares the initial grant on `/oauth/authorize?…&apps=crm` (omit `apps` to grant all apps) and expands it later by **following the `auth_url` from the failed call** — that URL carries a framework-signed, single-use `ticket` naming the target app and the prior grant, and the new token's claim is the **union** of the prior apps plus the target (the user identity and already-granted apps are preserved; upstream tokens stay server-side). Do NOT hand-assemble `…&mode=incremental&app=slack`: since 1.7.2 (GHSA-2c4g-9c8x-6m8g) an authorize without a valid ticket is an ordinary login and runs the full credential gate, and `/oauth/callback` ignores an `incremental=true` parameter entirely. Single use is enforced with a conditional write against the configured session storage, so a **multi-instance deployment needs shared storage** (Redis, or any adapter supporting `ifNotExists`) for that guarantee to hold across instances; a backend without conditional writes (Cloudflare KV) degrades to an in-memory guard that holds within one instance only and warns at first use. Without an `incrementalAuth` block, no claim is minted and there is **no** app-level gating (allow-all preserved). `consent` (tool-level) and `incrementalAuth` (app-level) are independent.
 
@@ -141,6 +141,8 @@ Endpoints are derived from `provider` using standard OIDC paths
 non-standard IdPs, override them with
 `providerConfig.{authEndpoint,tokenEndpoint,userInfoEndpoint,jwksUri}`.
 
+> **MCP client registration (upgrade note):** `requireRegisteredClients` defaults to `true` in remote mode too (it was `false` in 1.8.2 and earlier). Remote mode has no `dcr` block (no pre-registered clients) and FrontMCP's own `/oauth/register` is off in production, so a production remote server with the defaults admits only MCP clients that use a CIMD client-id URL; an unregistered plain `client_id` gets a 400 `Unknown client_id` page. Migrate clients to CIMD, or set `requireRegisteredClients: false` for local development only (an unregistered client's `redirect_uri` can't be checked). FrontMCP grants only the scopes in `allowedScopes` (default: the OpenID scopes), unrelated to `scopes` (what it asks the IdP for).
+
 **Deferred (not yet wired):** upstream **Dynamic Client Registration**
 (`providerConfig.dcrEnabled` / `registrationEndpoint`) — a pre-registered
 `clientId` is required; and upstream **token auto-refresh** — once the upstream

package/catalog/frontmcp-config/references/configure-auth.md

@@ -140,7 +140,9 @@ Declare upstream providers to make multi-provider orchestration a turnkey local
 class Server {}
 ```
 
-`UpstreamProviderOptions` fields: `id` (required; used in `getToken(id)`), `authorizationEndpoint`/`authorizeUrl` (required), `tokenEndpoint`/`tokenUrl` (required), `clientId` (required), `clientSecret?`, `scopes?`, `name?`, `userInfoEndpoint?`, `jwksUri?`. The per-provider callback URL is auto-computed as `${issuer}/oauth/provider/${id}/callback` — register that URL with each provider.
+`UpstreamProviderOptions` fields: `id` (required; used in `getToken(id)`), `authorizationEndpoint`/`authorizeUrl` (required), `tokenEndpoint`/`tokenUrl` (required), `clientId` (required), `clientSecret?`, `scopes?`, `name?`, `userInfoEndpoint?`, `jwksUri?`, `issuer?`, `additionalIssuers?`. The per-provider callback URL is auto-computed as `${issuer}/oauth/provider/${id}/callback` — register that URL with each provider.
+
+The provider's identity comes from its `id_token` only when it verifies against `jwksUri` with `iss` = the provider's `issuer` (or `additionalIssuers`), `aud` containing `clientId`, and a valid `exp`. A provider with no `issuer` never has its `id_token` used (one IdP key set can sign many tenants' tokens); FrontMCP asks `userInfoEndpoint` instead, and with neither the sign-in fails. With `issuer` set, a callback whose RFC 9207 `iss` names another server gets a 400. Set `issuer` for OIDC providers.
 
 Tools read downstream tokens through the `this.orchestration` context extension (available in `local`/`remote` mode):
 
@@ -474,13 +476,14 @@ If the vault is not configured, accessing `this.authProviders` throws (`AuthProv
 
 ## Troubleshooting
 
-| Problem                                 | Cause                                                                          | Solution                                                                                                           |
-| --------------------------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------ |
-| `JWKS fetch failed` error on startup    | The `provider` URL is unreachable or does not serve `/.well-known/jwks.json`   | Verify the provider URL is correct and accessible from the server; check network/firewall rules                    |
-| Tokens rejected with `invalid audience` | The `expectedAudience` value does not match the `aud` claim in the token       | Align the `expectedAudience` config with the audience value your identity provider sets in tokens                  |
-| Sessions lost after server restart      | Using the default in-memory session store in production                        | Switch to Redis or Vercel KV session store via `configure-session` reference                                       |
-| Local-mode tokens invalid after restart | `JWT_SECRET` unset (random per-process secret) and/or `tokenStorage: 'memory'` | Set a stable `JWT_SECRET`; use `tokenStorage: { sqlite: { path } }` or `{ redis }` to persist codes/refresh tokens |
-| OAuth redirect fails in local dev       | `remote` mode requires HTTPS and reachable callback URLs                       | Set `NODE_ENV=development` to relax HTTPS requirements, or use a local OAuth mock server                           |
+| Problem                                       | Cause                                                                                                                                                                            | Solution                                                                                                                                                                      |
+| --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `JWKS fetch failed` error on startup          | The `provider` URL is unreachable or does not serve `/.well-known/jwks.json`                                                                                                     | Verify the provider URL is correct and accessible from the server; check network/firewall rules                                                                               |
+| Tokens rejected with `invalid audience`       | The `expectedAudience` value does not match the `aud` claim in the token                                                                                                         | Align the `expectedAudience` config with the audience value your identity provider sets in tokens                                                                             |
+| Sessions lost after server restart            | Using the default in-memory session store in production                                                                                                                          | Switch to Redis or Vercel KV session store via `configure-session` reference                                                                                                  |
+| Local-mode tokens invalid after restart       | `JWT_SECRET` unset (random per-process secret) and/or `tokenStorage: 'memory'`                                                                                                   | Set a stable `JWT_SECRET`; use `tokenStorage: { sqlite: { path } }` or `{ redis }` to persist codes/refresh tokens                                                            |
+| OAuth redirect fails in local dev             | `remote` mode requires HTTPS and reachable callback URLs                                                                                                                         | Set `NODE_ENV=development` to relax HTTPS requirements, or use a local OAuth mock server                                                                                      |
+| Sign-in refused: "started in another browser" | The sign-in binding cookie is missing: `frontmcp_signin_<id>`, or `__Host-frontmcp_signin_<id>` over https (only that name counts there, so a sibling subdomain cannot plant it) | Start and finish the sign-in in one browser with cookies on, at the issuer's host; behind a proxy, pin `FRONTMCP_PUBLIC_URL` and forward `x-forwarded-proto` on every request |
 
 ## Examples
 

package/catalog/frontmcp-config/references/configure-skills-http.md

@@ -98,6 +98,19 @@ explicitly to opt out of authentication; use `'api-key'` or `'bearer'` to
 override the inherited policy with a Skills-specific one. **In production,
 set `auth` explicitly so the policy is visible at the call site.**
 
+With `'inherit'`, `/skills`, `/llm.txt` and `/llm_full.txt` need the same credential
+as the MCP endpoint (401/403 otherwise; only a public-mode server lets everyone in),
+and skills with `authorities` are listed only for a caller whose verified claims
+satisfy them. The other modes surface no claims, so gated skills are never served
+over HTTP there, and `GET /skills/<gated id>` answers 404.
+
+Custom routes that guard skills content should call `authorizeSkillHttpRequest(scope,
+skillsConfig, request)` from `@frontmcp/sdk`, which covers every mode.
+`createSkillHttpAuthValidator()` is only for an explicit `'api-key'` or `'bearer'`
+(it returns `null` only for `'public'`); its validator only sees headers, so it
+refuses every request under `'inherit'` or an unset `auth`, and code that treated
+`null` as "no auth needed" must switch to `authorizeSkillHttpRequest`.
+
 ## Skills HTTP Caching
 
 ```typescript

package/catalog/frontmcp-deployment/references/build-for-browser.md

@@ -57,6 +57,23 @@ Not all FrontMCP features are available in browser environments:
 | Crypto (`@frontmcp/utils`)  | Yes             | Uses WebCrypto API                        |
 | Direct client (`connect()`) | Yes             | In-memory connection                      |
 
+### Request context in the browser
+
+A browser has no `AsyncLocalStorage`. Unless the runtime provides TC39 `AsyncContext`
+(`getAsyncContextMode()` from `@frontmcp/utils` is then `'native'`), the browser build runs
+requests one at a time (`'serialized'`) so a request never reads another request's session, auth
+info or running tool:
+
+- `DirectMcpServer` calls, `connect()` clients and `createFetchHandler` requests take turns. A
+  request keeps its turn until it returns and everything it started has unwound; background jobs,
+  workflows and tasks take their own turn afterwards.
+- A request waiting on its client (elicitation, `roots/list`) steps aside while it waits.
+- Concurrent tool calls inside one request (`Promise.all`) are refused with
+  `AsyncContextOverlapError` once they overlap. Run them one after another.
+- A tool must not call its own server through a `DirectClient`/`DirectMcpServer` (it waits for its
+  own turn); use `this.scope` flows. A request that waits more than 10s for its turn logs why.
+- Timers and un-awaited promises must not read request context.
+
 ## Usage with @frontmcp/react
 
 The browser build is commonly paired with `@frontmcp/react` for React applications. `FrontMcpProvider` takes a pre-created `DirectMcpServer` (via the SDK's `create()` factory) — not a `serverUrl`. Hooks for listing/invoking are `useListTools` / `useCallTool`:
@@ -159,6 +176,8 @@ ls dist/browser/
 | CORS errors on tool calls   | MCP server missing CORS headers           | Configure CORS middleware on the MCP server                      |
 | Bundle too large            | All server-side code included             | Use `--target browser` and a dedicated client entry file         |
 | `@frontmcp/utils` fs throws | File system ops called in browser         | Remove fs calls; use API endpoints or in-memory alternatives     |
+| `AsyncContextOverlapError`  | Concurrent tool calls inside one request  | Await the calls one after another (no `AsyncContext` in browser) |
+| A call never returns        | A tool calls its own server via a client  | Call other tools through `this.scope` flows                      |
 
 ## Examples
 

package/catalog/frontmcp-deployment/references/deploy-to-cloudflare-skills-only.md

@@ -27,6 +27,13 @@ short AgentScript program in the Worker isolate, where each `callTool(actionId,
 input)` invokes a loaded skill's operation. The bundle is pulled from a SaaS
 endpoint, cached in KV, and refreshed on a Cron Trigger.
 
+The meta-tools only show what the caller may use: a skill whose
+`requiredAuthorities` the caller doesn't satisfy is left out of `search_skill`
+(and its catalog) and is `SKILL_NOT_FOUND` for `load_skill`, and `load_skill`
+leaves out actions the caller can never run. When the server configures
+`authorities`, bundle rules are evaluated with the server's engine (its
+`claimsMapping`, resolvers and custom evaluators).
+
 For the conceptual picture, see [Skills-Only Deployment](https://docs.agentfront.dev/frontmcp/features/skills-only-deployment).
 For the production-ready decorator build, see [`deploy-to-cloudflare.md`](./deploy-to-cloudflare.md).
 
@@ -53,6 +60,8 @@ For the production-ready decorator build, see [`deploy-to-cloudflare.md`](./depl
 
 ```ts
 // worker.ts — the real API is createEdgeMcp (not createWorker)
+import { env } from 'cloudflare:workers';
+
 import { createEdgeMcp, kvBundleCacheFromEnv } from '@frontmcp/edge';
 
 export default createEdgeMcp({
@@ -61,7 +70,10 @@ export default createEdgeMcp({
   tasks: { enabled: false },
   managed: {
     endpoint: 'https://cloud.example.com/v1/bundles/acme',
-    authToken: 'pinned-pull-token',
+    // The pull JWT the SaaS issued for this server (iss = expectedIssuer, aud includes
+    // expectedAudience, with exp), kept in a Worker secret:
+    //   npx wrangler secret put FRONTMCP_PULL_TOKEN
+    authToken: env.FRONTMCP_PULL_TOKEN,
     expectedAudience: 'acme-mcp',
     jwksUrl: 'https://cloud.example.com/.well-known/jwks.json',
     expectedIssuer: 'https://cloud.example.com',
@@ -79,6 +91,15 @@ The pull sends `authToken` as a bearer token and never follows a redirect, so
 `endpoint` must serve the bundle directly; a 3xx (or a status-0
 `opaqueredirect`) fails the pull.
 
+Before every pull, `authToken` itself is verified: it must be a JWT signed by a
+key served at `jwksUrl` (fetched without the token, redirects refused), with
+`iss` equal to `expectedIssuer`, an `aud` that includes `expectedAudience` (and
+a `resource` claim that does too, when it has one), and not expired. A token
+that fails is refused with `[saas-source] pull token rejected: …`: nothing is
+pulled, and the KV cache is **not** used in its place. An unreachable JWKS, or
+one with no usable signing key (no RSA, EC or OKP public key for signatures),
+counts as an ordinary pull failure, so the cache fallback still applies.
+
 This path is bundled by **wrangler** (not `frontmcp build`), so you maintain
 `wrangler.toml` yourself — it needs a `[[kv_namespaces]] binding = "BUNDLE_CACHE"`
 and a `[triggers] crontabs = [...]` (the `managed.pollIntervalMs` option is

package/catalog/frontmcp-deployment/references/deploy-to-cloudflare.md

@@ -178,6 +178,10 @@ Because `[vars]` reach `process.env`, `npx wrangler dev` sees the same `NODE_ENV
 
 Background tasks need a store that outlives a single request and is shared between isolates, which an edge runtime cannot provide in-process. FrontMCP disables them automatically when no distributed store is configured, and the worker serves normally without them — no `tasks: { enabled: false }` opt-out is needed. `tasks: { enabled: true }` without `tasks.redis` fails the build rather than the deployed worker.
 
+### Startup checks
+
+The server is built on its first request, but the checks the config's metadata settles run when the module evaluates, so `createEdgeMcp` throws and the worker fails to deploy: an `approval` or `featureFlag` field no plugin that reaches the entry enforces (`UnenforcedMetadataError`), or `authorities` without the `authorities` option (`AuthConfigurationError`). A plugin installed on an app reaches only that app's entries, unless one of its hooks is `appliesTo: 'uncovered-apps'` as the built-in approval and feature-flag plugins' are. A tool declared inside an `@Agent` is reached only by that agent's plugins (none with `execution.useToolFlow: false`), and an agent's plugins reach nothing else. The remaining checks run when the first request builds the server.
+
 ## Step 5: Deploy
 
 ```bash
@@ -269,6 +273,10 @@ new_classes = ["FrontMcpSession"]
 
 One DO per session holds a persistent transport so the `GET` notification stream stays open and `tools/call` notifications reach it. It runs the **same `http:request` flow** (auth/session:verify/router/audit/metrics + hooks) as the stateless path — so transparent auth returns `401` + `WWW-Authenticate` on the worker too.
 
+A session belongs to the caller that opened it: the `Mcp-Session-Id` only addresses the DO, so the flow's `checkPersistentSessionOwner` stage binds the session to the caller of its first request (verified issuer + subject, else its token) and answers anyone else with `404 Session not found` on `POST`, `GET` and `DELETE`, before every protocol handler (2026-07-28 included). The owner is kept in the DO's `state.storage`, so a DO rebuilt after eviction still refuses strangers. On a public server (anonymous callers, no token) the unguessable session id is the only credential. The owner ends its session with `DELETE`.
+
+OAuth sign-in works on the worker too, including `/oauth/provider/:providerId/callback` (a federated provider's redirect and the federated consent submission): path parameters are matched like Express.
+
 ## Storage Options
 
 | Storage       | Use Case                      | Notes                             |

package/catalog/frontmcp-development/examples/openapi-adapter/authenticated-adapter-with-polling.md

@@ -20,8 +20,11 @@ Demonstrates configuring authentication (API key and bearer token) and automatic
 
 ```typescript
 // src/server.ts
-import { FrontMcp, App } from '@frontmcp/sdk';
 import { OpenapiAdapter } from '@frontmcp/adapters';
+import { App, FrontMcp } from '@frontmcp/sdk';
+
+// Your code: returns a token issued for the upstream API (secrets manager, token exchange, ...)
+declare function getEvolvingApiToken(ctx: unknown): Promise<string>;
 
 @App({
   name: 'integrations',
@@ -51,8 +54,9 @@ import { OpenapiAdapter } from '@frontmcp/adapters';
       name: 'evolving-api',
       url: 'https://api.example.com/openapi.json',
       baseUrl: 'https://api.example.com',
-      securityResolver: (tool, ctx) => {
-        return { jwt: ctx.authInfo?.token };
+      securityResolver: async (tool, ctx) => {
+        // A credential issued for this API (never the caller's own ctx.authInfo.token)
+        return { jwt: await getEvolvingApiToken(ctx) };
       },
       polling: {
         intervalMs: 300000, // Re-fetch spec every 5 minutes

package/catalog/frontmcp-development/references/create-plugin-hooks.md

@@ -190,11 +190,13 @@ Both `@Will` and `@Did` (and `@Around`) accept an optional options object:
 @Will('execute', {
   priority: 10,                          // Lower runs first (default: 0)
   filter: (ctx) => ctx.toolName !== 'health_check',  // Predicate to skip
+  appliesTo: 'own-app',                  // Reach of an app plugin's hook (default: 'own-app')
 })
 ```
 
 - **priority** (`number`) - Execution order when multiple hooks target the same stage. Lower values run first, for `@Will`, `@Did` and `@Around` alike. Default: `0`.
 - **filter** (`(ctx) => boolean`) - A predicate that receives the flow context. Return `false` to skip this hook for the current invocation.
+- **appliesTo** (`'own-app' | 'uncovered-apps'`) - A hook of a plugin installed on an app runs, in `tools/call`, `resources/read`, `prompts/get` and `completion/complete`, only for that app's entries (`'own-app'`). With `'uncovered-apps'` it also runs for the entries of any app that has no instance of the same hook (same class and method) of its own or from a server-level plugin. Use it for gates an entry's metadata asks for (approval, feature flags), so the entry is not left ungated when the plugin sits on another app. Server-level plugins' hooks, and list-flow hooks, already run for every app.
 
 ## Examples
 

package/catalog/frontmcp-development/references/create-provider.md

@@ -104,6 +104,13 @@ export const databaseProvider = AsyncProvider({
 });
 ```
 
+`scope` is `ProviderScope.GLOBAL` (the default: one instance per process/worker, right for
+pools and clients) or `ProviderScope.CONTEXT` (one instance per request). A client that opens a
+session (MCP before 2026-07-28) keeps one CONTEXT instance for the session the server verified;
+any other caller, such as one with a token under 2026-07-28, gets new instances on every request,
+never another caller's. State that must outlive a request belongs in a GLOBAL provider or in
+storage keyed by the caller's identity.
+
 ## Step 3: Register in @App or @FrontMcp
 
 ```typescript

package/catalog/frontmcp-development/references/official-plugins.md

@@ -160,8 +160,9 @@ One policy decides every CodeCall surface: `codecall:search`, `codecall:describe
 ```typescript
 CodeCallPlugin.init({
   mode: 'codecall_only',
-  // `tool` is { name, appId, source, description, tags }; `name` is the tool's own name, never `<appId>:<name>`
-  includeTools: (tool) => !tool.name.startsWith('admin:'),
+  // `tool` is { name, fullName, appId, source, description, tags, annotations, metadata }, read-only;
+  // `name` is the tool's own name, never `<appId>:<name>`
+  includeTools: (tool) => !tool.name.startsWith('admin:') && !tool.annotations?.destructiveHint,
   directCalls: {
     enabled: true,
     allowedTools: ['users:list', 'crm:users:get'], // bare name, or `<appId>:<name>` to pin one app
@@ -174,6 +175,9 @@ CodeCallPlugin.init({
 - `codecall:searchSkills` and `codecall:searchKnowledge` run the SDK's `skills:filter` flow, so a skill a plugin withholds there (a flag-disabled skill, for one) is absent from both.
 - `directCalls.allowedTools` and `directCalls.filter` only narrow the base policy; listing a withheld tool does not make it callable. Unlisted tools are refused.
 - Hiding a tool from search is not the control; the refusal at execution is. Do not rely on `visibleInListTools` or search ranking to protect a tool.
+- `includeTools` and `directCalls.filter` receive the same object, with the tool's `annotations` and declared `metadata` (`tool.metadata?.annotations` is the same object as `tool.annotations`). It is a deep read-only copy, so a filter cannot change what the next decision reads.
+- Namespace bindings (`mail.send({...})` for a tool named `mail.send`) are AgentScript wrappers over `callTool()` inside the sandbox: they count toward `vm.maxSteps` and pass the rate limit and suspicious-sequence checks exactly like `callTool('mail.send', {...})`. A binding with no argument sends `{}`.
+- `codecall:execute` results never include a `stack`, in any environment. In `runtime_error`, `syntax_error` and `tool_error` messages, stack frames are dropped and absolute paths (POSIX, Windows, UNC, `file:` URLs, quoted paths) become `[path]`; other URLs are kept.
 
 ### Power Features
 
@@ -277,17 +281,21 @@ class MyTool extends ToolContext {
 
 ### Memory Scopes
 
-- `session` -- Valid only for the current session. Default scope. Cleared when the session ends.
+- `session` -- Default scope. With a verified session, valid only for that session and cleared
+  when it ends. Without one (stateless transport, MCP 2026-07-28), it belongs to the authenticated
+  principal and lasts across that principal's requests until its TTL, not per request.
 - `user` -- Persists for the user across sessions. Tied to user identity.
-- `tool` -- Scoped to a specific tool + session combination. Isolated per tool.
+- `tool` -- Scoped to a specific tool plus the same identity as `session` (the verified session,
+  else the authenticated principal). Isolated per tool.
 - `global` -- Shared across all sessions and users. Use carefully.
 
-**`session`, `tool`, and `user` scopes require a per-client identity.** A stateless HTTP
-transport injects the same session id (`__stateless__`) into every request, so it carries no
-session identity. `session` and `tool` scope fall back to the authenticated principal, and an
-unauthenticated stateless request is refused with a `RememberIdentityError` rather than given
-a namespace shared with every other client. `user` scope is refused with no authenticated
-user. If the data really is shared, use `scope: 'global'`.
+**`session`, `tool`, and `user` scopes require a per-client identity.** `session` and `tool`
+memory belong to the session the server verified, never to an `mcp-session-id` the client merely
+sends. A stateless HTTP transport (shared `__stateless__` id), MCP 2026-07-28 (no sessions) and an
+unverified `mcp-session-id` carry no session identity: `session` and `tool` scope fall back to the
+authenticated principal, and an unauthenticated request without a verified session is refused
+with a `RememberIdentityError` rather than given a namespace shared with other clients. `user`
+scope is refused with no authenticated user. If the data really is shared, use `scope: 'global'`.
 
 **Set `REMEMBER_SECRET` on every instance that shares a store.** All scopes, `session` and
 `tool` included, derive their encryption key from that secret plus the scope identity. A
@@ -405,11 +413,14 @@ authInfo.extra.approvalContext = { type: 'project', identifier: resolvedProjectI
 ### How the check decides
 
 1. `skipApproval: true`, or approval not required: the tool runs.
-2. A recorded **denial** for the caller (session or user scope): refused with state `denied`. A
-   denial outranks pre-approved contexts and any session approval.
+2. A recorded **denial** for the caller (session, user, time-limited or context scope): refused
+   with state `denied`. A denial outranks pre-approved contexts and any approval.
 3. The session context is one of `preApprovedContexts`: the tool runs.
 4. `alwaysPrompt: true`: refused with state `pending`.
-5. A valid approval for the caller: the tool runs.
+5. An approval for the caller that the tool's policy accepts: the tool runs. The caller's session,
+   user, time-limited and context approvals all count (a context approval only when the session
+   carries that context); its scope must be in `allowedScopes`, and it must be younger than
+   `maxTtlMs`, however it was stored.
 6. Otherwise refused with state `pending` (or `expired`).
 
 A refused call throws `ApprovalRequiredError`; the client receives an error result.
@@ -427,9 +438,12 @@ cannot hold a session approval. Releases up to 1.8.1 keyed a request without `mc
 its per-request id, so the grant was never found again
 ([#597](https://github.com/agentfront/frontmcp/issues/597)).
 
-Installed on an app, `ApprovalPlugin` gates only that app's tools (including those its adapters
-and plugins provide) against its own store, so two apps can each install it with separate stores.
-Installed on the server, it gates every tool; a tool both gate must pass each store's check.
+Installed on an app, `ApprovalPlugin` gates that app's tools (including those its adapters and
+plugins provide) against its own store, so two apps can each install it with separate stores. It
+also gates, against its store, the `approval` tools of apps with no approval plugin of their own,
+so such a tool never runs ungated because the plugin sits on another app (releases up to 1.8.2 ran
+them for anyone). Installed on the server, it gates every tool; a tool several plugins gate must
+pass each store's check, and a denial in any of them refuses the call.
 `this.approval` resolves the `ApprovalService` of the nearest `ApprovalPlugin` -- the one the
 tool's own app installed, otherwise the server's -- so with two apps each installing it, a grant
 or check in one app's tool uses that app's store. Releases up to 1.8.1 resolved the store of the
@@ -456,8 +470,11 @@ class DangerousActionTool extends ToolContext {
     // await this.approval.getSessionApprovals()            -- List session approvals
     // await this.approval.getUserApprovals()                -- List user approvals
     // await this.approval.grantUserApproval('tool-id')     -- Persist across sessions
-    // await this.approval.grantTimeLimitedApproval('tool-id', 60000)  -- Auto-expire
-    // await this.approval.revokeApproval('tool-id')        -- Revoke any approval
+    // await this.approval.grantTimeLimitedApproval('tool-id', 60000)  -- Auto-expire (ttlMs > 0)
+    // await this.approval.revokeApproval('tool-id')        -- Revoke the caller's session, user,
+    //                                                         time-limited and context approvals;
+    //                                                         returns whether any was revoked
+    //                                                         (recorded denials are kept)
 
     return { content: [{ type: 'text', text: 'Action completed' }] };
   }
@@ -477,6 +494,8 @@ import { ApprovalScope } from '@frontmcp/plugin-approval';
     category: 'write',
     riskLevel: 'medium', // 'low' | 'medium' | 'high' | 'critical'
     approvalMessage: 'Allow file writing for this session?',
+    allowedScopes: [ApprovalScope.SESSION, ApprovalScope.TIME_LIMITED],
+    maxTtlMs: 60 * 60 * 1000,
   },
 })
 class FileWriteTool extends ToolContext {
@@ -484,6 +503,12 @@ class FileWriteTool extends ToolContext {
 }
 ```
 
+- `allowedScopes` is enforced: granting another scope through `this.approval` throws
+  `ApprovalScopeNotAllowedError`, and a stored approval of another scope does not open the gate.
+- `maxTtlMs` is enforced: a longer `grantTimeLimitedApproval()` throws `ApprovalOperationError`,
+  grants without a TTL get `maxTtlMs`, and no approval counts beyond `grantedAt + maxTtlMs`.
+- A `ttlMs` of 0, a negative number, `NaN` or `Infinity` throws, and a time-limited grant needs one.
+
 When `approval.required` is `true`, the plugin automatically intercepts tool execution and checks approval status before allowing the tool to run.
 
 ---
@@ -770,7 +795,7 @@ The `toolName` completion of `ui://widget/{toolName}.html` runs the caller's `to
 
 The skill catalog in the `initialize` instructions (and the SEP-2640 `skill://` hints under `skillsConfig.sep2640InInstructions`) is filtered for the initializing client too, so a flag-disabled skill's name and description never appear there ([#603](https://github.com/agentfront/frontmcp/issues/603)). A skill's `skill://<path>/SKILL.md` entry in `resources/list` is gated by the skill that path serves now -- replace a skill at the same path and the entry takes the new skill's flag ([#606](https://github.com/agentfront/frontmcp/issues/606)).
 
-Installed on an `@App`, the gates cover every capability that app provides, including tools, resources and prompts contributed by its adapters (e.g. an OpenAPI adapter) and plugins. Its tool, resource, prompt and completion gates do not run for other apps' capabilities -- install it in `@FrontMcp({ plugins })` to gate every app. Resources and prompts served outside every app (the SEP-2640 `skill://` resources) are gated by every installed copy. Skills are gated through the `skills:filter` flow, which every skill surface runs -- as the calling user on every transport, stdio and in-memory included; custom plugins can hook `Did('filterSkills')` on it the same way, and reuse `filterServableSkills(scope, skills)` from `@frontmcp/sdk` to serve skills from a surface of their own.
+Installed on an `@App`, the gates cover every capability that app provides, including tools, resources and prompts contributed by its adapters (e.g. an OpenAPI adapter) and plugins. Its tool, resource, prompt and completion gates also cover the flagged capabilities of apps with no feature-flag plugin of their own, but not those of an app that installs its own -- install it in `@FrontMcp({ plugins })` to gate every app with one adapter. Listings follow the same copy of the plugin as the gates (a plugin on each of two apps decides each app's entries, listed and served, with that app's flags); up to 1.8.3 every copy filtered every app's listings. Releases up to 1.8.2 hid another app's flagged-off tool from `tools/list` but still ran it when called by name. Resources and prompts served outside every app (the SEP-2640 `skill://` resources) are gated by every installed copy. Skills are gated through the `skills:filter` flow, which every skill surface runs -- as the calling user on every transport, stdio and in-memory included; custom plugins can hook `Did('filterSkills')` on it the same way, and reuse `filterServableSkills(scope, skills)` from `@frontmcp/sdk` to serve skills from a surface of their own.
 
 ---
 
@@ -819,7 +844,7 @@ interface DashboardPluginOptionsInput {
   basePath?: string; // Default: '/dashboard'
   auth?: {
     enabled?: boolean; // Default: false
-    token?: string; // Query param auth (?token=xxx)
+    token?: string; // Bearer / x-frontmcp-dashboard-token; ?token=xxx for the page only
   };
   cdn?: {
     entrypoint?: string; // Custom UI bundle URL
@@ -831,9 +856,9 @@ interface DashboardPluginOptionsInput {
 }
 ```
 
-- `enabled` -- When omitted, the dashboard is automatically enabled in development (`NODE_ENV !== 'production'`) and disabled in production.
-- `basePath` -- URL path where the dashboard is served. Default: `'/dashboard'`.
-- `auth.enabled` / `auth.token` -- Gate the dashboard page on a shared secret. Present it as `Authorization: Bearer <token>` (preferred) or `?token=<value>`. `enabled: true` without a `token` is a **startup error** — the server refuses to boot rather than serve an "authenticated" dashboard with nothing to check. The token is compared in constant time and is never embedded in the served page.
+- `enabled` -- When omitted, the dashboard is automatically enabled in development (`NODE_ENV !== 'production'`) and disabled in production. Disabled means disabled everywhere: the page and the dashboard's MCP endpoint answer 404, and its tools refuse with `DASHBOARD_DISABLED` on every transport (`createDirect` and stdio included). To keep the dashboard in production, set `enabled: true` with `auth`.
+- `basePath` -- URL path where the dashboard page is served. Default: `'/dashboard'`. The page's MCP client talks to the dashboard app's own route (`/dashboard`, after the server's `entryPath`), which `basePath` does not move.
+- `auth.enabled` / `auth.token` -- Gate the dashboard on a shared secret: the page, its MCP endpoint and its tools. The page takes `Authorization: Bearer <token>` (preferred) or `?token=<value>`, and sets an HttpOnly `SameSite=Strict` cookie (an HMAC of the token, never the token) that its own MCP client uses. MCP clients send `Authorization: Bearer <token>`, or `x-frontmcp-dashboard-token: <token>` when the server's own auth uses `Authorization`; `?token=` is refused there. Without the token the MCP endpoint answers 401 (`WWW-Authenticate: Bearer realm="frontmcp-dashboard"`). `enabled: true` without a `token` is a **startup error** — the server refuses to boot rather than serve an "authenticated" dashboard with nothing to check. The token is compared in constant time and is never embedded in the served page.
 - `cdn` -- Override default CDN URLs for the dashboard UI bundle and its dependencies. Useful for air-gapped environments.
 
 ### Security
@@ -843,12 +868,12 @@ interface DashboardPluginOptionsInput {
 The dashboard's MCP scope **inherits the server's authentication**. Its introspection tools (`dashboard:graph`, `dashboard:list-tools`, `dashboard:list-resources`) reach the root scope and enumerate every app, tool, resource and prompt on the server — including names, descriptions and (on request) schemas. Two consequences:
 
 - On an authenticated server (`local`, `remote`, `transparent`, `orchestrated`), the dashboard requires the same credential as everything else.
-- On a **public** server the dashboard is public too, because the server is. `auth.token` gates the dashboard _page_, not the MCP scope or the SSE stream. If the inventory is sensitive, authenticate the server — do not rely on the dashboard token alone.
+- On a **public** server, `auth.token` is what keeps the inventory private: it gates the page, the dashboard's MCP endpoint (SSE stream and POSTs included) and the tools. Releases up to 1.8.2 gated only the page, answered MCP with the dashboard disabled, and pointed the page at `<basePath>/sse`.
 
 Three further limitations worth knowing:
 
-- **The bundled page cannot authenticate itself against a non-public server.** The browser client opens `EventSource(sseUrl)` and POSTs with no `Authorization` header, and the SDK reads the credential from that header only. So on a server with `local`/`remote`/`transparent`/`orchestrated` auth the page loads (its own token gates that) but the in-page graph, tool list and SSE stream get `401`. Run the dashboard on a public/development server, or put it behind a proxy that injects a credential — scoped to the dashboard's own routes (`<basePath>/sse` and `<basePath>/message`) and holding no grant beyond the dashboard scope, since injecting a server credential across the MCP endpoint would let any page on that origin issue arbitrary authenticated JSON-RPC. Failing closed here is deliberate — the alternative is the `mode: 'public'` scope that GHSA-rgxj-434m-vxh3 was about.
-- The token is accepted as `Authorization: Bearer <token>` (scheme matched case-insensitively) or `?token=`. Prefer the header: a URL token lands in browser history, `Referer` headers and access logs. There is no cookie/session option yet.
+- **The bundled page cannot authenticate itself against a non-public server.** Its cookie carries the dashboard token only; the browser client opens `EventSource(sseUrl)` and POSTs with no `Authorization` header, and the server's own authentication reads its credential from that header. So on a server with `local`/`remote`/`transparent`/`orchestrated` auth the page loads but the in-page graph, tool list and SSE stream get `401`. Run the dashboard on a public/development server, or put it behind a proxy that injects a credential — scoped to the dashboard's own MCP routes (`/dashboard/sse` and `/dashboard/message`, after the server's `entryPath`) and holding no grant beyond the dashboard scope, since injecting a server credential across the MCP endpoint would let any page on that origin issue arbitrary authenticated JSON-RPC. Failing closed here is deliberate — the alternative is the `mode: 'public'` scope that GHSA-rgxj-434m-vxh3 was about.
+- The token is accepted as `Authorization: Bearer <token>` (scheme matched case-insensitively), as `x-frontmcp-dashboard-token` on the MCP endpoint, through the page's cookie, and as `?token=` for the page only. Prefer a header: a URL token lands in browser history, `Referer` headers and access logs.
 - Dashboard options are **process-wide**. Two `@FrontMcp` servers built in one process that configure the dashboard with CONFLICTING auth now throw at registration rather than silently sharing the last token; a differing `basePath` or `cdn` logs a warning. Run one dashboard per process, or call `resetDashboardOptions()` between serial constructions.
 
 ---

package/catalog/frontmcp-development/references/openapi-adapter.md

@@ -89,8 +89,9 @@ OpenapiAdapter.init({
   name: 'my-api',
   url: 'https://api.example.com/openapi.json',
   baseUrl: 'https://api.example.com',
-  securityResolver: (tool, ctx) => {
-    return { jwt: ctx.authInfo?.token };
+  securityResolver: async (tool, ctx) => {
+    // A credential issued for the API, never the caller's own ctx.authInfo.token
+    return { jwt: await getApiToken(ctx) };
   },
 });
 
@@ -110,17 +111,33 @@ OpenapiAdapter.init({
   url: 'https://api.example.com/openapi.json',
   baseUrl: 'https://api.example.com',
   headersMapper: (ctx, headers) => {
-    headers.set('Authorization', `Bearer ${ctx.authInfo?.token}`);
+    const tenantId = ctx.authInfo.user?.tenantId;
+    if (tenantId) headers.set('x-tenant-id', tenantId);
     return headers;
   },
 });
+
+// Opt-in token passthrough (High Risk) — only when the API accepts tokens issued for this MCP server
+OpenapiAdapter.init({
+  name: 'same-issuer-api',
+  url: 'https://api.example.com/openapi.json',
+  baseUrl: 'https://api.example.com',
+  passthroughCallerToken: true,
+});
 ```
 
-| Risk Level | Strategy                                   | Description                                          |
-| ---------- | ------------------------------------------ | ---------------------------------------------------- |
-| LOW        | `authProviderMapper` or `securityResolver` | Auth from user context, not exposed to clients       |
-| MEDIUM     | `staticAuth`, `additionalHeaders`          | Static credentials                                   |
-| HIGH       | `includeSecurityInInput: true`             | Auth fields exposed to MCP clients (not recommended) |
+With no `authProviderMapper`, `securityResolver` or `staticAuth`, the adapter sends **no** credentials: operations that require auth fail with `Authentication required for tool '…'` and a `SECURITY WARNING` is logged at startup. The caller's MCP token (`ctx.authInfo.token`) is never forwarded implicitly — not by default, and not when an `authProviderMapper` function returns `undefined` — because passing it to another API is token passthrough, which the MCP specification forbids. `passthroughCallerToken: true` is the explicit opt-in, used only after every other credential source came up empty.
+
+| Risk Level | Strategy                                                    | Description                                          |
+| ---------- | ----------------------------------------------------------- | ---------------------------------------------------- |
+| LOW        | `authProviderMapper` or `securityResolver`                  | Auth from user context, not exposed to clients       |
+| MEDIUM     | `staticAuth`, `additionalHeaders`, or none                  | Static credentials, or no credentials at all         |
+| HIGH       | `includeSecurityInInput: true`, or `securitySchemesInInput` | Auth fields exposed to MCP clients (not recommended) |
+| HIGH       | `passthroughCallerToken: true`                              | The MCP client's own token is sent to the API        |
+
+`passthroughCallerToken: true` scores HIGH alongside an `authProviderMapper` too (the token is sent when no mapper function returns a credential); only a `securityResolver` or a non-empty `staticAuth` leaves it unused.
+
+Resolution order: `securityResolver` → `authProviderMapper` → `staticAuth` (fills every credential no mapper function returned; a mapped value wins) → `passthroughCallerToken`. A security scheme with no `authProviderMapper` entry is refused at startup unless `staticAuth` covers it, `additionalHeaders` carries its credential, `headersMapper` may set it (a header or cookie scheme, checked on each request), or `passthroughCallerToken` does for an HTTP bearer scheme (it sends the caller's token for it and logs a `SECURITY WARNING`; the caller's token never fills an API key, basic, OAuth2 or OpenID Connect scheme). An operation that requires auth is sent only with a credential for one of its own schemes, from a credential option, the tool input (`securitySchemesInInput`, `includeSecurityInInput`), `additionalHeaders` or `headersMapper`; otherwise it fails with `Authentication required for tool '…'`. A tool-input credential is used for a scheme only when no other source supplies one (a server credential always wins).
 
 ## Spec Polling
 

package/catalog/frontmcp-production-readiness/references/common-checklist.md

@@ -18,8 +18,9 @@ These checks apply to ALL deployment targets. Run them first, then proceed to yo
 - [ ] Session TTL is configured appropriately (not infinite)
 - [ ] Tool-level authorization is enforced where needed (ApprovalPlugin or custom)
 - [ ] OAuth redirect URIs are restricted to known domains
-- [ ] `FRONTMCP_PUBLIC_URL` is pinned to the canonical origin — issuer / resource / OAuth-discovery URLs and the transparent-mode expected audience derive from it, not from request headers. `X-Forwarded-Host`/`X-Forwarded-Proto` are ignored by default; only set `FRONTMCP_TRUST_PROXY=1` behind a proxy that strips client-supplied forwarded headers
-- [ ] `auth.requireRegisteredClients: true` (local/remote) so unknown clients can't present an attacker-chosen `redirect_uri` (auth-code interception). Clients register via DCR / `dcr.clients` / CIMD
+- [ ] `FRONTMCP_PUBLIC_URL` is pinned to the canonical origin — issuer / resource / OAuth-discovery URLs and the transparent-mode expected audience derive from it, not from request headers. `X-Forwarded-Host`/`X-Forwarded-Proto` are ignored by default; only set `FRONTMCP_TRUST_PROXY=1` behind a proxy that strips client-supplied forwarded headers. The Web fetch handler (`createFetchHandler`, Workers) takes the address from the request URL, never from a `Host` header that disagrees with it
+- [ ] `auth.requireRegisteredClients` left at its default `true` (local/remote) so unknown clients can't present an attacker-chosen `redirect_uri` (auth-code interception). Clients register via DCR / `dcr.clients` / CIMD; a production remote-mode server has neither DCR nor `dcr.clients`, so its MCP clients must use CIMD
+- [ ] `auth.allowedScopes` lists the scopes the server may grant (local/remote); anything else a client asks for is dropped
 - [ ] Transparent mode sets `auth.expectedAudience` (bind tokens to this resource) and validates issuer (`providerConfig.verifyIssuer`, default on)
 
 ### CORS Configuration

package/catalog/frontmcp-production-readiness/references/production-browser.md

@@ -23,6 +23,7 @@ Target-specific checklist for publishing FrontMCP as a browser-compatible SDK.
 - [ ] All file operations removed or polyfilled
 - [ ] Fetch API used instead of Node http/https modules
 - [ ] Works in major browsers (Chrome, Firefox, Safari, Edge)
+- [ ] Without `AsyncContext` requests run one at a time: tools don't start concurrent tool calls inside one request, don't call their own server through a client, and don't read request context from timers
 
 ## Security
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@frontmcp/skills",
-  "version": "1.8.2",
+  "version": "1.8.4",
   "description": "Curated skills catalog for FrontMCP projects",
   "author": "AgentFront <info@agentfront.dev>",
   "homepage": "https://docs.agentfront.dev",