What Happened
Security research on SequenceHash identifies a protocol flaw: hashing values after simply concatenating them erases their boundaries. Two different sequences can then produce the same hash input, potentially allowing forged Fiat–Shamir proofs or commitments that can be opened in more than one way [1].
SequenceHash addresses this by appending a 128-bit byte count to each value. It also uses a double-hash construction to resist length-extension attacks and offers customization strings to bind a result to its intended context. SequenceMAC is a keyed counterpart. An open specification, test vectors and initial Rust, Go and Python implementations are available [1].
Why It Matters to Businesses
AI applications routinely bind together user identity, prompts, retrieved documents, tool arguments and outputs. If a system hashes those fields for an audit record, approval or authorization decision, ambiguous encoding can undermine what the hash is supposed to identify. A hash is only evidence of the values the application actually included and encoded consistently. SequenceHash addresses boundary ambiguity; it does not establish that an agent’s action was authorized or that its inputs were trustworthy [1].
Kimbodo Engineering Perspective
We would treat this as a protocol-design issue, not a reason to replace every existing hash. Where an application already uses a canonical, reviewed encoding, changing formats introduces migration and interoperability costs. Where teams concatenate variable-length fields before hashing or authenticating them, an unambiguous sequence construction is a practical safeguard [1].
This control sits alongside, not in place of, defenses for prompt injection, tool misuse and data exposure. Frameworks such as OWASP AI guidance and MITRE ATLAS can help organize those broader threats; SequenceHash addresses the narrower question of exactly which byte sequences a cryptographic result represents.
How We Would Implement It
- Inventory hashes and MACs used for agent audit events, approvals, cache keys and cross-service messages. Identify any construction that concatenates fields without unambiguous boundaries.
- Define a versioned field order and byte encoding. Include every security-relevant value, such as tenant, actor, tool, action, arguments and policy version; use a distinct customization string for each protocol purpose [1].
- Use SequenceHash where an unkeyed commitment is appropriate and SequenceMAC where keyed authentication is required. Keep authorization checks separate from either construction [1].
- Verify implementations against the published test vectors, then test field-boundary collisions, omitted fields, reordered fields and cross-context replay before rollout [1].
Risks, Costs and Security
Security still depends on the underlying hash. The specification discourages outputs shorter than 256 bits; SequenceMAC requires keys of at least 32 bytes, and longer keys do not necessarily add security [1]. Consistent encoding and complete field selection remain application responsibilities.
Adoption also requires format versioning, coordinated verification across services and careful migration of stored records. Most importantly, cryptographic binding does not prevent an AI agent from following malicious instructions or receiving excessive privileges. Those require separate input handling, constrained tools, access controls and monitoring.
Where Kimbodo Comes In
Kimbodo builds and operates this in production for businesses — see our AI Security & Guardrails practice, or Request a Security Review.
