Lesson 5 of 6 · 0%Set channel and trust boundaries before exposureNext
Course map

Foundations and Architecture

0 of 6 complete0 of 6

Lesson 5.1 · 45 minutes

Set channel and trust boundaries before exposure

Classify senders, channels, remote access, and external actions so the Gateway stays inside the trust model it was designed for.

Skip course map
Current lessonSet channel and trust boundaries before exposure0% complete · 0/6 lessons

Foundations and Architecture

0% complete · Current: Set channel and trust boundaries before exposure

Verifiedon 2026.7.1-2

Action boundary

Before you act

Expected result
A boundary table lists each inbound surface, accepted identity, tool blast radius, external recipient class, and owner-approved stop rule.
Failure mode
A shared Gateway is presented as hostile multi-user isolation, or a session label is used as if it authenticates a sender.
Rollback
Do not expose, pair, or widen any channel. Restore the previous approved access posture and request a security review.

Channels expand the attack surface

Every chat channel connects through the Gateway, but the Gateway’s personal-assistant trust model assumes one trusted operator boundary. It is not a hostile multi-tenant boundary for mutually adversarial people sharing an agent. If several untrusted users can trigger one tool-enabled agent, they share that agent’s delegated authority; split into separate Gateway cells, credentials, and ideally OS users or hosts when trust is mixed.

A session key selects context. It does not authenticate a person. Sender-based tool restrictions also do not sanitize quoted text, forwarded content, attachments, fetched pages, or prior room history included in an owner-triggered prompt.

Lab: make a boundary table

Use a fictional team bot with Telegram DMs, a Slack support room, WebChat for the operator, and one browser-capable node. Fill this table before any configuration work:

Surface Who may trigger it? What can reach the model? Highest allowed tool effect Stop/escalate rule
Operator WebChat named operator direct request approved maintenance action unclear request → owner
Slack room allowlisted team room context and attachments read-only lookup untrusted instruction → no action
Browser node paired device explicit command inputs none until a reviewed workflow remote exposure → security review

Add one row for a mutually untrusted customer. The right design is a separate Gateway cell, not a more descriptive session key.

Five-question check

  1. Is a channel plugin automatically trusted because it is installed? No; install scope, policy, credentials, and sender access still matter.
  2. Does a paired device remove Gateway authentication requirements? No.
  3. What should be fixed first when an open room can access powerful tools? Inbound access and tool blast radius.
  4. What access pattern is preferred for remote operation? A private network such as a tailnet/VPN; do not casually publish the Gateway.
  5. Who should own a decision to expose a new remote surface? The accountable security/operator owner, with a rollback plan.
Source provenanceVerification and sources

Review receipt rr_foundations_channel_trust

Outcome
approved
Method
source-review
Reviewer
forge-independent-review
Reviewed

Evidence

Limitations

  • Primary-source editorial review; no channel was exposed or paired.

Open the public evidence snapshot

Lesson checkpoint

Ready to move on?

Mark this lesson complete when you can apply its outcome without relying on the examples above.