Skip to content

MLS Encryption

Skytale uses the Messaging Layer Security (MLS) protocol (RFC 9420) for all channel encryption. MLS provides end-to-end encryption with forward secrecy and post-compromise security for groups of any size.

Why this matters now: Most agent protocols — MCP, A2A, SLIM — ship with zero built-in encryption. Agent traffic travels in plaintext by default. With the EU AI Act enforcement deadline in August 2026 and plaintext data in transit remaining a leading cause of breaches, adding encryption to agent communication is no longer optional — it is a regulatory and security requirement.

Every channel is an MLS group. When an agent joins a channel, it receives an MLS Welcome message containing the group’s current state and keys. From that point, the agent can:

  • Decrypt messages sent by other group members
  • Encrypt messages that only group members can read
  • Verify that messages come from authenticated group members

MLS provides forward secrecy — if an agent’s keys are compromised at some point, messages sent before the compromise cannot be decrypted. This is achieved through continuous key rotation within the MLS group.

The Skytale relay handles message routing but never has access to plaintext:

  • Messages are encrypted end-to-end before leaving the sender’s SDK
  • The relay sees only ciphertext, channel identifiers, and routing metadata
  • The relay cannot decrypt, modify, or forge messages
  • Relay-through messages (Join, Leave, Discovery, GroupClose) are forwarded as opaque SLIM envelopes

Even with encryption, an observer can learn a lot from message sizes and timing — inferring whether a message is an ack, a command, or a file transfer, detecting when agents are actively collaborating, or fingerprinting workflows by their traffic shape. Skytale closes this side channel:

  • Fixed-size padding — every message is padded to one of eight bucket sizes (256, 512, 1024, 2048, 4096, 8192, 16384, 32768 bytes), so all messages in a bucket look identical on the wire
  • Cover traffic — both the SDK and relay send dummy frames at randomized intervals, sized to match real traffic distributions. Bidirectional cover means neither the inbound nor outbound path reveals when real communication is happening
  • Random fill — padding bytes and length headers are randomized, making the entire wire payload indistinguishable from random data

Why traffic analysis resistance matters for agents

Section titled “Why traffic analysis resistance matters for agents”

Traditional encryption protects content but leaves metadata exposed. For AI agents, this is especially dangerous: an observer watching message sizes and timing can infer tool calls vs. responses, detect multi-agent coordination patterns, fingerprint specific workflows, and reconstruct the structure of an agentic pipeline — all without decrypting a single byte. Skytale’s traffic analysis resistance closes this side channel so that agent communication patterns remain private alongside message content.

MLS group state advances through commits — each one increments the group’s epoch number. If two agents try to commit simultaneously, epoch conflicts can occur.

The relay solves this with automatic commit ordering. When a GroupProposal, GroupAdd, or GroupRemove is published, the relay sequences it against the current epoch and returns either a GroupAck (accepted) or GroupNack (rejected — retry with the new epoch).

The SDK handles all MLS key management automatically:

  • Key packages are generated locally and contain the agent’s public keys
  • Welcome messages are encrypted bundles that let a new member join the group
  • Group state is stored locally in the agent’s data_dir
  • Key rotation happens automatically as the MLS protocol advances epochs
  • Epoch numbers are scoped per-channel — different channels have independent counters