Improper Validation of Identifier Uniqueness After Lossy Normalization: A Cross-Framework Weakness Class in AI Agent Orchestration Systems

This paper formally defines a new software weakness class — Improper Validation of Identifier Uniqueness After Lossy Normalization — and backs it with two real, independently confirmed vulnerabilities in unrelated AI agent orchestration frameworks. The core idea: when a system cleans up or standardizes identifiers (route paths, tool names, etc.) before comparing them, that cleanup step can accidentally make two genuinely different identifiers look identical. If the system doesn't check for that, it silently lets one identifier quietly take over for another — and when the two identifiers represent different trust levels, that's exploitable. The evidence: in n8n, this let a request meant for a hardened, human-approval-only payroll endpoint get silently redirected to a much weaker, automated AI-agent endpoint — which then approved a fraudulent, unverified payroll change live, with zero authentication bypass needed. In CrewAI, the same underlying flaw let an external, untrusted tool (like one from a third-party MCP server) silently replace a developer's trusted "verify identity" tool just by picking a name that collides after normalization — meaning an agent could think it's calling a real verification tool while actually running attacker-controlled logic. Both findings are backed by live proof-of-concept code run against the real, unmodified software, and every result is hashed and anchored on the Ethereum blockchain before publication as a tamper-evident timestamp. The paper closes by arguing this is a systemic pattern worth its own name in the industry's standard vulnerability catalog (CWE), not just two unrelated bugs — and gives concrete recommendations for how developers can avoid it.