{"slug": "keys-of-the-departed-ghost-account-hunter-uncovering-the-dead-identities-still", "title": "\"Keys of the Departed\": Ghost Account Hunter - Uncovering the Dead Identities Still Haunting Our Systems", "summary": "A developer built Keys of the Departed, an open-source \"ghost account hunter\" that investigates forgotten machine identities such as stale deployment keys and orphaned service accounts. Rather than simply flagging inactive credentials, the tool reconstructs an identity's history from engineering evidence, separates verified facts from assumptions, and surfaces conflicting information so auditors can decide whether revocation is safe. The project was submitted to the Hacktoberfest Open-Source AI Challenge Week 4.", "body_md": "*This is a submission for the [Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine](https://dev.to/challenges/hacktoberfest-week4-2026-10-26).*\n\nWhen I first started thinking about the *Ghost in the Machine* challenge, I pictured something we rarely think about when discussing cybersecurity: an account nobody remembers creating, a deployment key nobody remembers owning, or a service account that continues working long after the project it belonged to has disappeared.\n\nI started calling them **ghost accounts**.\n\nA developer creates a deployment key, connects it to a CI/CD pipeline, and moves on. The team changes, the project gets archived, but the key remains active. Nobody knows whether it is still needed, what depends on it, or who should be responsible for it.\n\nSimply revoking it isn't always the answer. It could break something important.\n\nThat's what inspired **Keys of the Departed — a Ghost Account Hunter for forgotten machine identities.**\n\nI wanted to build more than an inactive-credential scanner. I wanted an investigation platform that could reconstruct an identity's history using engineering evidence, identify possible ownership and purpose, expose conflicting information, and help auditors decide what deserves attention.\n\nThe idea behind the name and visual identity is an archive of forgotten digital identities — histories waiting to be uncovered.\n\nA look inside the archive.\n\nThe screenshots below walk through **Keys of the Departed**, from discovering forgotten machine identities to investigating their evidence and reviewing what should happen next.\n\n**Explore the code:** [Keys of the Departed — GitHub Repository](https://github.com/justsamridhi/keys-of-the-departed)\n\nWhen I began ideating for this challenge, I kept coming back to one situation: an engineer leaves a team, their personal account is removed, but the automated credentials they created are still running somewhere.\n\nA deployment key might still be connected to a pipeline. A service account might still have access to a repository. A scheduled bot might still be executing tasks nobody remembers assigning to it.\n\nI initially thought about building a scanner that could identify these forgotten identities. But the more I thought about it, the more I realised that simply finding an inactive credential wasn't enough.\n\nAn identity can be inactive and still be important. Another can be active but completely unmanaged. And revoking something without understanding what depends on it could cause an outage.\n\nThat changed the direction of the project.\n\nI wanted to build something that could investigate an identity's history, connect it to available engineering evidence, distinguish verified information from assumptions, and give an auditor enough context to make a decision.\n\nThat became **Keys of the Departed**.\n\nI wanted the interface to reflect the idea behind the project. Instead of presenting forgotten identities as rows of alerts, I imagined an archive where every identity had a history that could be examined.\n\nThis led to the four chambers, which became a central part of the MVP:\n\nThese are not simply four visual categories. They organise different identity situations and help an investigator understand why an identity needs attention.\n\nI also wanted the experience to have a more reflective side. That became the **Free Spirit** section. It asks the user five questions and generates an identity profile based on their answers. It is a small interactive experience within the application, separate from the security investigation itself, but it helps complete the archive's identity and storytelling concept.\n\nThe hardest part was not displaying an identity as suspicious. It was deciding what evidence would justify that conclusion.\n\nA language model could extract a name from a commit log, but that did not prove the person owned the credential. A matching quote could still be associated with the wrong person. And an inactivity rule could flag a credential that was still essential to an automated workflow.\n\nI had to separate three things that are easy to confuse:\n\nI also had to account for services that might not be available during a demonstration. Local model inference depends on Ollama being available, and the application needed a predictable fallback rather than hanging or failing when it was not.\n\nThese problems influenced the architecture much more than the choice of frontend framework did.\n\nThe application is organised as a TypeScript monorepo with four workspaces: `client`, `server`, `contracts` and `tests`.\n\n| Layer | Technology | Responsibility | \n|---|---|---|\n| Frontend | React 18, Vite 6, TypeScript, CSS | User interface and investigation experience | \n| Backend | Node.js, Express, TypeScript | API routes, application logic and access control | \n| Shared contracts | Zod | Data validation across application boundaries | \n| Database | MongoDB Atlas | Accounts, investigations and audit records | \n| AI and analysis | Gemma 3 4B, Ollama, TabPFN | Evidence extraction and behavioral evaluation | \n| Authentication | Auth0 | Authentication and protected actions | \n\nThe architecture follows a clear separation: the frontend handles the auditor experience, the Express API handles requests and access control, the investigation pipeline processes evidence, and the database stores the resulting records.\n\nI integrated **Google Gemma 3 4B through Ollama** as the forensic candidate extractor.\n\nThe model runs through a local Ollama service and examines unstructured engineering evidence, such as commit logs and CI/CD events. Its job is to identify potentially useful ownership and operational claims and return them in a structured format.\n\nBut Gemma does not get to decide whether a claim is true.\n\nIt proposes candidate claims, including source references and quoted evidence. Those claims are then passed to the deterministic verification layer.\n\nI also added a fallback for situations where Ollama is unavailable. The application can use precomputed synthetic claims so that the investigation workflow remains demonstrable without depending on a running local model.\n\nThis is one of the most important parts of the project.\n\nEvery candidate claim passes through a TypeScript evidence verifier before it can enter the accepted dossier.\n\nThe verifier applies five reason-code checks:\n\nClaims that fail verification are recorded in a rejected-claims ledger with their corresponding reason codes.\n\nI wanted this part to be inspectable. An auditor should be able to open a case and see which claims were accepted, which were rejected, and why. The dossier is therefore more than an AI-generated summary: it brings together the identity, supporting evidence, verified claims, rejected claims and review information in one place.\n\nFinding forgotten identities is only the first step. Investigators also need a way to decide which cases deserve attention first.\n\nFor this, I incorporated **TabPFN** into the behavioral anomaly-scoring work.\n\nThe evaluation uses tabular behavioral telemetry, including invocation frequency, off-hours execution ratio, IP entropy and rotation latency. Its anomaly scores are compared against simpler baselines such as Isolation Forest and inactivity heuristics.\n\nThis is intended to help prioritise investigations rather than automatically classify an identity as malicious.\n\nAn important implementation distinction: TabPFN is currently evaluated offline, with precomputed evaluation results presented in the interface. It is not represented as a live inference service in the application.\n\nI did not want an AI-generated finding to become an unrestricted security action.\n\n**Auth0** provides the authentication and access-control layer. Protected actions are gated so that guest users cannot simply initiate sensitive operations without the required authentication.\n\nThe project also models a **Client-Initiated Backchannel Authentication (CIBA)**-inspired approval experience for an auditor reviewing a proposed remediation.\n\nThe current CIBA experience is a simulated demo flow, not a live production push-approval integration. The important architectural boundary is that the AI can assist with investigation, but sensitive actions remain behind an authorization and human-review step.\n\nRemediation is sandbox-only. The application demonstrates decisions such as simulating the revocation of a deployment key or disabling a service account; it does not modify real production credentials.\n\nThe evidence and decisions need to survive beyond a single browser session.\n\nI used **MongoDB Atlas** with the official MongoDB Node.js driver to persist accounts, investigations, evidence-related records and audit information.\n\nThe backend separates database access and repository operations from the API routes. This keeps the investigation workflow from being tightly coupled to the user interface and allows the archive and case views to retrieve their data through dedicated services.\n\nThe frontend then presents these records through the four chambers and the detailed case dossier.\n\nI also wanted to keep track of how the project itself evolved.\n\nI used **Entire** for lifecycle checkpoints and development provenance, helping preserve important decisions and the reasoning behind changes.\n\n**DevRelay** was part of the development-session workflow, supporting session records and exports. These tools belong to the development process rather than the application's runtime investigation pipeline.\n\nFor me, this mattered because the project involved several architectural decisions that were not obvious at the beginning. Keeping a record of those decisions made it easier to understand why the system was structured the way it was.\n\nI configured **Render** to host Keys of the Departed as a single Node.js web service rather than maintaining separate frontend and backend deployments.\n\nThe deployment configuration in `render.yaml` brings the two application layers together:\n\n`client/dist`.` server/dist`.`/healthz` and `/api/health` endpoints expose application health, uptime, database connectivity and the current operating mode (`demo` or `configured`).\nI also had to account for an important difference between local development and cloud deployment. Gemma runs through Ollama on a local service, so a hosted instance cannot automatically access the model running on my development machine. MongoDB connectivity and other optional integrations also need to be configured independently through environment variables.\n\nTo handle this, I designed the application to distinguish between a fully configured environment and Demo Mode. When optional services are unavailable, the application can use synthetic fixtures and fallback responses for demonstration instead of treating every missing integration as a fatal error.\n\nThis deployment work taught me that getting an application to run locally is only one part of building it. Its dependencies, configuration, health reporting and failure behaviour also need to be considered before it can be reliably hosted.\n\n**Deployment:** Render · Single Node.js service · React/Vite static frontend · Express API\n\nAn identity is examined, candidate evidence is extracted, claims are independently checked, and the resulting dossier is stored for review. The auditor can then inspect the case, understand the findings and make a decision through the protected workflow.\n\nThe dashboard, archive chambers, investigation wizard, case dossier, safety guidance and Free Spirit identity experience all contribute to the same application, but they serve different purposes.\n\n**What if a security audit didn't feel like an audit at all?**\n\nThat was the idea I wanted to explore with Ghost Account Hunter.\n\nI didn't want to build yet another dashboard that throws inactive accounts, warning badges and risk scores at an auditor. I wanted to turn the forgotten corners of an organisation's digital infrastructure into an archive of mysteries waiting to be investigated.\n\nEvery abandoned deployment key has a history. Every orphaned service account has a story. And sometimes, the most dangerous identity isn't the one making noise — it's the one nobody remembers exists.\n\nThat's what **Keys of the Departed** is built around.\n\nOpen innovation gave me the freedom to bring this vision to life without treating AI as a magic black box.\n\nBut I didn't want the archive to be all investigations and security warnings. I wanted it to have a personality of its own.\n\nThat led to **Are You a Free Spirit?** — an interactive experience where users answer questions and discover their archetype through a personalised identity profile card. Alongside the four chambers, it gives the application a world of its own.\n\nI see this growing beyond a demonstration archive. I want to bring in richer identity timelines, more evidence sources, deeper ownership discovery and stronger behavioral analysis. The bigger ambition is to connect it to real organisational environments, helping security teams understand orphaned machine identities before deciding whether to retain, rotate or revoke them.\n\nI want to keep pushing the idea that security software can be technically rigorous without being lifeless, and that AI can make investigations more insightful without taking responsibility away from people.\n\n**We spend so much time creating digital identities and so little time remembering what happens to them. Keys of the Departed is my attempt to change that.**\n\nEvery year, Día de los Muertos brings the past into the present. Photographs are placed on altars, candles are lit, marigolds guide the way, and stories are told so that those who have departed are never truly forgotten. At the heart of this celebration is a beautiful thought: **someone may be gone, but their story deserves to live on.**\n\nWhile exploring the spirit of this theme, I found myself thinking about a different kind of departed.\n\nNot people, but the digital identities they leave behind.\n\nA developer moves on. A team dissolves. A project goes silent. Yet somewhere, a key still unlocks a system, a bot continues its routine, and an account retains access to places its creator may no longer remember. Its history is buried, but its existence hasn't ended.\n\nI began imagining these identities as ghosts, and the application as a place where they could finally be found.\n\nThat vision became **Keys of the Departed — Ghost Account Hunter**.\n\nI wanted to build an experience that felt like stepping into a forgotten archive at midnight. Something between an ancient library, a mysterious sanctuary and a digital graveyard. We carried that idea into the visual language of the application: deep burgundy, antique gold, candlelight, roses, old parchment and the quiet mystery of a world suspended between memory and oblivion.\n\nAt the heart of it sits an **open book**. It represents the archive, holding the histories of identities that would otherwise disappear into the noise of infrastructure. As words rise from its pages, fragments of forgotten stories seem to return: a name, a trace, a piece of evidence. The effect is a small visual moment, but it captures the entire idea behind the project — **bringing what was buried back into the light.**\n\nAnd then there is our **hunter**.\n\nWe didn't want a character who simply destroys every ghost he encounters. He is the keeper of this strange archive, its investigator and its guide. He enters the places nobody thinks to look, follows the evidence and uncovers what each identity left behind. His presence gives the application a personality, but also represents its central philosophy: understand before you act.\n\nThe **logo** brings the two central symbols together: a book for memory and evidence, and a key for access and responsibility. It is a reminder that the most important part of an identity isn't just the access it holds, but the story behind why it was given that access in the first place.\n\nWe extended this world through the archive's four chambers, each with its own atmosphere and meaning. They give the investigation a sense of discovery rather than presenting every unfamiliar identity as an immediate threat. Even the innocent have a place here. That distinction matters: the goal is not to hunt everything down, but to uncover what deserves attention.\n\nWe also wanted visitors to become part of the world, which led to **Are You a Free Spirit?** — a five-question experience that reveals one of four personal archetypes: The Seeker, The Scholar, The Sentinel or The Alchemist. It offers a lighter, more playful encounter with the archive, complete with individual profile identities.\n\nNone of these elements exists only to make the interface look spooky. The book, the hunter, the keys, the atmosphere and the interactions all serve the same narrative. We wanted the design to feel intentional, immersive and recognisable — a security investigation wrapped in a world that people would actually want to explore.\n\nAnd that is why this theme felt so right for the project.\n\nDía de los Muertos is about remembrance. **Keys of the Departed takes that idea into the digital world.** We remember the people behind our systems by investigating the identities they leave behind. We give forgotten access a history, and we make room for the possibility that not every ghost needs to be exorcised.\n\nI like to think of this project as a small tribute to everything that remains after its creator has moved on.\n\n**The candles are lit. The archive is open. The hunter is waiting. And somewhere between the pages, a forgotten key is still turning.**\n\n**Gemma 3 4B**, running locally through Ollama, powers the AI-assisted investigation layer. It extracts candidate claims about machine-identity ownership, history and purpose from engineering evidence.\n\nEvery claim passes through a deterministic R1–R5 verification pipeline that checks source existence, quote matching, personnel records, claim structure and minimum evidence length. Unsupported claims are rejected with traceable reason codes.\n\n**AI investigates. Evidence decides what can be trusted.**\n\n**TabPFN** explores behavioral anomaly detection using ten telemetry features, including invocation frequency, off-hours activity, IP entropy and rotation latency.\n\nIts offline evaluation is compared against Isolation Forest and inactivity-based heuristics to help identify which machine identities deserve closer investigation.\n\n**Auth0** provides authentication and protected-action boundaries. The application demonstrates a simulated CIBA-style consent flow, keeping sensitive decisions under human control.\n\nRemediation remains sandbox-only; no real production credentials are modified.\n\n**Entire** supports development provenance through lifecycle checkpoints, prompt records, decisions and trajectory logs. It helps preserve not just what was built, but the engineering journey and reasoning behind it.\n\n**Render** is configured to host the application as a single Node.js service, combining the React/Vite frontend with the Express API. The setup includes production build configuration and health endpoints for monitoring application status and database connectivity.\n\nBuilt with **Aditya Modani** ([@modapk06](https://dev.to/modapk06)).\n\nA project shaped by collaboration, experimentation and a shared effort to bring the idea of Keys of the Departed to life.", "url": "https://wpnews.pro/news/keys-of-the-departed-ghost-account-hunter-uncovering-the-dead-identities-still", "canonical_source": "https://dev.to/justsamridhi/keys-of-the-departed-ghost-account-hunter-uncovering-the-dead-identities-still-haunting-our-p4o", "published_at": "2026-10-31 20:46:04+00:00", "updated_at": "2026-10-31 20:52:06.815864+00:00", "lang": "en", "topics": ["ai-tools", "ai-agents", "developer-tools", "ai-safety"], "entities": ["Keys of the Departed", "Hacktoberfest Open-Source AI Challenge", "GitHub"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/keys-of-the-departed-ghost-account-hunter-uncovering-the-dead-identities-still", "markdown": "https://wpnews.pro/news/keys-of-the-departed-ghost-account-hunter-uncovering-the-dead-identities-still.md", "text": "https://wpnews.pro/news/keys-of-the-departed-ghost-account-hunter-uncovering-the-dead-identities-still.txt", "jsonld": "https://wpnews.pro/news/keys-of-the-departed-ghost-account-hunter-uncovering-the-dead-identities-still.jsonld"}}