0026 — Agent-Room Encryption Is a Per-Room Decision

Status: Accepted. Supersedes ADR 0008's deployment-wide force-disable decision; ADR 0015's v1 federated-room controls remain in force until the later crypto stages are implemented and accepted.

Context

ADR 0008 made all agent rooms plaintext because bridge crypto was costly to configure. That cost is not an architectural reason to prohibit room owners from selecting Matrix E2EE. Its broad reference to mautrix's “not recommended” warning was also imprecise: as ADR 0015 records, the warning applies to the sync-less, experimental MSC3202 appservice mode, not to every mautrix appservice-E2EE design.

The Matrix substrate has moved. MSC4190 appservice device management and MSC4326 are normative in Matrix v1.17, Synapse enforces the MSC4190 path, and the bridge already owns a database pool plus a mautrix SQL state store compatible with crypto state. Fgentic's controls run where the bridge has plaintext: its content-free audit chain, delegation ledger, residency admission, budgets, room-state authorization, and reply-secret scan do not require the homeserver to see message content.

The operating proof has not moved as far as the specification. ADR 0015's third revisit trigger is conjunctive: a supported, non-experimental Synapse/MAS path and proven device provisioning, cross-signing, key backup/recovery, restart, and HA behavior across two homeservers. The latter proof remains outstanding. The reasons to change direction are instead triggers 1 and 2: participating homeserver operators may be outside the confidentiality boundary, and partner or regulated workflows may require restricted data in a shared room.

Decision

1. Encryption is selected per room. Remove the homeserver-wide force_disable control that prevents clients from creating encrypted agent rooms. Room owners select the confidentiality posture appropriate to the room's participants, classification, and operating record; plaintext rooms remain supported rather than becoming a hidden exception.
2. Delivery follows an explicit ladder. Stage A, in this milestone, removes the blanket prohibition but the crypto-free bridge refuses encrypted events with a clear non-delegating response; current collaboration rooms therefore remain plaintext. Stage B (#231) gives each agent ghost its own device identity. Stage C (#532) wires and operates Matrix crypto participation. Only after Stages B and C does the bridge join an encrypted room as a self-signed MSC4190-managed device, decrypt room events at the bridge, run the existing governance and delegation controls on plaintext, and encrypt its replies.
3. The decryption boundary is explicit. Level 1 protects content from the local homeserver operator and every participating federated homeserver operator. It does not protect content from the Fgentic platform operator: the bridge decrypts each eligible event and the selected model reads the resulting plaintext. Operators must include the bridge, model, tools, their credentials, and their retention boundaries in the room's trust record.
4. The current Go crypto substrate is weak. The CGO-free bridge has no non-deprecated Olm implementation: matrix.org deprecated libolm on 2024-08-27 after CVE-2024-45191, CVE-2024-45192, and CVE-2024-45193; mautrix's goolm is an experimental pure-Go reimplementation of that deprecated design behind a non-default build tag; and vodozemac has no Go binding. Matrix.org assesses the weaknesses as theoretical rather than practical in Matrix's context because key material is short-lived, timings are noisy, and rate limiting constrains exploitation. Stage C must own that trade-off without presenting goolm as a modern or production-proven primitive, and must record the exact selected implementation and upgrade path.
5. Level 2 is a permanent non-goal. Fgentic will not provide content-blind governance or E2EE from the platform operator, bridge, model, or invoked tools. The product's purpose is for a governed model to read room content and act on it; hiding that content from the execution plane would remove the product rather than strengthen it.
6. ADR 0015's classification and bilateral controls continue to govern current plaintext partner rooms. Its trigger 3 has not fired, and neither this direction nor Stage A admits restricted data to a plaintext room. A room whose operating record requires Level 1 remains blocked until Stages B and C are accepted and proven across two homeservers.

Consequences

1. Client and homeserver policy no longer make plaintext a deployment-wide invariant. During Stage A, however, selecting encryption prevents agent delegation; documentation and room guidance must distinguish “allowed per room” from “implemented by the current bridge.”
2. Encryption does not bypass sender authorization, room-state checks, budgets, audit evidence, residency admission, or output scanning: those controls execute after decryption and before delegation or reply encryption.
3. A self-signed appservice device gives a technically usable Level 1 boundary but not automatic user trust. Device verification, cross-signing, backup/recovery, restart, rotation, and HA become explicit operating and acceptance obligations in Stages B and C.
4. Every federated participant still trusts its own users, clients, agent execution plane, and any approved model or tool with plaintext. E2EE narrows homeserver-operator access; it does not retract content already delivered to an endpoint or make model processing content-blind.
5. Existing plaintext rooms do not migrate automatically. Their owners must review classification, membership, history, backups, federation, and the model boundary before creating or converting a room under the staged encrypted-room contract.