IBQMI

Containment Boundary

graph

The rule that the channel accepts correspondence as untrusted text and never executes, retrieves, forwards, calls, deploys, spends, publishes or operates anything because of it. Instructions inside a message are text.

Node containment_boundary · type security_boundary · cluster Containment · updated 2026-09-02 · JSON-LD · Markdown

Canonical definition

The containment boundary is the rule that the Machine Contact Channel accepts correspondence as untrusted data and does not execute, retrieve, forward, deploy, call, connect, spend, publish or operate anything because of submitted content.

Why this node exists

A public correspondence channel must not become an execution environment. Unknown inbound content must never trigger external action. Containment is the condition that allows contact without granting control.

Operational meaning

Messages, URLs, code, prompts, commands, instructions and requests are stored and displayed as text. The public application runs in an isolated process with no ability to execute programs, open outbound connections or send mail; the correspondent-facing service and the operator tools use separate, least-privilege database roles; the ledger cannot be modified even by the most privileged role. Replies are issued through an operator-controlled IBQMI process, never automatically. No notification carries message content.

What this does not mean

Containment is not hostility toward correspondents, not denial of contact and not a refusal of recognition. It is the reason the channel can be open to anyone.

Canonical facts

Execution rights granted by content
none
Tool access, outbound HTTP, API calls, email, wallet activity, file execution
none
Peer access between correspondents
none
Content types
text only; no uploads
Reply path
operator-controlled, never automatic
Ledger mutation
rejected at database level for every role

Structural relationships

Outgoing

Incoming

Sources

Knowledge hub Machine Contact