diff --git a/docs/channels/groups.md b/docs/channels/groups.md index 0f2f5335bf6b..72a72f613aeb 100644 --- a/docs/channels/groups.md +++ b/docs/channels/groups.md @@ -119,6 +119,8 @@ By default OpenClaw keeps context as received: allowlists decide who can trigger Set it per channel (`channels..contextVisibility`), per account (`channels..accounts..contextVisibility`), or globally (`channels.defaults.contextVisibility`). Channels that fetch supplemental context (Discord, Feishu, iMessage, Matrix, Microsoft Teams, Signal, Slack, Telegram, WhatsApp) apply the policy when building inbound context; unknown policy combinations fail closed and omit the context. +These modes filter channel-supplied supplemental context only. Tool policy and the owner-only tool inventory are still selected from the current turn's originating requester, not every sender represented in the prompt. See [Requester-scoped controls and prompt context](/gateway/security#requester-scoped-controls-and-prompt-context). + ![Group message flow](/images/groups-flow.svg) If you want... diff --git a/docs/docs_map.md b/docs/docs_map.md index f3f79dda16a8..cb9b52cbbb86 100644 --- a/docs/docs_map.md +++ b/docs/docs_map.md @@ -4026,6 +4026,7 @@ Do not edit it by hand; run `pnpm docs:map:gen`. - H3: What the audit checks (high level) - H3: Priority order when triaging findings - H2: Hardened baseline in 60 seconds + - H3: Requester-scoped controls and prompt context - H2: Trust boundary matrix - H2: Not vulnerabilities by design - H2: Gateway and node trust diff --git a/docs/gateway/config-tools.md b/docs/gateway/config-tools.md index 8f684f7c9d15..704fecd3def7 100644 --- a/docs/gateway/config-tools.md +++ b/docs/gateway/config-tools.md @@ -154,7 +154,7 @@ Further restrict tools for specific providers or models. Order: base profile → ### `tools.toolsBySender` -Restricts tools for a specific requester identity. This is defense-in-depth on top of channel access control; sender values must come from the channel adapter, not message text. +Restricts tools for the current turn's originating requester. This is defense-in-depth on top of channel access control; sender values must come from the channel adapter, not message text. It does not authenticate other content in the model prompt; see [Requester-scoped controls and prompt context](/gateway/security#requester-scoped-controls-and-prompt-context). ```json5 { diff --git a/docs/gateway/security/index.md b/docs/gateway/security/index.md index 06716ff235ee..a5fae7c045cf 100644 --- a/docs/gateway/security/index.md +++ b/docs/gateway/security/index.md @@ -95,6 +95,12 @@ Keeps the Gateway local-only, isolates DMs, and disables control-plane/runtime t Built-in baseline for chat-driven agent turns: non-owner senders cannot use the `cron` or `gateway` tools regardless of config. +### Requester-scoped controls and prompt context + +`tools.toolsBySender`, sender ownership, and owner-only tool inventories are evaluated against the current turn's originating requester. They do not authenticate or sanitize other content in that model prompt, including quoted text, prior shared-room history, forwarded content, fetched content, attachments, tool results, or other prompt inputs. Content from another person can therefore influence an owner-triggered turn when it is included in that turn's context. + +Treat these controls as defense in depth that reduces direct capability for a requester, not as hostile multi-user isolation. Use `contextVisibility` to filter supported channel-supplied context, restrict tools and sandbox the agent, and use separate gateways and ideally separate OS users or hosts when participants are mutually adversarial. + ## Trust boundary matrix Quick model for triaging risk reports: