Workspace policy
Workspace settings → Policy, under Security & data, holds the boundaries that apply to everyone in the workspace. The API enforces each one where it is used, not just the Settings page, so a change also covers conversations, share links, alert subscriptions and jobs that already exist.
Every switch starts at the behaviour the workspace has always had, and nothing changes until an admin picks something else. Web search for your own model endpoints is new and starts Off. The top of the panel summarises the current settings. Change any of the cards below it, then click Save policy settings. A change reaches every Kumkuat server within about a minute.
Only workspace admins and owners see the panel, and only they can change a policy. The API refuses a change from anyone else, even a role that has been granted Change workspace settings under Permissions.
Chat share links
Who can open a link to a shared chat.
| Choice | Effect |
|---|---|
| Anyone with the link (default) | No sign-in needed. Whoever has the link can read the whole conversation. This is how share links have always worked. |
| Workspace members only | The viewer must be signed in to an account in this workspace. Anyone else sees a sign-in message or not found. |
| Off | Nobody can create share links, and links already shared stop opening. |
The choice applies to links already shared as well as new ones, so switching back reopens them. Revoking a link from the chat removes it for good.
Web search in audience chat
| Choice | Effect |
|---|---|
| Allowed (default) | Audience chat may ground a reply with a Google Search when the conversation asks for it. |
| Off | No audience-chat reply is grounded with Google Search, even when the request asks for it: in the web app, over the REST API and through MCP. Grounding questions are refreshed without it too. |
With the switch off, a persona answers from its profile, its grounded context and your stored documents. A conversation already in progress follows the new setting from its next turn.
The switch covers audience chat only. Narrative report research, source discovery, auto tags and social-profile lookups use their own search and are not affected. See Data flow for what each search receives. The one exception is the next setting, which works only while this switch is Allowed.
Web search for your own model endpoints
Whether a model endpoint the workspace added itself may search the web through Kumkuat. An endpoint has no search of its own.
| Choice | Effect |
|---|---|
| Off (default) | A feature that runs on one of your model endpoints answers from what the model already knows. Nothing is sent to a search provider. Grounding questions marked Web search are declined on an endpoint. |
| Allowed — Kumkuat searches with Google Search | In audience chat, grounding-question refreshes and auto tags with web search enabled, your endpoint's model may ask Kumkuat to search the web, up to three times per reply. Kumkuat runs each search with a Gemini model and Google Search, sends that call only the query your model wrote, and returns the results to your model. |
Unlike the other switches, this one starts Off: a workspace usually adds its own endpoint to keep its content on its own infrastructure, and turning this on sends your model's search queries to Google. It applies only while Web search in audience chat is Allowed. Your endpoint must accept tool calls in the OpenAI format; one that does not answers without searching. Models that Kumkuat runs for you search with their own provider's tools and are not affected. See Web grounding.
Alert webhook destinations
Where alert subscriptions may post.
| Choice | Effect |
|---|---|
| Any URL (default) | Alert subscriptions may post to any webhook URL. |
| Only these hosts | Only https URLs on the hostnames you list are accepted, checked when a subscription is created and again each time an alert is delivered. |
| Off | No webhook subscriptions can be created, and existing webhook subscriptions stop delivering. |
For Only these hosts, enter one bare hostname per line, such as alerts.example.com, with no https://, path or wildcard.
Slack webhook URLs must always be on hooks.slack.com. While delivery is restricted (Only these hosts or Off), alerts reach Slack only through the workspace's Slack connection, and per-alert Slack webhook URLs are refused. Email and in-app delivery are not affected.
Newsroom pages found by discovery
Whether onboarding may attach a company's newsroom page without a person choosing it.
| Choice | Effect |
|---|---|
| Attach automatically (default) | When onboarding, or the Find newsroom page retry, looks for a company's newsroom, the best page it finds is attached and crawled daily. |
| A person chooses | Background discovery attaches nothing and makes no lookups. The newsroom keeps its daily web search until an admin or owner picks the page in Comms Sources → Discover newsrooms. |
A lookup a person starts in Discover newsrooms still searches the web, and attaches only the page they pick. Pages already attached keep crawling; pause or remove them in Comms Sources.
API clients
Whether anything other than the web app can reach the workspace.
| Choice | Effect |
|---|---|
| Allowed (default) | Members can create personal API keys and admins can create workspace keys. Scripts, MCP clients and AI assistants connected by signing in can reach the workspace. |
| Off — web app only | Only people signed in to the web app can use the workspace. API keys and connected AI assistants are refused from their next request with 403 api_clients_disabled, no new keys can be created, and an AI assistant asking to connect sees the workspace as unavailable. |
Turning it off does not sign anyone out, and keys are kept rather than deleted: they work again when the switch returns to Allowed. An audit-log feed polled by your SIEM also needs API clients allowed.
API key lifetime
The longest a new API key may last.
| Choice | Effect |
|---|---|
| No maximum (default) | A key lasts until it is revoked, unless whoever creates it chooses an expiry. |
| 30 days, 90 days, 180 days or 1 year | New keys must expire within that time. A key created without an expiry gets the maximum, and a rotated key keeps its lifetime within it. |
The maximum applies to keys created from then on: personal keys, workspace keys and gateway connections. Keys that already exist keep their current expiry, so revoke any you no longer want. The sign-in the web app uses for you is not affected, and neither are AI assistants connected by signing in. A request for a longer key is refused with 400 key_expiry_exceeds_workspace_maximum.