Server-enforced public-only scope for Assistant API keys

[Jack-Lewis1]

We call the Assistant API from a server-side proxy, so customers can use an AI help assistant inside our product. The key retrieves everything in the docs index, including pages behind authentication. So any gated page that's indexed can end up in an answer to a customer.

Each option available today costs something:

• filter on the message endpoint (version, language, groups) narrows retrieval, but the caller supplies it. A request that leaves it out still reaches every indexed page, so it's a convention the integration has to keep rather than a boundary it can rely on.
• noindex / searchable: false on gated pages keeps them out of the key's reach, but also out of on-site search and the assistant for signed-in users. Protecting customers means taking the assistant away from your own team.
• A second, fully private site works, but means running a separate site with its own search, so staff look in two places, just to get one boundary.

What would solve it: an option, when creating an Assistant API key, to scope it server-side — to public pages only, say, or to a fixed set of groups. The key could then never retrieve anything outside that scope, whatever the request body contains. On-site search and the assistant for signed-in users would keep seeing everything they're entitled to.

A smaller, related gap: filter is in the OpenAPI spec for POST /v2/assistant/{domain}/message, but not on that endpoint's documentation page. We only found it by reading the spec.