A protocol can be secure on its own and still become dangerous the moment it starts communicating with another one.
That's the problem I'm investigating with Interoperability Cross-Contamination (IXC).
IXC occurs when information crosses between agents, tools, or protocols and the payload survives, but its security meaning doesn't. Role, provenance, permissions, scope, or task lifecycle can be lost or reinterpreted during translation.
The attack pattern:
Untrusted input → Legitimate protocol handoff → Semantic context loss → Authority rebinding → Unauthorized downstream behavior.
Imagine Agent A receives a task that is later canceled. A bridge forwards the original task content to Agent B but fails to preserve its canceled state. Agent B interprets the content as an active request and potentially executes it.
Neither system necessarily violated its own protocol. The failure happened between them.
That's what makes IXC interesting. Both sides can pass schema validation, authenticate correctly, and process structurally valid messages while still producing an unauthorized result.
The attacker isn't necessarily exploiting either protocol individually. They're exploiting the difference between what one system means and what another system understands.
This is a trust boundary problem disguised as interoperability.
If your bridge preserves the payload but loses its provenance, lifecycle, or authority constraints, it can transform untrusted information into executable instruction.
The attack surface isn't always the endpoint.
Sometimes it's the translation itself.
$IXC | Interoperability Cross-Contamination
CA: 2p4MoqrVBURSFfAbFLyCBxU8uqD9MsDznDH3iX4hpump