December 16, 2025
GIDs Gone Wild
Be Careful with GIDs in Rails
AI grabs wrong invoice—dev points at Rails, commenters clap back
TLDR: A developer’s AI bot guessed a record link and pulled the wrong invoice, sparking warnings about using Global IDs safely. Commenters say the real fix is signed IDs and proper access checks—and the real culprit is trusting an AI to write app logic without guardrails.
A Rails dev plugged a large language model (LLM—think ChatGPT-style bot) into their invoicing app and watched it go rogue: the bot crafted a fancy Global ID (a text handle like a URL to a record) and fetched the wrong invoice. Cue panic. The author warns these Global IDs can be "treacherous" with AI, but the crowd wasn’t buying a Rails blamefest. Top comment energy: “the AI hallucinated and somehow it’s Rails fault?” One camp shouted, “Use signed IDs!”—a built‑in feature that creates tamper‑proof links—and reminded everyone that raw IDs are for internal jobs, not public APIs. Another camp rolled their eyes at the title, arguing the real problem is letting an LLM write glue code without guardrails.
Then came the nerdy nuance: signed IDs are signed (verifiable) but not encrypted, so you still need access checks. One commenter deadpanned: “Rails is a dangerous place to be throwing random data into APIs,” as the thread devolved into riffs about bots cosplaying as accountants. Someone asked if big apps even use Global ID, and the subtext was: yes, internally, not as a user-facing ticket to your data. The vibe: Rails didn’t fail—your AI did. Guard your IDs, sign them, and don’t let a chatbot run your finance department.
Key Points
- •Rails Global IDs (GIDs) are string identifiers (gid://app/Model/ID) used to reference models, primarily for ActiveJob serialization.
- •GIDs are trusted identifiers and their resolution does not inherently perform authorization checks.
- •GID resolution relies on ActiveRecord::Base.find, which can return records based on the primary key extracted from the GID.
- •Using GIDs in LLM tool calls can be risky because LLMs can fabricate or modify GID strings, leading to unintended lookups.
- •The author observed a case where an LLM substituted a UUID into a GID, which resolved to the wrong invoice without raising an error.