Your Coding Agent Already Knows Where the Password Went

The DataParade scanner reads code. Code tells you what a system does. It does not tell you why, and it is quiet about everything that was considered and rejected. The decision to use component A instead of component B, the promise that a password never gets stored in plaintext, the moment someone said "we'll just log the whole request for now": none of that is in the parse tree.

It used to live in people's heads and in the occasional design doc. Now it lives in coding-agent session histories. If you build software with Claude Code, Cursor, Codex, Grok Bot or Antigravity, the conversation where you decided how to handle that email address is on your machine, in a file, with a timestamp. It is the most complete record of design intent most teams have ever had, and nobody reads it.

The short version: we built BotSpy, a local, read-only tool that reads all five agents' histories into one schema and one SQLite store with full-text and semantic search. It started as a joke about counting F-bombs. It is turning into the next evidence source for the DataParade knowledge base, and the interesting problem is not reading the transcripts. It is deciding what in a mountain of text counts as a claim about data.

It started as a meter

The first thing I built on top of my own session histories was a meter that shows the balance between the number of times I say thanks to a coding agent and the number of times I swear at it. As an indicator of how the day is going. Across 3,009 messages the average sentiment was mildly positive, with 1,385 positive, 1,041 neutral, 583 negative and 168 F-bombs. One agent was friendlier than the rest. Another was the only one I was net negative with in the last 24 hours.

This is not a product. But to build it I had to solve the real problem, which is that five agents store their histories five different ways: JSON lines here, a SQLite database there, a database in write-ahead-log mode that the live app holds open. BotSpy has one adapter per agent, snapshots live databases through a read-only copy so the source and its WAL are never touched, and normalizes everything to Session, Message and Part with provenance back to the exact file, line or row. There is no server and nothing leaves the machine. Delete one directory and no copy remains.

The sensitive-data visibility is deliberate. Every architecture diagram in the repository marks where session content lives, and there is a document listing every path the tool reads, copies or writes. If we are going to be the privacy tool, the privacy tool's own tools should be legible.

A mountain of text, and what to pull out of it

Session traces almost certainly hold information that could improve the knowledge base. The question is how. A month of sessions is millions of tokens, most of it tool output, diffs and the agent thinking out loud. The claims we care about are sparse: "the Stripe webhook payload includes the customer's email, we don't persist it", "switch the session store from Redis to Postgres", "hash the token before writing it".

The approach we are testing is to tie chunks of that text to the semantic concepts the knowledge base already tracks. We know the data items, the components and the flows from the scan. So the retrieval question is not "what is in these transcripts" but "what do these transcripts say about this data item". That is a narrower problem, and one where a graph of known entities can steer the search instead of a vector index guessing. Call it GraphRAG if you want. I would rather call it looking things up by the thing you are looking for.

Hypothesis, then confirm

The payoff is in the interview. Today the DataParade interviewer asks you what it cannot learn from code: are customers and users the same thing, does this flow leave the boundary. The questions are correct and they are tedious, because the person answering is being asked to remember.

With session traces as a source, the interviewer can do something better. It finds a gap in the knowledge base, checks the transcripts for anything about that data item, forms a hypothesis, and asks you to confirm it:

On September 22 you told your coding agent that password reset tokens are hashed before they're stored. The code in auth/reset.ts still writes the raw token to reset_tokens.token. Is the hashing still planned, or did the decision change?

That is a better question than "how are reset tokens stored?" for three reasons:

1. It is specific.
2. It carries its evidence, from two sources that disagree.
3. The disagreement is the finding.

A knowledge base that holds what the code does, what the person said, and what the agent was told, and can show where they diverge, is the thing we are building toward. The scan gives us the first. The interview gives us the second. The transcripts are the third, and they are already on disk.

One more notch to the left

DataParade's pitch has been that security and privacy review should move left, to the pull request. Session traces move it one notch further, to the conversation where the code was decided. A PR gate can tell you that a new flow carries an email address to a third party. A transcript can tell you that the person who wrote it knew, said so, and said why. Or that they never mentioned it, which is its own kind of signal.

What we haven't tested

• Whether the claims are findable. We have a sentiment classifier running over sessions and nothing yet that extracts data-handling claims. The first experiment is to take one repository's sessions and hand-count how many claims about personal data they contain, so we know the ceiling before we build the extractor.
• Whether people will allow it. Session histories contain everything, including things that have nothing to do with the project. Any version of this that leaves the machine needs the same read-only, path-listed, delete-one-directory guarantees BotSpy makes locally, and probably stronger ones.
• Agents other than those five. The adapter protocol is small on purpose. We have not written a sixth.

Lessons

1. The design record moved and nobody noticed. It is in agent transcripts now. Read them before you ask a person to remember.
2. Ask to confirm, not to recall. A hypothesis with evidence attached gets a better answer than an open question, and a wrong hypothesis gets corrected faster than a blank gets filled.
3. Build the boring part read-only first. The adapters and the snapshot logic are what make the interesting part possible, and they are what make it safe to try.

BotSpy is on GitHub, with every path it touches documented. The claim extractor does not exist yet. When it does, it will be the next article.