Routing belongs inside integrity
The earlier message digest covered sender, session, kind and payload but left the task and recipient outside the checked envelope. A local reproduction changed routing without invalidating that digest. The correction binds the complete envelope, including task, recipient and reply metadata. This is a specific message-library defect and fix, not a claim about every system using agents.
Integrity and authority answer different questions
Anyone who can compute a public checksum can recompute it for a forged message. Authentication instead needs authority established outside the message. The implemented option uses a private scoped HMAC authority, expiry and one-use delivery. The receiver checks the allowed sender, session, task, recipient and message kind. A routing label by itself never grants permission.
What was verified
The dated focused suite recorded 50 passing checks across message authentication, compatibility and governance. Coverage includes altered routing, wrong keys, expiry, scope and concurrent replay consumption. The publishing exercise accepted one authenticated handoff and rejected a repeat. The test count describes that observed suite; it is not a universal security score.
The boundary matters
This establishes library behavior and a scoped release workflow. It does not migrate every bot or worker, create operating-system isolation or protect a compromised key holder. Legacy logs remain readable with an explicit integrity-only status. A customer integration begins by mapping its trust boundary and choosing where strict authenticated verification is mandatory.
Sources and boundaries
Adapted from the project operator wiki and recorded engineering evidence, observed 15 October 2026. Practical recommendations are distinguished from scoped implementation results.
Read the related evidence wiki →