How can several software agents exchange confidential messages when members join, leave, go offline, or lose a device? Messaging Layer Security, or MLS, supplies a standardized group key agreement protocol. It lets participating clients establish shared cryptographic state, advance that state in numbered epochs, and derive keys for encrypted application messages. An agent application still has to decide who is allowed into the conversation and what each participant may do. MLS secures group communication; it does not grant an agent authority and it is not evidence that artificial superintelligence exists.
The practical answer is to treat membership changes as committed cryptographic state transitions, not as decorative updates to a chat participant list. A new agent enters through a validated KeyPackage and receives a Welcome after a Commit. A removed agent must be excluded from new epoch secrets, while messages it legitimately accessed before removal remain a separate retention problem. Teams building actual agent systems must also enforce credentials, tool permissions, reliable delivery, device security, and recovery. This guide traces those boundaries with a three-to-four-to-three-member example and checks each conclusion against the IETF specifications.
Reading map
Choose a section: the protocol boundary, the service layers, KeyPackages, the ratchet tree, membership transitions, the numerical walk-through, asynchronous failures, security limits, agent engineering, diagnosis, transfer exercises, deployment review, FAQs or primary reading.
The question MLS answers, and the questions it does not
Three layers of a trustworthy deployment
KeyPackages: the public invitation material
Ratchet trees: why the protocol can scale
Proposal, Commit and Welcome have separate jobs
Worked example: three clients, then four, then three
Asynchrony and concurrent changes: the difficult middle
Security guarantees must be read with their conditions
Designing secure groups of real software agents
Failure diagnosis and practical repairs
Transfer exercise: the group changes context
A deployment review that can survive an incident
Further reading: protocols, architecture and related routes
The question MLS answers, and the questions it does not
MLS is concerned with the cryptographic state of a changing group of clients. It solves an awkward coordination problem: many participants need keys that protect messages from the delivery infrastructure, but individual members may be unavailable when membership changes. Traditional pairwise messaging can send each participant a separate encrypted copy; that works, yet the traffic and state-management overhead grow with a group. An unchanging shared secret reduces traffic but makes departures and compromises dangerous. MLS applies a structured ratchet-tree key agreement, moving a group to a fresh epoch after an accepted Commit.
The protocol is deliberately narrower than a complete messenger. It does not choose the business rules for admission, operate your organisation’s employee directory, authorize payment tools, or decide whether an AI-generated instruction is safe. It does not protect a decrypted document once an authorized client exports it to an insecure log. The IETF architecture in RFC 9750 separates these application responsibilities from the wire and key-agreement rules in RFC 9420. That separation should appear in the software architecture and in security reviews.
Clients are endpoints, not human names
An MLS member is a client with cryptographic keys, not merely a human display name. One person using a laptop and phone can be represented by two clients, and two process instances of one service may need distinct client identities if they are separately enrolled endpoints. A robot worker called ResearchAgent is not authenticated just because a user interface displays that string. A credential must bind a verifiable key to a meaningful identity according to the application’s authentication service. The distinction matters when revoking one stolen device without evicting every endpoint associated with an account.
A production inventory should map application principal, device or process instance, credential, MLS client identity, and permitted group roles. Those records may be related, but they are not interchangeable. If a team uses a single credential for five independently deployed agents, compromise attribution and selective removal become harder. Design the identity scheme before using a shared group to carry sensitive operational instructions.
Epochs are specific membership states
An epoch is a particular group state with its authenticated clients, derived secrets, and transcript context. Imagine epoch 7 contains Alice, Ben and Cora. Adding Dev does not simply append a visible row; the accepted Commit creates epoch 8 with four members and fresh secrets. Removing Dev creates epoch 9 with the remaining three. The epoch numbers are an illustrative sequence, not a proof of global chronological ordering across unrelated conversations. Within one valid MLS group history, members use a sequence of connected epochs.
This gives an engineer a powerful diagnostic: ask which epoch a message belongs to and which client held secrets for that epoch. A membership badge may say ‘removed’ while an offline client has not yet processed the removal Commit. Your application has to coordinate user-visible membership, cryptographic state, and pending delivery rather than assuming a database update instantly changes every remote device.
Forward secrecy and post-compromise security are different
Forward secrecy addresses later exposure of earlier communication after obsolete secrets have been erased. Post-compromise security addresses the possibility of recovering secure communication after an attacker briefly obtained a client’s old state. MLS uses key updates and Commit processing to move a group away from earlier compromised keys. These benefits are conditional. A device that permanently retains plaintext archives, key backups, or exported message keys can undermine protection of that material; an attacker continuously controlling the endpoint can read what the endpoint reads.
RFC 9420 is explicit that the post-compromise benefit associated with an update takes effect when relevant members process the Commit, not merely when a sender queues an Update proposal. This is why operational health must measure successful transitions and recipient catch-up, not just how many rotation jobs reported ‘started’. An application should be precise about whether its protection claim concerns past content, future messages, or the currently compromised device.
Three layers of a trustworthy deployment
A secure group-messaging design has at least three layers: cryptographic group state, the transport and identity services that make state changes usable, and business authorization. MLS can maintain strong encrypted group state while a weak enrollment API admits an impostor. Conversely, impeccable identity validation cannot repair a delivery service that permanently suppresses revocation commits. A good architecture shows the boundaries and records evidence at each one. RFC 9750 explains that the authentication and delivery functions can be centralized, distributed, or implemented in different arrangements.
Authentication Service: identity is a verified binding
The Authentication Service, or AS, associates application-meaningful identifiers with credential and public-key information. Its implementation can involve certificates, an organizational identity system, direct key checks, or another scheme compatible with the application. The important question is whether a receiving MLS client can verify that the asserted principal owns the expected signing key. A signature on a message proves control of a key. It does not independently prove that the human or service behind the key has a given job title.
Suppose a client accepts a KeyPackage whose leaf signature verifies but whose owner binding was never checked. The cryptography may be internally consistent while group admission is still wrong. An identity review therefore needs to ask how credentials are issued, validated, expired, rotated, and revoked; how mismatches are handled; and whether changes can be audited. Authentication failures should block membership decisions until reviewed, rather than being hidden under a generic ‘encryption worked’ indicator.
Delivery Service: reliable order without plaintext authority
The Delivery Service, or DS, distributes MLS messages and often stores KeyPackages so offline clients can be added. It need not decrypt ordinary application messages. However, message confidentiality alone does not make the DS harmless. A compromised or malfunctioning DS can omit, delay, reorder, or selectively deliver traffic. Depending on how an application sequences concurrent Commits, delivery behavior can determine which candidate transition advances the group. Members that miss state changes may become unable to decrypt later traffic.
Treat DS availability and integrity as engineering requirements separate from confidentiality. Record enough safe delivery metadata to diagnose a gap, but avoid keeping sensitive plaintext for debugging. Establish bounded replay and catch-up rules; test simultaneous commits and interrupted network sessions; and decide how the client reports an unresolvable fork. RFC 9750 discusses strongly consistent and eventually consistent delivery choices rather than claiming the MLS cryptography dictates one deployment model.
Policy Service: authorization remains outside MLS
Consider an agent that can read research notes but cannot approve expenditure. MLS membership might allow it to receive encrypted task updates; it must not thereby gain permission to trigger a purchasing API. Enforce every consequential action at the tool boundary with a policy decision based on the initiating principal, exact operation, resource, contextual constraints, and current authority. A message saying ‘the committee approved this’ is content, not a verified access-control grant.
Use a separate authorization decision before an agent enters the group and another at every protected action. The first decides communication membership; the second decides activity. When a member is removed, disable active API tokens, revoke tool capabilities, and update applicable access-control records independently of the cryptographic Commit. An MLS group membership event may be useful evidence for an authorization workflow, but it is not the whole workflow.
KeyPackages: the public invitation material
The most easily misunderstood MLS object is a KeyPackage. It is not a secret invitation code and it is not a shared password. It is a signed bundle that tells existing members how a client can be securely added, including key material for hybrid public-key encryption and information about its identity and supported capabilities. The recipient retains the corresponding private key locally. A service can publish KeyPackages for later pickup because the public package alone should not reveal that private key.
What a KeyPackage contains and why it is signed
A KeyPackage contains an initialization key, a LeafNode with a credential, signature key and capabilities, and signatures or other validity material defined by the MLS format. Exact fields and validation rules belong to RFC 9420 Sections 5, 7 and 10; an implementation should use a maintained protocol library rather than invent wire serialization. The signatures help recipients reject tampered or unauthorized presentations of the client’s public state, provided the credential itself is trusted by application policy.
Before an Add, validate the credential binding, supported cipher suite, required extensions, signature, lifetime information where applicable, and expected identity. Do not accept ‘it parsed’ as proof of legitimacy. A format-valid packet can still belong to the wrong device or principal. Record the specific reason an enrollment was refused without copying sensitive private material into diagnostic logs.
One-time use and the last-resort exception
RFC 9420 intends KeyPackages to be used once. Once one has introduced a client into a group, the publication service should remove that package from normal inventory. Reuse can create replay risks. The protocol allows a last-resort pattern for some deployments, but that exception trades convenience and availability against stronger assumptions about freshness and duplication. A service that blindly recycles a package because inventory ran out has turned a routine scaling problem into a cryptographic hazard.
An operator should monitor inventory by client and age. In an illustrative fleet of 10 clients each preparing 6 ordinary unused packages, the directory holds 60 packages, calculated as 10 times 6. If 9 packages are consumed, 51 remain across the fleet, but that aggregate says nothing about a particular client’s exhaustion. Track per-client minima, expiration and delivery failures, not just a global total. Apply rate limits to anonymous retrieval and provide a bounded replenishment path.
Credential validation is not optional ceremony
A credentials system can fail silently when engineers separate encryption from identity. Suppose an onboarding endpoint accepts any signed KeyPackage whose self-chosen display name matches ‘PayrollAgent’. That demonstrates the key holder can sign, but it does not demonstrate authorized control of the payroll role. The correct check binds the public key to an identity and an issuer or trust rule that the organization actually accepts. Only then can an authorization layer decide whether that verified identity belongs in the group.
Credential expiry and revocation are harder than a boolean ‘valid’ field in a database because offline clients hold previously authenticated state. Make the protocol library’s credential checks explicit, define how often fresh trust information is obtained, and use application-level removal and replacement when credentials are no longer trustworthy. An old message’s authentic signature should not be rewritten as evidence that today’s account permissions are unchanged.
Getting new material onto an offline device
Asynchronous membership is valuable because a recipient does not have to be online at the instant of addition. The joining device has previously published usable KeyPackage material and retained its private side. Existing group members can use that public information in an Add/Commit sequence and deliver a Welcome for later processing. The new device must obtain the appropriate tree and group context, validate them, and derive its own epoch state before reading application messages for that epoch.
This arrangement creates an operational dependency: if the recipient deleted the matching private key, rotated it without preserving a pending one, or cannot obtain the required tree, a Welcome cannot magically repair the mismatch. A recovery path should replace the enrollment material and initiate a legitimate new join. It should not ask the server to supply missing private keys or disable validation to ‘unblock’ a pending invite.
Ratchet trees: why the protocol can scale
MLS arranges clients as leaves of a tree whose structure supports efficient updates to shared group secrets. The tree lets a sender encrypt refreshed path secrets toward sets of other members rather than treating every group member as an unrelated one-to-one recipient. This is an important idea for groups that change membership repeatedly. Nevertheless, the tree is an implementation of key agreement, not a magical guarantee that every end-to-end network cost is logarithmic.
Leaves, paths and shared internal nodes
Each member corresponds to a leaf carrying information about its keys and capabilities. Internal nodes have public-key-related state that helps distribute changes. The direct path from a leaf to the root passes through a limited number of levels in a suitably balanced tree. A member refreshing its leaf and path can derive new secrets, while other members use ciphertexts directed toward positions they can decrypt to reach the same new epoch.
For intuition, a balanced binary tree with 16 leaves has four edges on a leaf-to-root path, because 2 to the fourth power equals 16. That illustration is about tree depth, not a promise of exactly four encrypted objects for every real MLS Commit. Tree shape, blanks, proposal content, extensions and delivery framing affect the actual bytes and processing. Never translate a big-O statement directly into a billable bandwidth guarantee.
Secret evolution is not a single group password
An MLS group does not operate by copying a human-readable password to every participant and replacing it occasionally. It derives epoch secrets through a key schedule based on authenticated state transitions and then derives secrets for application encryption and other functions. The tree supports refreshing secret contributions; transcript hashes help bind the current state to the sequence of accepted messages. This structured evolution helps make later compromise less informative about earlier states when obsolete material is discarded.
An engineering design should distinguish raw credentials, leaf private keys, tree path secrets, epoch secrets, derived application encryption keys, and stored plaintext. Give them separate lifecycle and observability rules. Dumping all of them into a generic ‘debug state’ archive defeats much of the reason to adopt the protocol. Test that deletion happens where expected, while remembering that deletion claims are limited by backups, swap, crash dumps and hardware behavior.
Group Context ties a state to its history
The GroupContext records public state such as the group identifier, epoch and hashes used by the protocol. It is more than a label to display above a conversation. When a client validates a Commit or a Welcome, the context and transcript relationships help detect inconsistent histories and incorrect transitions. The exact algorithms are specified in RFC 9420 Sections 8 and 12 and should not be replaced with an improvised JSON comparison.
Imagine two devices that both claim to be at epoch 12 but have different transcript hashes. The number alone cannot reconcile them. The correct response is to use authenticated protocol state to diagnose a fork, missing Commit, or misconfiguration. A dangerous workaround would be to change the displayed epoch number in a database while leaving incompatible cryptographic state untouched. Representation should follow verified state, not force it.
Public and private message forms
An MLS PublicMessage is signed and integrity-protected but is not encrypted. A PrivateMessage provides encrypted authenticated carriage. RFC 9420 requires application messages to use the private form, while some deployments may send handshake messages publicly when a delivery service needs to inspect certain metadata. Privacy claims must therefore specify whether they concern user payloads, protocol handshakes, membership, message frequency or routing.
An outside observer may learn that a group exists, see delivery patterns, or infer periods of high activity even when payload confidentiality remains intact. Protect especially sensitive operational metadata through the surrounding application where feasible. A security review that stops after confirming the plaintext body is encrypted leaves exposure of timing, group identifiers and delivery relationships unexamined.
Proposal, Commit and Welcome have separate jobs
Group evolution occurs by proposing a change and having an authorized participant Commit the selected change or changes. The protocol distinguishes a proposal from a committed transition to support asynchronous operation, validation and consistent agreement. A Welcome helps a newly added client initialize its new state. Those names are not three synonyms for ‘invite’. Each belongs to a different point in an auditable state machine.
An Add proposal expresses an intended membership change
An Add proposal identifies new participant material, generally relying on a validated KeyPackage. The proposal can be distributed to existing members and later included in a Commit. Until the change is committed and processed, the group cannot assume every member has accepted the new client. If approval policy requires a supervisor’s decision, the application must enforce it before a client creates or accepts the corresponding group transition.
One useful control is to label a pending invitation separately from an active membership. The user interface should not expose current protected group content to a pending applicant simply because an invitation was prepared. A backlog of proposals may contain stale or conflicting ideas; recipients must validate the list that actually becomes part of the Commit.
Commit is the decisive transition, not a status update
A Commit applies a collection of referenced or included changes and advances the group to a new epoch. Recipients verify that proposed operations and cryptographic path information satisfy protocol rules. A Commit may contain more than one change, and an Update or a Commit without proposals may rotate relevant cryptographic state. Crucially, an application should not equate ‘Commit constructed locally’ with ‘the networked group successfully advanced’.
In a distributed conversation, one endpoint may generate a valid Commit while another concurrently proposes a different transition. The delivery layer and the agreed sequencing strategy must determine what is accepted, and clients need to process the corresponding history. Record separate milestones for created, sent, accepted by ordering policy, and processed by individual clients. Only the last gives evidence that a particular remote device actually holds the new epoch.
Welcome initializes the new member
The new client usually cannot reconstruct its joining state simply by reading the ordinary Commit visible to existing members. The sender constructs a Welcome containing encrypted joining information appropriate to the KeyPackage. On receiving it, the client checks the cryptographic material, obtains any required ratchet tree, and initializes state for the epoch to which it was added. The Welcome is associated with the new member, not a reusable universal invitation link.
If a copied Welcome is presented to a different device that does not possess the matching private key, the device should not be able to decrypt the intended secrets. If a valid recipient receives the Welcome twice, the application must still use appropriate state and replay handling rather than blindly creating duplicate logical group sessions. Treat welcome processing as a state transition with clear success, expiration and repair behavior.
Remove changes future eligibility
A Remove proposal targets a member’s leaf. When committed with the required cryptographic changes, the new epoch is constructed without the removed member’s access to the fresh group secrets. The removed endpoint should therefore be unable to decrypt new application messages encrypted for the new epoch under the intended security assumptions. That is narrower than claiming that all data has vanished from the removed person’s device or that the server cannot route a packet to it.
A correct user interface should show the difference between removal requested, removal committed, and relevant devices updated. Independent tool tokens also need revocation. If the participant retained plaintext from before removal, MLS cannot rewind that knowledge. If an adversary still controls a current legitimate participant, they may obtain content through that participant. Cryptographic exclusion is a meaningful boundary, not a replacement for data governance.
Update refreshes credentials or secrets without changing headcount
Member changes are not limited to addition and removal. An Update proposal, once included in a valid Commit, can refresh leaf key material. A member can also initiate a Commit with a path update to improve protection following a past compromise. In a three-person group, the roster might remain three after a rotation, yet the new epoch should not share all security properties of the old one.
Operational reports should therefore record epoch transitions even when the visible membership count is unchanged. Otherwise, an on-call engineer examining a key compromise has no way to distinguish a rotation that actually took effect from a no-op health indicator. Do not assume that a scheduled key rotation automatically restores protection against an attacker still actively observing the sender’s endpoint.
Worked example: three clients, then four, then three
Use a controlled hypothetical group rather than a claimed production measurement. Alice coordinates a lesson-planning workflow, Ben reviews factual sources, and Cora approves the final explanation. A separate summarization service called Dev joins temporarily, then leaves when its task ends. The example uses epoch labels 7, 8 and 9 to make state changes visible. It assumes correctly validated identities, accepted Commits, uncompromised intended recipients and normal application-message encryption.
Epoch 7: Alice, Ben and Cora
At epoch 7 the membership set is Alice, Ben and Cora, so the headcount is 3 members. Suppose each of them sends two distinct encrypted application messages before any membership change. That is 3 multiplied by 2, giving 6 originating group messages. If every message is delivered to the other two members, the example entails 6 multiplied by 2, or 12 recipient deliveries. The group has not yet enrolled Dev, so Dev has no entitlement to derive the application keys for epoch 7.
Those counts are accounting assumptions, not performance measurements of MLS. In a real service, retransmissions, offline queues, routing fanout, and whether senders receive their own message copies affect observed network traffic. Distinguishing originated messages from forwarded copies prevents an apparently harmless example from concealing an incorrect denominator.
Epoch 8: the accepted Add admits Dev
Dev publishes an appropriate unused KeyPackage, Alice validates its credential and capabilities, and an Add proposal is included in a valid Commit. Existing members process the Commit, while Dev uses a matching Welcome to initialize its state. The agreed membership becomes Alice, Ben, Cora and Dev at epoch 8. A simple dashboard could show 4 members, but its stronger assurance comes from the verified epoch state and the underlying credential checks.
Now suppose each of the four sends two new application messages. That is 4 times 2, or 8 originating messages. Every message forwarded to the three other members produces 8 times 3, or 24 hypothetical recipient deliveries. Dev’s new membership does not retroactively grant the cryptographic keys for Alice’s six epoch-7 messages. Whether the service separately shares earlier archives with new participants is an application-level history policy.
Epoch 9: committed removal excludes Dev
When the summarization task ends, Alice proposes Dev’s removal and a valid Commit advances the group to epoch 9. After clients process it, the group membership is Alice, Ben and Cora, again 3 members. Two fresh sends per member give 6 originating messages and 12 forwarded copies under the same simplified assumptions. Dev should not derive the fresh epoch-9 application keys merely by retaining its epoch-8 state.
Add the three periods carefully: originating messages equal 6 plus 8 plus 6, or 20. Hypothetical recipient deliveries equal 12 plus 24 plus 12, or 48. The average delivery copies per originated message for this scenario is 48 divided by 20, which equals 2.4. That ratio describes this chosen traffic pattern, not bandwidth reduction, cryptographic complexity or an observed service benchmark.
Exactly what a removed member can still know
Dev could have read and retained the epoch-8 messages that arrived while it was an authorized member. A client might also have saved screenshots, produced summaries, copied attachments or written plaintext into another system. MLS does not wipe those outputs. The cryptographic removal is forward-looking: under the required secrecy conditions, Dev lacks keys to decrypt new epoch-9 application messages. It does not erase legitimate knowledge acquired during epoch 8, nor does it by itself revoke access to a separate shared document URL.
Dev should also be barred from sending application messages as a current group member after removal. Clients receiving a purported new message must validate sender identity and epoch membership. A malicious delivery service might forward stale messages or withhold the removal event, so application monitoring has to distinguish a rejected stale sender from a persistent delivery fork. Test both behaviors, not merely that a UI roster shows three names.
A careful count of exposure and protection
Imagine there are eight confidential paragraphs in epoch 8 and six new paragraphs in epoch 9. If Dev legitimately received all eight earlier paragraphs, removing Dev cannot reduce that historical exposure to zero; its potential pre-removal knowledge remains 8 out of those 8 paragraphs. The new protection question is whether Dev can decrypt any of the six fresh epoch-9 paragraphs from retained old secrets. Under successful membership rekeying and no further endpoint compromise, the expected unauthorized decryptions from that route are zero of six.
The numbers are invented solely to explain denominators. They are neither measured security outcomes nor universal success rates. A real assessment should test actual ciphertexts and state transitions rather than declaring an observed zero from protocol theory. It should also separately audit non-cryptographic paths such as document sharing, exports, compromised remaining members and copied API credentials.
Asynchrony and concurrent changes: the difficult middle
MLS is designed for asynchronous groups, but asynchronous does not mean state changes are magically simultaneous everywhere. Devices may sleep, delivery queues may delay a Commit, and two clients may each believe their planned change should happen next. Implementations must have a sequencing and error-recovery strategy. This is especially relevant when a workflow uses cloud agents that restart, autoscale, or pause between tasks.
A sender’s local success is not global agreement
Suppose Alice prepares the Remove Commit at 09:00, but Ben’s device is offline until 09:10. At 09:01 Alice may have advanced locally depending on the service’s accepted ordering, while Ben still stores older group state. A product interface should not treat these as equivalent observations. Document what ‘removed’ means at the API boundary and how old-epoch messages are handled during catch-up.
Security-sensitive commands should be gated on the latest accepted state and tool authorization, not on the remote client’s possibly stale UI. Consider refusing new protected actions until required membership changes are visible to the relevant control plane. Design an explicit timeout and reconciliation strategy instead of silently discarding delayed traffic and calling the missing response a cryptographic error.
Concurrent Commits require a coherent history
Consider Ben and Cora each proposing a membership change against epoch 8. If both independently create competing Commits, the system cannot simply concatenate arbitrary secret trees and declare success. The application must define how the Delivery Service sequences valid changes and how clients recover or retry rejected operations. RFC 9420 discusses the sequencing of state changes; RFC 9750 discusses what different delivery consistency assumptions mean for implementations.
Measure conflict rates separately from cryptographic validation failures. A rejected stale-epoch Commit may be a routine concurrency event, whereas a malformed signed message may indicate tampering or a bug. Use structured error categories so recovery can rebuild from current authenticated state. Blindly resubmitting identical stale bytes across epochs makes both reliability and security worse.
Offline catch-up and irreconcilable forks
A device returning after several epochs needs an authenticated path through the intervening accepted state changes. It may need group metadata or a fresh join depending on what it missed and whether its stored secrets remain suitable. If delivery failed in a way that created incompatible histories, manual or application-directed recovery may be necessary. A cryptographic engine should never ‘catch up’ by skipping validation or importing another member’s private keys.
Set operational thresholds for how long offline devices retain sensitive old state. RFC 9420 points out that long-offline members who keep old keys can create risks for forward secrecy. A project may adopt an expiration and re-enrollment policy, with transparent notice that reinstalling a client or missing crucial state can mean losing access to old encrypted content.
Security guarantees must be read with their conditions
It is easy to translate a protocol’s security properties into a blanket advertisement. The more useful habit is to specify adversary capabilities and the moment at which protection holds. Ask whether the attacker controls the Delivery Service, the Authentication Service, an endpoint, a past key, a current key, or the application’s external authorization layer. MLS addresses several of these threats differently; the remaining controls are part of engineering.
A compromised delivery server can still disrupt the group
A Delivery Service normally should not know protected message plaintext, but an attacker controlling it can selectively delay, drop or reorder messages. The attacker can obstruct an honest participant’s attempts to rotate out compromised state by withholding relevant Update or Commit traffic. Group availability and forward progress therefore deserve active monitoring. Some missing messages can be detected, but not every malicious omission has an obvious local proof.
Protect DS infrastructure with ordinary service security and design application-level loss detection, retries and reconciliation. Avoid a reassuring ‘end-to-end encrypted’ badge that implies reliable delivery. A message can be perfectly confidential and still never arrive. When this happens, report an availability or state-transition failure honestly rather than treating encryption as the root cause.
A compromised identity service threatens membership authenticity
An Authentication Service compromise is more dangerous for impersonation than ordinary DS packet dropping. A dishonest AS might assert that an attacker-controlled signing key belongs to an authorized principal, potentially admitting a fraudulent client. Protocol signature checks alone cannot catch a forged trust assertion if the client accepts that AS’s binding. RFC 9420 and RFC 9750 distinguish this risk from ciphertext confidentiality against a delivery intermediary.
Mitigations depend on system architecture. A team can use transparent identity-key histories, organizational issuance review, device-to-device verification, or independently audited enrollment. Each has usability and operational costs. State exactly what is checked. ‘All messages are signed’ is an incomplete answer to a threat involving a dishonest authority that decides which key is accepted as someone’s identity.
Compromised devices can read their own plaintext
If malware controls a current legitimate client’s process, it can often read decrypted content and may sign malicious application messages with that client’s current credentials. Rotating group secrets cannot make a continuously compromised device trustworthy. To regain security, the compromised endpoint must be remediated or removed and the remaining members must process appropriate fresh state. The application must also revoke tokens that the attacker could have copied.
Threat models need to include inference and export paths: an agent may summarize confidential content to a public channel, issue a web request containing it, or log raw prompts. These are application safety failures even when MLS correctly protects transport. Sandboxing, minimum privilege, human approval for high-impact actions and output controls remain relevant.
Group membership and metadata privacy differ
Payload encryption does not necessarily conceal the group identifier, message frequency, endpoint routing details, or timing of membership changes. A DS may know which clients must receive packets even when it cannot read the payload. Some protocol messages can also be public rather than private. Sensitive organizational patterns can leak through seemingly innocuous counts such as a sharp increase in after-hours messages.
Define which metadata is collected, retained, shown to administrators and exported to monitoring tools. A client-side screen that claims ‘private group’ should be explained as a message-content promise rather than a guarantee of complete traffic-analysis resistance. Where metadata privacy is critical, evaluate surrounding transport, pseudonyms, batching and retention choices without assuming MLS itself solves every observational channel.
Replay, KeyPackage depletion and stale transitions
Replay protection operates at several layers. Protocol state and per-sender key evolution help recipients reject inappropriate duplicates, but applications still need to consider reused KeyPackages, reprocessed invitations and business actions triggered by duplicate plaintext events. A retained ‘last resort’ KeyPackage exists for an availability reason; allowing broad reuse without monitoring should not become a permanent default.
Suppose an instruction says ‘issue one purchase order’ and a buggy integration handles the same valid decrypted application event twice. Even perfect encryption will not make that business operation idempotent. Give consequential tool invocations an application-level operation ID, a current authorization check and a durable deduplication rule. Keep this separate from cryptographic replay handling so reviewers know which problem each control actually solves.
Designing secure groups of real software agents
The phrase ‘agent MLS’ refers here to present-day software processes participating as MLS clients. No existing artificial superintelligence is being asserted. These systems can be ordinary scheduled assistants, research services, document processors or internal workflow components. Their security needs resemble human group messaging in key establishment but diverge in authority, unattended operation, replication and auditability.
Separate task roles from the cryptographic roster
A group might contain a fact collector, a verifier and a publishing service. All three may legitimately receive encrypted planning messages, while only the publisher can send content to a website. The cryptographic roster says which clients share group state; it does not express which messages are instructions, which instructions are authorized, or which outputs need approval.
Write down the application role matrix separately. For example, a reviewer may read draft text and attach comments but may not change publication status. If a privileged instruction arrives from a group member without the required role, the receiving tool must reject it even though the message’s MLS authentication succeeds. This is the practical place where trustworthy automation either holds or fails.
Tie each high-impact action to a fresh permission decision
Consider an internal agent receiving an encrypted message saying ‘publish the new report’. It should verify the origin and epoch, parse the intended task as data, check whether the sender has live permission to request publication, and verify any required human approval. The decision should include the exact target resource and action. If the same sender loses permission five minutes later, previously queued work must not be assumed permanently authorized.
A sensible design uses short-lived application credentials, auditable authorization decisions and cancellation semantics for pending jobs. Do not let a long-running task treat an MLS signature from yesterday as an eternal authorization token. Cryptographic authentication proves a message’s origin under the group state; policy asks whether this operation is permitted now.
Make removal a multi-system procedure
When an agent exits a sensitive workflow, finish or cancel its assigned jobs, revoke independent API credentials, remove access to relevant external storage, and Commit its removal from MLS groups. Ensure remaining clients process the new state. Also review what plaintext the agent might have exported before departure. Those steps can occur in a coordinated workflow but should be reported as separate evidence items.
A completion report might say: group removal committed, two of two online remaining clients verified epoch update, one external API credential revoked, pending task canceled, and archival data reviewed. These are illustrative fields, not a claim about a deployed environment. If one field remains unknown, mark the operation partially complete and constrain further access. Do not convert a stale membership display into a claim that all access has ended.
Logs should prove transitions without dumping secrets
A helpful event trail records group identifier or an appropriate pseudonym, initiating client, epoch-before, intended operation, validation result, accepted Commit reference, epoch-after, and per-client processing acknowledgements where available. It should not store private tree material, application plaintext or complete decrypted secrets. Debugging needs to distinguish an authentication rejection from a networking timeout without creating a durable copy of every private conversation.
Choose retention periods and access rights appropriate to organizational risk. Cryptographic logs are evidence about processing, not a substitute for audit review. For a sensitive incident, investigators should be able to trace why a specific agent was enrolled, which policy granted communication membership, who approved removal and when remaining devices had actually advanced.
Failure diagnosis and practical repairs
Troubleshooting should begin with a narrow question: is the failure in identity validation, KeyPackage availability, proposal validation, Commit sequencing, Welcome processing, epoch catch-up, or application authorization? A generic ‘cannot decrypt’ alert is not enough because the remediation differs sharply. Build separate tests for each boundary and include at least one negative example that must be rejected.
Failure: the wrong KeyPackage or an expired credential
A Welcome that cannot be opened may correspond to a KeyPackage whose private key is missing or no longer held by the intended device. A credential might also fail policy checks before a member is added. The right first repair is to inspect references and identity bindings, not to weaken signature verification. Confirm that the device produced the package and retained the correct private key, then replace the pending invitation with fresh authenticated material when necessary.
Add metrics for consumption, expiry, and validation failures per client. A single global inventory chart hides the one isolated worker that has exhausted all packages. Prevent the DS from silently serving a stale package indefinitely. When a last-resort exception is deliberately configured, document the risk and monitor reuse instead of disguising it as normal provisioning.
Failure: Commit conflicts or missing proposals
Two clients creating Commits from the same earlier epoch may produce a sequencing conflict even if each was individually well formed. A recipient might also be missing a referenced Proposal. The repair starts by retrieving the accepted authenticated group history according to the delivery policy, then retrying a still-permitted operation against the current state. Blindly replaying the original bytes is unsafe because proposals and paths are bound to specific state.
Operationally, distinguish duplicate submission, stale state, malformed cryptographic data and unauthorized group mutation. These diagnoses may all appear as ‘update failed’ to an end user, but they have different security meanings. Include the epoch and proposal identifiers in safe diagnostic records so responders can determine whether to retry, rejoin or investigate tampering.
Failure: an offline member cannot catch up
A long-offline device might miss one or more Commit messages, lose a local key, or return with state too old for the application’s retention policy. Engineers should check message history, local secure state and membership policy before attempting repair. Depending on what remains available, the device may legitimately process a backlog or need to be removed and re-enrolled. Never import another member’s private secrets merely to create a green dashboard indicator.
Design an explicit recovery user experience. Explain when historical messages are no longer available, when keys need refreshing, and when an administrator must approve a new device. Encryption does not obligate a system to keep old secrets forever. Safe recovery can preserve future membership while honestly acknowledging lost past material.
Failure: removal succeeds cryptographically but access remains
Suppose Dev cannot decrypt epoch-9 messages yet can still fetch the same task document from a cloud drive using a cached token. MLS removal worked; the authorization workflow failed. The diagnosis belongs to credential inventory, shared links and external resources, not the cipher suite. Another failure mode is a still-authorized remaining member automatically forwarding decrypted group messages to Dev through a different tool.
Run an end-to-end revocation exercise that tests all important channels: future MLS ciphertext, API calls, storage links, queued jobs, cached files and notification routes. Record test scope and findings separately. One successful failed-decryption test does not establish all those other guarantees. This distinction helps security teams direct repair to the responsible component.
Transfer exercise: the group changes context
Try a different situation. A hospital’s internal coordination team uses three services to handle a nonclinical scheduling workflow: Roster, Checker and Messenger. A temporary contractor-run Translator service must process public event notices but must never see patient information. Someone proposes adding Translator to the existing encrypted group that also carries confidential patient scheduling details. Should the team add Translator and rely on MLS to filter what it reads?
No. MLS establishes which clients share group secrets; it does not provide per-message role-based visibility inside one epoch to members that share the relevant application encryption state. The team should create a separate group containing only appropriately shareable material or ensure that restricted material never enters a group whose members lack access. It should verify Translator’s credential and job authorization before addition, then remove and revoke associated external capabilities when the limited task ends.
Now change the facts: Translator is an independently managed client whose credential is valid, but the delivery service has not acknowledged its removal Commit. The right answer is not simply ‘deleted from roster, safe’. The team must establish which membership transition was accepted and processed, gate restricted work while uncertainty persists, and avoid sending sensitive new traffic under stale state. An agreed current epoch, correct application policy and client acknowledgements are complementary evidence.
Transfer calculation: dividing groups instead of filtering inside one
Assume a group has five clients, of which only three may see confidential records. If all five share the same epoch secrets for all messages, the protocol cannot enforce the desired 3-out-of-5 visibility merely by labeling messages ‘restricted’. A simple arrangement is two groups: a restricted group of 3 authorized clients and a general coordination group of 5 clients. An authorized service may participate in both, but it must enforce a rule against copying restricted content into the general group.
Suppose three restricted messages are sent to the other two restricted participants, giving 3 times 2 equals 6 recipient deliveries in that group under a one-copy-per-peer assumption. Sending those same three messages to all four other members in the general group would give 3 times 4 equals 12 deliveries, including unauthorized access paths. The arithmetic illustrates recipient scope; it is not a benchmark of MLS networking overhead.
A deployment review that can survive an incident
Review the system from the attacker and operator viewpoints. Start with what identities mean; verify KeyPackage generation, lifetime, capability checks and secure storage. Confirm protocol state transitions with tests that add, update and remove members under offline and concurrent conditions. Inspect delivery consistency choices, restoration after crashes and the handling of insecure debug output. Treat tools, files and business authorizations as separate assets. The standard secures a group key-agreement mechanism; the application must secure its own behavior.
Before production use, run failure-injection tests: remove a current client while another is offline; present a reused KeyPackage; deliver a stale Commit; suppress a legitimate Update; corrupt a Welcome; alter a credential binding; and ask an authenticated but unprivileged agent to invoke a forbidden tool. Each test should have a documented expected result, a measurable observed result, and a repair path. Do not silently treat unexpected behavior as proof that the security property cannot be checked.
Frequently asked questions
Does MLS make a delivery server unable to harm users?
No. It can protect application-message confidentiality from the delivery intermediary, but the server can still delay, suppress or interfere with availability, and it may expose some metadata. RFC 9420 describes how suppression can even obstruct recovery from a previous compromise. Applications therefore need operational detection, reliable state synchronization and a threat model that separates confidentiality from availability.
Can a removed member read earlier messages?
A member may retain plaintext it legitimately received before removal. Cryptographic exclusion concerns fresh secrets and messages after a valid committed transition. Whether older history is stored, shared with new members, deleted or retained is an application policy. The right security statement is specific about epochs and storage, not a claim that removal retroactively destroys all knowledge.
Is an Add proposal the same as approved admission?
No. A proposal expresses a candidate change. A valid Commit advances group state, while the surrounding application must also validate identity and authorization. Some deployments include additional approval processes before a client is allowed to propose or accept membership operations. Users should see separate states for pending, accepted and fully processed changes where those distinctions matter.
Does MLS authorize tools used by AI agents?
No. MLS authenticates group participants and protects group messaging under stated assumptions. A service that receives an encrypted instruction still needs to check whether the sender may invoke a particular tool with particular arguments now. Group membership does not override least-privilege access control, approval requirements or cancellation rules.
Why not reuse a KeyPackage indefinitely?
KeyPackages are designed for limited use; RFC 9420 warns that reuse can create replay risk. Last-resort packages are an explicit availability trade-off rather than an excuse to avoid inventory management. Rotate and replenish packages, monitor per-client counts and use the library’s validation rules. Do not solve enrollment failures by deleting authentication checks.
Does a key rotation automatically restore security after compromise?
Not against a continually compromised endpoint. Post-compromise recovery relies on honest members establishing fresh state that the attacker no longer knows, and relevant parties processing the resulting Commit. If malware still reads the endpoint’s current secrets and plaintext, cryptographic rotation alone cannot remove its presence. Endpoint remediation, member removal and external credential revocation may all be necessary.
Can MLS be used for only two clients?
Yes. The protocol and architecture allow small groups as well as larger ones. Whether MLS is a sensible choice for a particular two-client service depends on interoperability, existing infrastructure, security requirements and complexity. Do not assume a group protocol must be reserved for hundreds of members or that its use proves any special AI capability.
Further reading: protocols, architecture and related routes
For the normative cryptographic protocol, read IETF RFC 9420, Messaging Layer Security, especially Sections 3, 7, 10, 12, 14 and 16. For the architecture, read IETF RFC 9750, MLS Architecture, especially the identity, delivery, operational and security sections. For the HPKE component used in KeyPackages, see IETF RFC 9180, Hybrid Public Key Encryption. These are official sources, not guesses about how a particular vendor’s product is deployed.
Within the wider eduKate technical reading collection, TLS delegated credentials explores a different identity and short-lived-key problem, QUIC address validation concerns network endpoint reachability, and CONNECT-UDP and MASQUE concerns proxy transport boundaries. Those topics complement MLS rather than replace its membership cryptography. The superintelligence systems hub collects the broader engineering and governance routes.