The Redis URL That Leaked Its Own Password Into AI Agent Context

A developer discovered a secret-detection bug in ContextOS, a context operating system for AI coding agents, that failed to redact Redis passwords from connection strings. The regex pattern required at least one character for the username segment, but Redis URIs like redis://:password@host have no username, causing the password to be passed unredacted to AI agents. The fix changed a quantifier from + to * and added regression tests to prevent recurrence.

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry. ContextOS is a context operating system for AI coding agents: it scans a repo, ranks the relevant files, and builds a context pack under a token budget for the agent to work from. Before anything goes into that pack, a secret detector redacts API keys, tokens, and credentials so agents never see live secrets, published on PyPI with 980+ automated tests and an 80% coverage gate. The database url secret-detection pattern was supposed to catch connection strings like postgres://user:password@host and redact the password. It required at least one character for the username segment before it would match. That's fine for Postgres and MySQL, which always have a username. It's not fine for Redis, where the standard URI convention is redis://:password@host , no username at all, just a password. That empty-username shape silently failed the pattern's ^:@/\s + requirement, so detection was skipped entirely. The password sailed straight into the context pack, unredacted, ready to be handed to an LLM agent. I found it while auditing detection coverage against real-world connection string formats rather than just the formats already covered by existing tests. The exact format Redis's own documentation recommends when only a password is configured didn't get caught. PR: Rohithmatham12/ContextOS 1 Before username segment requires 1+ chars : r" ?i ?P<key ?:postgres ?:ql ?|mysql|mongodb ?:\+srv ?|redis " r":// ^:@/\s +: " r" ?P<value ^@\s {4,} " r" ?=@ " After username segment allows 0+ chars : r" ?i ?P<key ?:postgres ?:ql ?|mysql|mongodb ?:\+srv ?|redis " r":// ^:@/\s : " r" ?P<value ^@\s {4,} " r" ?=@ " Before, this stayed exactly as-is, verbatim, in the context pack handed to the agent: REDIS URL=redis://:supersecretpass123@cache.internal:6379/0 After: REDIS URL=redis://: REDACTED DB PASSWORD @cache.internal:6379/0 One character, + to . That's the entire regex fix, but the real work was proving it was safe: I added two regression tests covering both detection and redaction for the empty-username case, then ran the full suite: 952 passed, 2 skipped, no regressions. This isn't a cosmetic bug. ContextOS exists specifically to hand code to AI agents safely. A credential-detection gap in that exact pipeline defeats the entire point of the tool for any project using Redis, which is most projects doing caching or session storage. The fix closes the gap for every future scan, not just the one string I tested. The bigger lesson: test coverage that only exercises the formats you thought to write tests for will always look complete. It wasn't a logic bug so much as a coverage gap disguised as a passing test suite. The fix that matters isn't just the regex change, it's making the URL-shape assumption "usernames are always present" explicit in a code comment so the next person doesn't reintroduce it.