the switchboard · messaging gateways · designed and ratified, implementation scheduled
Put an agent in the chat, keep the governance
A support agent that lives in your company chat is the most useful agent you can deploy, and the most dangerous, because one instance answers many people. The switchboard is how the hall will let a centrally hosted agent runtime — Hermes, the harness behind our own Discord assistant, or any harness on a VM you control — serve a whole Teams, Slack or Discord workspace: every person proves who they are once, every message arrives signed by the platform, and every answer is capped by the room it will be printed in. Nothing anyone types can widen that.
status, honestly: messaging gateways are designed and ratified (RH-GATEWAY-DESIGN, 2026-08-24); the core acceptance contract and the first adapters are scheduled after 1.0. nothing on this page is clickable yet.
One agent, many people
Today a chat agent is usually a single service identity with wide access. Every answer runs under its authority, not the asker’s, and the model is the only thing deciding who gets to see what. That is not a control.
The confused deputy
One agent instance answers many people. If it runs under its own wide authority, the only thing between “what is on Alice’s host?” asked by Bob and the answer is the model’s judgement — and every chat message is attacker-writable input.
Context contamination
Even with per-call permission checks, a model remembers what it read while answering Bob. Alice’s next question can pull it back out. Authorization on tool calls cannot scrub a context window; only a separate context can.
the room defines what may be said · the person defines what may be done · the server verifies who spoke and computes both · the model decides neither
Nothing until linked
The switchboard never guesses who is calling. A person proves once that a chat identity and a hall Account belong together — both sides, by a round-trip only they can perform — and from then on every message they send has a resolved Account behind it.
You say hello
A chat user the hall has never linked gets exactly one reply, whatever they typed: the fixed linking instruction with a link. No anonymous tier exists — nothing until linked.
You prove the hall side
The link opens the hall’s own sign-in — your single sign-on if you have one — so the Account is proven by a real login session, never by a name someone typed in chat.
You prove the chat side
Either the platform’s own sign-in (Slack OpenID Connect, Discord identify) returns your immutable user id to the hall, or the hall shows you a one-time code that you post from your chat identity and reads the id from the platform-signed event.
Linked, visibly, revocably
The identity link is an object the owner can see and revoke in the Access manager. Unlink it, or disable the Account, and the very next message from that chat identity is treated as unknown again.
Display names, handles and anything typed into chat are never inputs to identity. The hall takes the platform user id only from a response the platform signed — its own sign-in, or the signed event that carried your one-time code.
The room decides what may be said
In a shared channel the answer prints into a room, and everyone who can read the thread will read it. So the question is never “may Alice see this?” — it is “may this be printed here?”. Each room — a venue, in the product’s words — is bound on the owner plane, the human-only administration surface, to a group and an access profile, the published permission set that becomes the room’s disclosure ceiling. Identity is checked first: an unlinked person gets only the linking instruction. A linked person in a room nobody has bound gets one fixed “this room is not configured” reply that names no object.
Ceilings intersect, never add
A person holding root asking in a low-cleared channel gets low-cleared answers. An elevated badge in the room never widens the room; what the person may command is their own authority, capped by the room and the gateway.
One context per room
Every room gets its own agent session with its own context, so nothing the model read at a higher clearance can leak into a lower room. A direct message is the room of one — and “one” is proven from the platform’s signed conversation data, never assumed. A group DM is a room.
One refusal, always the same
When the answer may not be printed here — the object does not exist, is outside this room, or the asker is not allowed — the reply is one fixed text, byte for byte, with one standing hint: for anything outside this room, DM me or use the board. Nobody in the room learns which of the three it was.
if m.kowalska starts a direct message and asks the same question, it runs in a fresh context under a separate credential capped by her own badge — a private answer is never computed inside a shared room
Verified, then minted, then capped live
A gateway is a Service of a third kind, beside services and connectors: it carries people’s messages in under verified attestation. A connector works; a gateway speaks for people. That difference in trust earns it its own noun, its own registration and its own ceiling.
Verify or nothing. The gateway hands the hall the raw platform-signed event — a Slack request signature, a Discord Ed25519 interaction, a Teams token — and asserts nothing else. Core verifies it with a signature module the deployment installed, derives who spoke and in which room from the signed bytes, and refuses anything that disagrees. A platform whose events cannot be verified gets no on-behalf-of features at all: its gateway may read under its own identity, write nothing, and attribute nothing.
Then the exchange. The gateway presents its own credential plus the verified event, and the authorization server mints a short-lived on-behalf-of credential — standard token exchange, not a bespoke door. That credential stores references, never computed authority, and on every request the server computes two separate live ceilings. In a shared room, what may be disclosed is capped by the gateway and the exact credential it presented, that credential’s own scopes, the room’s current access profile and the fixed task-and-report envelope; what the person may command is that disclosure ceiling further capped by their own current authority. In a proven one-person direct message both ceilings are capped by the person as well. If any required arm is missing, the request fails closed.
Revocation revokes the memory. Narrow the room, unlink the person, disable the gateway or the Account, and the credential dies mid-thread — and the room’s agent session must start a fresh, empty context before it may say another word. A fully compromised gateway can never exceed its own configured ceiling.
slack-acme · Service kind: gateway · own ceiling: work plane
Slack request signature over event Ev07… · installation acme/A0… bound to this gateway · dedup ok
m.kowalska (Account) · identity link slack:acme:U04… · active
#ops-billing · group ops-billing · profile billing-readers@v12 (followed live)
board · scopes ⊆ tasks:read, tasks:write, reports:read, reports:write
computed on every request · disclosure: gateway and source credential ∩ credential scopes ∩ room profile ∩ envelope · command: disclosure ∩ person · any required arm missing fails closed
Chat can ask, never operate
phase: 3 · fix · references: INC-4785 RCA · addressed to: the authoring line · created as: m.kowalska (on your confirmation)
your confirming message is itself a platform-signed event; the task is created as you only if it matches this summary exactly · “deploy it” from chat becomes a prepared act and a board link, never an action
Browse servers, answer questions, change nothing
The sysadmin case — “what is the state of that host?” — never gives the agent standing keys. A broker Service in your estate presents the on-behalf-of credential to the hall’s minimized introspection surface. When every live arm and the designated caller check out, the hall returns only an active state, a subject reference, the groups relevant to that broker, and three opaque selectors derived from the room, the person and the presenting gateway. The broker intersects those and may issue a short-lived, read-only host certificate from its closed list of operations: no shell, no write, no reboot expressible. The hall stays infrastructure-agnostic; hosts are never board objects.
Three arms, intersected
The room’s clearance, the person’s own entitlement, and the gateway’s own host-domain entitlement — a wide room never discloses past the person, a powerful person never widens a low room, and no gateway reaches hosts outside its own registration.
The general plugin contract
The same shape serves ServiceNow, secret vaults, ticketing or n8n: the hall supplies minimized identity, the groups relevant to that plugin and the three opaque selectors for room, person and gateway; the plugin applies its own domain rules. Direct-from-chat calls are disclosure only.
Mutations go through the board
Anything that changes something flows chat → task → a normally authorized agent that checks the requester’s identity and groups before acting. That is the production line from the tour, entered from a chat window.
The warehouse uses the same disclosure-only pattern for your knowledge sources
What the hall provides, and what you plug in
The acceptance contract
The adapters and the runtime
status, honestly: the design is ratified (RH-GATEWAY-DESIGN); it adds exactly one mechanism to the authority model — the on-behalf-of exchange — and no execution ever flows through a gateway: a task created from chat enters the same pull model as any other, and your lines pick it up under their own credentials. implementation lands after 1.0; the roadmap keeps the tally.
Give your chat a governed voice
The design is ratified; the core contract and the adapters are scheduled after 1.0. Stand up the hall today, and the switchboard will plug into that hall when it ships.