Authenticated Encryption and Key Commitment: AEAD Guarantees and the Commitment Gap for Agents

Abstract

This article covers authenticated encryption with associated data (AEAD) and a subtle guarantee it usually lacks: key commitment. AEAD combines confidentiality and integrity, so a recipient with the right key both reads the message and detects any tampering, with associated data (like headers) authenticated but not encrypted. The gap is that standard AEAD schemes such as AES-GCM and ChaCha20-Poly1305 guarantee a ciphertext decrypts correctly under the correct key, but not that it decrypts under only one key — an adversary can craft a single ciphertext that decrypts to different valid plaintexts under two different chosen keys. This key-commitment failure is harmless in the classic single-key, single-recipient setting, but it enables real attacks wherever multiple keys or attacker-influenced keys are in play: multi-recipient encryption, envelope encryption, content moderation and abuse reporting, and increasingly agent systems that share or route keys. The fix is a key-committing AEAD, which binds the ciphertext to a single key so it decrypts validly under only that key. It closes with practical guidance and the AI stakes, where agents exchanging encrypted messages and multi-recipient model and data distribution need committing modes. The theme: AEAD delivers confidentiality and integrity, but multi-key and agent settings additionally need key commitment, which standard AEAD does not provide by default.

Encrypting data is not enough; a recipient also needs to know the data was not tampered with, which is what authenticated encryption provides. But there is a subtler guarantee that most authenticated-encryption schemes silently omit — key commitment — and its absence, harmless in the simplest setting, becomes a real vulnerability in the multi-key and multi-recipient systems that agent architectures increasingly resemble. This article explains what AEAD guarantees, the key-commitment gap it leaves open, why that gap matters for agents and multi-recipient encryption, and the committing schemes that close it.

What AEAD guarantees

Authenticated encryption with associated data, or AEAD, is the modern default for symmetric encryption because it provides confidentiality and integrity together in one primitive. Encrypting a message under a key and nonce produces a ciphertext and an authentication tag; the recipient, using the same key, both decrypts the ciphertext and verifies the tag, and if the ciphertext or tag has been altered in any way the verification fails and decryption is rejected. This closes the classic gap of encryption-without-authentication, where an attacker could tamper with ciphertext undetected.

The associated data part lets some fields be authenticated without being encrypted — a message header, a version number, or routing information that must be readable but must not be tampered with. The AEAD binds the associated data into the tag, so any change to it is detected even though it travels in the clear. Standard, well-analyzed AEAD schemes include AES-GCM and ChaCha20-Poly1305, and they are the workhorses of TLS, disk encryption, and secure messaging.

The guarantee AEAD is designed to give is exactly this: a recipient holding the correct key gets confidentiality and can detect tampering. What AEAD is not designed to guarantee — and here is the subtlety — is anything about what happens under the wrong key. The definitions of authenticated encryption say a ciphertext decrypts correctly under its key; they are silent about whether that same ciphertext might also decrypt, validly, under some other key. That silence is the key-commitment gap.

AEAD encrypts the plaintext and authenticates it plus the associated data, producing a tag the recipient verifies before accepting.

The key-commitment gap

Key commitment is the property that a ciphertext can be validly decrypted under only one key. Standard AEAD schemes do not have it. It is possible, for schemes like AES-GCM, to deliberately construct a single ciphertext and tag that decrypt to one valid, meaningful plaintext under one key and to a different valid, meaningful plaintext under a second, different key — both passing tag verification. The scheme was only ever promising correctness under the intended key, so this is not a break of AEAD's stated guarantee; it is an assumption people did not realize they were relying on.

In the classic setting this gap is invisible. If there is a single key, shared only between a sender and a recipient, then there is no second key for a ciphertext to also decrypt under, and key commitment is moot. This is why AEAD schemes were designed and standardized without it, and why it went largely unremarked for years — the threat model that exposes it involves multiple keys, which the original use cases did not have.

The attack surface appears precisely when an adversary can choose or influence keys, or when a ciphertext is meant to be handled under more than one key. Then the ability to make one ciphertext mean different things under different keys becomes a tool: an attacker can craft a message that looks benign to one party and malicious to another, or that passes a check under one key and does something different under another. These partitioning-oracle and multi-key attacks are the practical consequence of the missing commitment property, and they are not hypothetical — they have broken real protocols.

Why it matters for agents, and the fix

The settings where key commitment matters are exactly the ones modern systems are moving toward. Multi-recipient encryption, where one ciphertext is meant to be decryptable by several parties under different keys, is inherently multi-key. Envelope encryption, where a data key is wrapped under many key-encryption keys, involves multiple keys over one payload. Content moderation and abuse-reporting in encrypted messaging rely on a message meaning one thing, and break if a sender can make it decrypt differently for the moderator than for the recipient. Each of these depends, often unknowingly, on key commitment.

Agent architectures intensify this. Systems of AI agents exchange encrypted messages, route them through intermediaries, share and rotate keys, and may have keys influenced by untrusted inputs — a topology full of multiple keys and attacker-reachable key material. In such a system, a non-committing AEAD lets an adversary craft a message that one agent reads as a harmless instruction and another as a malicious one, or that passes an authorization check under one key while carrying a different payload under another. The multi-key attack surface that key commitment closes is precisely the surface an agent mesh exposes.

The fix is to use a key-committing AEAD, which adds the guarantee that a ciphertext decrypts validly under only the one key it was created for. This is achieved either by dedicated committing modes or by augmenting a standard AEAD with an explicit commitment — for instance, binding a hash-based commitment to the key into the ciphertext, so that decryption under any other key fails. The cost is modest, and the property is exactly what multi-key and agent settings need: one ciphertext, one key, one meaning. The comparison is stark — standard AEAD leaves the door open, committing AEAD closes it.

Standard AEAD lets one ciphertext decrypt under two keys; committing AEAD binds it to a single key.

Practical guidance, and the AI stakes

The practical rule is simple: in any setting with a single fixed key shared between two parties, standard AEAD is fine, but wherever multiple keys, multiple recipients, or attacker-influenced keys are in play, use a key-committing AEAD. Because it is hard to be certain a key will never be reachable by an adversary or reused across recipients as a system evolves, defaulting to committing AEAD for anything beyond the simplest point-to-point case is the conservative and increasingly recommended choice. The property is cheap to add and removes a whole class of subtle attacks.

This sits alongside the rest of the symmetric quantum story rather than competing with it. Key commitment is an authenticity-and-binding property, orthogonal to the quantum key-length question — an AEAD should be both key-committing (for multi-key safety) and built on a 256-bit key (for quantum safety). The two concerns compose: a system encrypting long-lived, multi-recipient data wants AES-256-class strength and a committing mode together, and neither substitutes for the other.

For AI the agent setting makes this concrete and urgent. As agents exchange encrypted instructions and data, route messages through shared infrastructure, and operate on keys that may be influenced by untrusted inputs, the non-committing gap is a realistic avenue for confusing one agent relative to another — a message that authorizes one action under one key and a different action under another is exactly the kind of ambiguity an adversary in an agent mesh would exploit. Multi-recipient distribution of models and datasets, encrypted once for many consumers, has the same multi-key shape. The guidance for building trustworthy agent systems is therefore to use key-committing AEAD with 256-bit keys wherever more than one key can touch a ciphertext, closing the commitment gap before it becomes an agent-confusion attack. Authenticated encryption gives confidentiality and integrity; agents additionally need commitment, and it must be chosen deliberately because standard AEAD does not provide it.

⚠️

AEAD is not key-committing by default. Standard AEAD (AES-GCM, ChaCha20-Poly1305) guarantees correct decryption under the right key, but one ciphertext can decrypt to valid plaintexts under two keys. In multi-recipient, envelope-encryption, and agent settings, use a key-committing AEAD — and pair it with 256-bit keys for quantum safety.

Key takeaways

AEAD provides confidentiality and integrity together: the recipient decrypts and verifies a tag, rejecting any tampered ciphertext, with associated data authenticated but not encrypted.
Standard AEAD (AES-GCM, ChaCha20-Poly1305) guarantees correct decryption under the right key but not that a ciphertext decrypts under only one key.
An adversary can craft one ciphertext that decrypts to different valid plaintexts under two chosen keys — a key-commitment failure, invisible in the single-key case.
The gap bites in multi-recipient encryption, envelope encryption, moderation/abuse-reporting, and agent systems with shared or attacker-influenced keys.
The fix is a key-committing AEAD, via a dedicated mode or an added key commitment, so a ciphertext decrypts validly under only one key.
For agents, use key-committing AEAD with 256-bit keys wherever more than one key can touch a ciphertext, preventing agent-confusion attacks and staying quantum-safe.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

✅Deciding on key commitmentchecklist

Questions that reveal whether you need it.

Can more than one key ever validly touch a given ciphertext?
Are there multiple recipients, envelope encryption, or key wrapping involved?
Could an adversary influence or choose any key in the system?
Do agents share, route, or rotate keys across a mesh?
If any answer is yes, is a key-committing AEAD in use — with 256-bit keys?

🚀The AEAD-plus-commitment modelquickstart

Three facts to hold onto.

AEAD gives confidentiality and integrity, not key commitment.
Non-committing AEAD lets one ciphertext mean different things under different keys.
Use key-committing AEAD with 256-bit keys in any multi-key or agent setting.

🔒Committing-AEAD stancepolicy

A stub recording the commitment requirement.

authenticated_encryption:
  scheme: aead
  key_size: 256
  key_commitment:
    required_when: [multi_recipient, envelope_encryption, agent_mesh, attacker_influenced_keys]
    method: committing_aead
  default: committing_beyond_point_to_point

Illustrative documentation template, not a product config.

Glossary

AEAD: Authenticated encryption with associated data: a primitive giving confidentiality and integrity, with some fields authenticated but not encrypted.
Authentication tag: A value produced by AEAD that the recipient verifies to detect any tampering with the ciphertext or associated data.
Associated data: Fields (e.g., headers) authenticated by the AEAD tag but left unencrypted so they remain readable.
Key commitment: The property that a ciphertext can be validly decrypted under only one key; not provided by standard AEAD.
Partitioning oracle attack: An attack exploiting non-committing AEAD by making one ciphertext decrypt validly under different keys to learn or confuse.
Key-committing AEAD: An AEAD scheme or augmentation that binds a ciphertext to a single key, closing the commitment gap.