When I applied for my first API key, the platform masked most of the credential string with asterisks, only revealing a two-letter prefix followed by a hyphen. At first, I tried copying it, thinking the asterisks would also be copied. I even considered manually typing out the full key. After reading relevant materials, I understood those asterisks were merely frontend masking. When you copy the whole string, your clipboard receives the complete real key; the asterisks are just for display.

After obtaining the key, I was unsure where to store it securely. Plenty of online materials stressed that API keys are highly sensitive credentials exclusive to each individual. I treasured it and worried constantly about losing it. I saved the key in a local notepad file, alongside the website and account credentials related to it. I closed and reopened the file to verify everything, and only breathed a sigh of relief after confirming the content was complete and intact.

I connected the key to Pi Agent and sent a simple "hello" as a test, only to get a 402 error. I found out many overseas LLM platforms require prepaid balance to work properly. This raised a major concern: if someone stole this funded API key, would they be able to drain the balance of my account?

I began following the AI Genesis Hackathon in early October. Inspired by this personal experience with API keys, I decided to build a tool for key protection. I was deeply interested in key masking technology at first, planning to develop a masking tool accessible to ordinary developers. I did my research and formed a rough concept. At that time, the hackathon had not started, so I could only estimate its timeline. I originally planned to prepare for this event and even considered building a K12-related project at first.

I started with research, trying to decide which intelligent agents to invoke and how to divide tasks between them, while reading performance benchmarks for various agents. It took roughly a day and a half to finalize this part. Afterwards, I checked the official website for submission requirements and track categories, and settled on the general scope of my project. I recorded all my preparation notes in AFFiNE and reviewed my progress every day.

My initial idea was to mask keys at the moment of code upload. That way, even if judges or other users viewed the code, they could not get the raw key through copying or other methods. It reminded me of encrypted communications between agents and supervisors in spy movies: masked keys required an extra decryption step to restore the real credential. After evaluation, I realized I could not implement this solution stably with my current skill set, so I abandoned this approach.

I kept studying open-source projects and commercial security tools on the market. From my research, I found most solutions lack protection that intercepts secret leaks at the source, right before developers push their code.

That’s when I started building KeyShield. I investigated existing tools including GitGuardian, GitLeaks and TruffleHog and identified their weakness: they do not intercept key leaks at the source from a developer’s perspective. I chose to build my project to fill this gap.

I browsed numerous GitHub repositories related to secret security. Apart from a small number of pre-commit interception tools, most projects perform global scans to hunt for secrets. GitGuardian’s report stated that in 2025 alone, 28.65 million hardcoded secrets were accidentally uploaded to public GitHub repositories, marking a 34% year-over-year increase. Countless developers accidentally commit API keys and credentials when pushing code. Seeing this data, I recognized the high research value of this topic. It also aligned perfectly with my interests, and I believed I could build this pre-commit safeguard.

Then the formal development of the project began. I collaborated with Hyper to discuss requirements, sketch the overall project architecture, and select the tech stack including components such as the FastAPI service. We downloaded and installed dependencies together and discussed every step. I designed the overall architecture, while the agent helped supplement details and expand my thinking. We built the minimum viable prototype of KeyShield in about a day and a half.

Once the first prototype was ready, I carefully reviewed all the code, the workflow designed by Hyper, datasets, and its reasoning process for building the project. This was just the beginning; the framework was newly built, and I encountered many unfamiliar complex files and code snippets. I moved on to implementation: manually creating project folders, polishing generated code and pasting it into corresponding files, continuously adjusting formatting and details. This produced the project’s first official file. I recorded future plans and the full workflow as technical notes in my notebook. Some coding logic was hard for me to fully understand with my current knowledge, so I looked up documentation and learned the underlying principles bit by bit.

Later, I collaborated with Devin, acting as an assistant engineer. We communicated in depth and discussed most code revisions together. We enriched the framework, revised code, and planned file invocation logic and directory structures. I shared all the hackathon submission requirements recorded in AFFiNE with Devin. We brainstormed to build the outline, long description and plan for the README. I drafted roughly 80% of the manuscript and handed it over to Devin, asking it to refine details, polish awkward phrasing, avoid excessive jargon, and most importantly, highlight the project’s differentiators. I integrated insights from my research into my draft, and told Devin it could supplement relevant information beyond my original text. Devin retrieved cutting-edge authoritative resources that would otherwise be hard for me to access. Then we discussed where to place these new materials in the README.

After finishing the first draft of the README, the project direction, framework, required files and core features were mostly confirmed. Next, I studied code snippets from previous open-source projects, learned their core logic, and adapted the code into modules for my project. I manually created new files and added the adapted modules to the codebase. Then I asked Devin to perform code review. I raised questions: are all these new modules worth keeping? Which parts can be removed? Even though I learned and modified existing code on the fly, can these revisions meet the basic expectations of the project?

Devin completed the code review, offered many revision suggestions, and affirmed my development ideas and code quality. But it also reminded me: even though I adapted classic code modules from other works, my project did not need every complex feature. Trying to pack dozens of feature layers into the limited hackathon timeline would only result in a bloated, rough final submission.

I followed Devin’s advice, revisited the README, filtered the essential features the project had to implement, and clarified the specific direction for secret interception. I designed a three-layer system for this protection. First, real-time file monitoring. Second, a Git pre-commit hook that also runs detection. If secrets or credentials are found in staged files, it blocks the commit immediately. These two form the core backend capabilities.

However, these two layers alone were not enough. There is a scenario where empty key placeholders exist in code. They won’t trigger leak detection, but the program will fail to run due to missing configuration, and users won’t know where to fill in their keys. To solve this pain point, I designed the third layer: a supporting frontend UI. Users can enter their API keys in the interface, and my self-designed algorithm produces masked keys. I set a strict requirement for this system: stateless and highly confidential. It must never store keys entered by developers on the server side, so the tool itself does not become a source of secret leakage. This was the biggest risk I needed to avoid.

Then we began developing these three layers. Before this project, I had independently built and released two projects: a vocabulary learning tool and a Sudoku game, both pure frontend works. From these two projects, I accumulated experience and found my strength: frontend UI design and implementation. For backend capabilities like dynamic file monitoring and Git hooks, I only had basic familiarity. I referenced code from great open-source projects, studied, copied and debugged snippets to learn step by step. Objectively speaking, my backend foundation was still weak, so Devin guided me heavily while developing these modules. It output code with detailed comments so I could understand the underlying logic.

During debugging, I ran many commands in the terminal and hit numerous errors. Often the terminal could not recognize commands or locate functions. Installing dependencies from overseas sources was extremely slow, sometimes taking hours or failing entirely. When these issues appeared, I asked for solutions and switched to domestic mirrors to complete installation. Network obstacles appeared constantly throughout development, and I relied on legitimate methods to troubleshoot on my own. Troubleshooting consumed most of my development time, but I eventually fixed most network and environment issues.

I also discovered cross-platform compatibility issues in many modules. Some code was written for Linux, some for Bash on macOS, and they were not compatible with Windows PowerShell syntax. Before running commands in the terminal, I had to check the source code to confirm the original developer’s environment. Since I work on Windows, many scripts and commands needed manual rewriting to work with PowerShell.

While debugging, I gradually understood the purpose and activation logic of virtual environments. The three major modules — real-time file monitoring, frontend UI, and scan detection called via curl API endpoints — all required a virtual environment to run. When I first set up the Git hook, even with the virtual environment activated, I made operational mistakes and kept getting path-not-found errors. I suspected environment conflicts. After checking the code, I found an error in an import statement from ... import scan. I troubleshooted the pre-commit hook Python script alongside GitHub Desktop, identified the fault in the scan function, and found the root cause and fixes.

After countless errors and repeated debugging, the whole system finally worked. KeyShield includes four core features:

1. Real-time file monitoring, which runs inside a virtual environment.

2. Git commit hook, the project’s core protection. It does not require a virtual environment. It automatically scans when developers attempt a Git commit and blocks the operation if secrets are detected.

3. Frontend UI, an auxiliary feature. Users can input API keys and get masked keys generated automatically.

4. API endpoint supporting global scan detection, callable via curl. I have not systematically learned the startup method and syntax for this interface yet; I may study this more in the next year or so. I can run it following documentation, but my understanding of its low-level principles remains shallow. The feature works, and I will deepen my knowledge later.

I carefully read the hackathon requirements and submission checklist recorded in AFFiNE and started preparing the project submission materials. The rules were clearly written, but they required massive research work behind the scenes. I used Perplexity to retrieve extra reference materials for two more days. After sorting through everything, I became more certain that my project has a unique niche in secret security.

Within the hackathon submission framework, I added my analysis of product logic, practical value and future prospects. My knowledge of commercial product systems is limited, so my analysis is purely from a technical perspective. I added comparisons against competing projects, basic market evaluation, summarized common risks of secret leakage, privacy hazards and financial risks developers face, and mapped out future iteration plans. This project could become a formal product someday, but I made tradeoffs for this hackathon. This was my first hackathon, so I followed the mindset “start small, build small”. For this submission, I only delivered a working demo instead of a commercial product. My priority was stable logic and clear positioning, matching the reality of a first-time participant.

At this point, the core project was nearly complete. Most technical blog posts would end here, but the most critical remaining work for this hackathon was preparing presentation slides and demo screen recording. I had read post-mortems from previous hackathon participants, especially Xdite’s sharing from Facebook Hackathon, which highlighted the importance of demo videos and slides. I worked with Devstral to polish my presentation materials.

I designed the presentation outline based on the README and hackathon submission requirements. It covered preliminary research, industry pain points, project design ideas, then introduced KeyShield, paired with screenshots so judges could quickly understand the value. This was a brand-new workflow for me: Devstral (a model from Mistral) generated Markdown content from my outline and materials, then I exported it directly to PDF inside VS Code.

For screen recording, I planned to capture a complete demo showing every feature step by step. Recording was new territory for me. I rarely recorded my screen before, so I looked up Windows recording solutions. The built-in Snipping Tool supports screen recording, and there is also the Xbox Game Bar. But Xbox Game Bar often had black screen or missing audio issues for me, so I chose Windows Snipping Tool for this recording.

I felt nervous before recording, afraid of operational mistakes breaking the demo flow. To ensure a smooth recording, I practiced the full demo repeatedly for two or three days. Through repeated practice of setting up virtual environments and running terminal commands, I memorized the whole workflow and built a basic understanding of terminal syntax.

One afternoon, while heading to the cafeteria during my practice phase, I checked hackathon updates. I went through the full October event schedule on the official website but could not find any information about AI Genesis Hackathon. I felt discouraged at that moment.

I searched for ongoing hackathons and compared options. I originally planned to join AMD Developer Hackathon, also known as ACT III Hackathon. But I found the competition had already started for a day or two. This sudden change stressed me out, yet I knew panic would not help. I calmed down and focused on finishing the screen recording.

Once the recording was done, I faced a new problem: the footage contained private files and unrelated content on my desktop that needed redaction. My first thought was to blur sensitive parts with video editing software. I rarely edit videos and had no editor installed, so I downloaded CapCut.

Honestly, video editing was completely unfamiliar. Luckily, I could ask for guidance and learn masking and blurring operations step by step to finish post-processing from scratch. The experience was surreal: one day I was deep in code debugging, the next I was learning video editing.

The editing process was bumpy. Many advanced redaction features required a Pro subscription, so I could only use simple watermark overlays to hide private content.

I was not satisfied with the final video. Some details and redaction were rough. I plan to delete this demo video after the hackathon. Once I iterate and improve the project later, I will re-record a polished full demo.

The original recorded video only demonstrates real-time file monitoring and the terminal UI. Part of the Git hook logic is integrated into the real-time monitoring module, but the standalone Task2 hook only triggers under specific terminal Git commit scenarios. Also, the hook still had minor unresolved bugs at recording time, and the deadline was imminent. After weighing everything, I did not include the standalone hook demo in the video.

The hackathon required the demo video to combine slide introduction and live demo. Using ideas from Devstral, I worked to connect these two segments smoothly. To create the slide section of the video, I needed to extract each slide from the exported PDF. Manual screenshotting would be tedious and inconsistent in size. I followed Devstral’s suggestion: install FFmpeg for batch processing.

But new challenges appeared. Compiling from source created large files and slow downloads, which could take two to three hours. It was past 10 p.m. when I planned to download it, and I was too tired to wait, so I postponed the task. The next day I switched to secure mirrors maintained by domestic universities, which greatly improved download speed.

Downloading was only the first step. I needed terminal commands to split the PDF slides into individual images. At that time, I thought the whole project was almost finished, so I casually typed cut my PPT into pieces in the terminal. Looking back it makes me laugh; the terminal threw a wall of red errors because it cannot understand natural language. I looked up command syntax and wrote the proper instruction to split the PDF into neatly sized images.

Next, I needed to turn these slide images into a video, add subtitles to the demo footage, and merge the two videos together, keeping the total runtime under five minutes. I had a choice: use AI voiceover with subtitles or write a script and record my own voice.

After consideration, I decided not to use my own voice for privacy reasons. Modern voice technology can identify people from audio and clone voices, which carries risks. I wrote the full presentation script and roughly split timestamps for each segment. I sent the script to Kimi, which is strong at analyzing presentation rhythm. It pointed out my coarse timestamps and helped refine the timeline.

Using the revised script and timeline, I generated a test version of the slide video. The draft was playable, but choppy. There was noticeable delay before switching slides. With Devstral’s help, I adjusted the playback rate and transitions to produce a smoother final version. I identified the issue as frame rate and timing between visuals and text.

I am not a video production professional, so I logged all these issues in my technical journal. These skills will be useful for making presentation slides and demo videos in the future. But my priority was to complete all hackathon deliverables first; fine-tuning can wait after the competition.

It was past 9 p.m. on October 15. Exhausted from days of intensive preparation, I tried to publish my repository and submit the project. A fatal error blocked my push, warning of sensitive content. I had no idea my self-deployed KeyShield hook had already activated.

I had no choice but to complete the commit via terminal. I sorted files manually, wrote Git commands, checked push status repeatedly, and only relaxed once I confirmed the repository was public on GitHub.

Submitting the project was not the end. After pushing code, I filled out the hackathon form. The requirement to bind a Discord account tortured me for a while, and I even considered dropping out and only keeping my open-source repository. After careful consideration, I persisted, solved the access issue through legitimate means, linked my Discord account, and fully submitted my project.

Even after all materials were submitted, I kept working. On October 16, I sorted out three major flaws of the project: unresolved bugs in the Git hook, messy repository files, and no clear plan for updating the demo video. I spent hours brainstorming an iteration roadmap: fix the core hook and underlying logic first, then update the repository once stable.

While pushing revised hook updates, a funny yet meaningful incident happened. I used GitHub Desktop for the commit as usual, and the fatal error blocked me again. The terminal printed the suspected secret pattern and content. At that moment, I truly realized my pre-commit hook was fully functional.

The feeling was a mix of excitement and helplessness: the security tool I built successfully blocked my own commit. Fortunately, all secrets and credentials in the demo are fake samples I prepared in advance. The README repeatedly reminds readers to replace demo secrets with real private credentials in production. In hindsight, this was the best real-world validation of KeyShield’s power. It proved the protection logic is robust and works exactly as designed.

Surprisingly, checking “bypass hook” in GitHub Desktop still failed to skip the check. The GUI bypass option could not get around my protection, meaning the hook has high priority and strong enforcement. I chose not to weaken the protection strength for now; feature trimming and logic optimization will be saved for future versions. In the end, I successfully pushed the new version through the terminal. I also learned an important note for future users: if demo secret samples remain in the repository, it is recommended to commit via terminal or clean the sample secrets beforehand.

After fixing the core hook, I cleaned up the whole repository. I sorted files, removed unused scripts, temporary assets and invalid configurations. This cleanup took more than an hour to remove clutter and keep the repository tidy. I paused when fatigue hit and left remaining polishing work for the final day before the deadline.

On October 17, the final countdown day, I wrapped up the remaining work. I finished the README, revised the repository bio, set the open-source license, and polished all public-facing details. I firmly believe documentation quality and repository presentation reflect a developer’s professionalism, so I treated this step seriously.

Many people might think the hackathon journey ends once the project is submitted. It was not the case for me. On the afternoon and evening of October 17, I completed the most valuable part of this experience: exploring projects built by global participants.

Participants came from all over the world, mostly India, Pakistan, Italy and Western Europe. Browsing their submissions shocked me. Most overseas projects were polished, commercially viable finished products with complete logic, full features and refined demos. Many were built by teams of two to four people. Their project scale, completeness and production capability far exceeded what I could build at my current level. For the first time, I saw firsthand the engineering capacity of top overseas developers.

After reviewing these projects, I did not feel inferior. I did not think my project was worse, nor did I want to restart my submission. I gained a clear, confident understanding of my own work. While my project is not as universally applicable as consumer-facing tools, not as polished as commercial products, and built without a team, KeyShield fills a rarely addressed but critical gap in secret security. Competing tools mostly scan for leaks after the fact, while my tool intercepts threats at the source before code is committed. This niche is unique, technically solid and valuable.

As a solo first-time participant, I built, debugged and delivered a full Git hook protection system within the short hackathon timeline. This was my personal limit. Meanwhile, many popular submissions suffered from obvious homogenization. I saw nearly five identical projects focused on helping patients understand medical prescriptions and discharge documents. These projects were warm, practical and well-built, but the track was overcrowded with little room for original innovation. They were clearly a local technical trend.

I also saw many outstanding projects built by highly skilled developers. One small-team AI subtitle and voice tool left a deep impression on me. It supports multilingual subtitles and AI voice generation. The voice quality was far more natural than the narration I used for my presentation video. From product design and engineering implementation to demo presentation, it was professional, complete and refined.

I truly admire these overseas developers’ engineering skills, product thinking and presentation skills. Many participants are industry professionals, and joining hackathons is just a hobby to challenge themselves. Their technical background, vision and teamwork ability are beyond my current reach, and they are what I aim to learn from in the long run.

The hackathon is drawing to a close, and this technical blog reaches its end.

This was my very first global hackathon. I started from zero, worked alone, encountered countless bugs, fixed mistakes and iterated continuously. I had no prior experience, no teammates and no senior mentors. I finished this journey purely out of curiosity, persistence and passion.

Yet I firmly believe: the growth, knowledge, debugging skills, product thinking and global perspective I gained from this competition are far more valuable than any award or thousands of dollars in prize money.

Awards are temporary. The technical lessons, troubleshooting experience, independent problem-solving ability and self-growth I earned are lifelong assets for my programming career.

Click https://github.com/memostudycode/KeyShield to see my project.

In the face of constant trial and error and persistent network latency issues, I finally completed registration and created my own team. The hackathon accepts both individual and team participants, with a distinctive rule: every participant must create a team first. If you choose to compete solo, creating a team finishes this step. If you plan to join as a team, one member creates the team and sends invitations to partners around the world to collaborate together. The core mission of my team is to build security tools that protect developers in day-to-day coding workflows.

While browsing the Introduce section of the hackathon, I met a fellow participant from India. We shared similar research interests and were at comparable stages in our academic journeys, so we started discussing technical ideas and our projects. This was my first conversation with an international competitor for whom English was a second language. I felt nervous at the beginning and used translation tools to convey my thoughts as clearly as I could. Our discussion stayed simple and focused mostly on our hackathon projects. I also asked about his development progress, and we had a friendly exchange.

After I published KeyShield, my project attracted attention from many seasoned professionals in this field. Some of them had decades of experience, and others were highly knowledgeable experts, including PhD students from Ivy League universities. There were also developers working in niche areas who produced exceptionally high-quality work. An entrepreneur and chief engineer even followed my repository. I was really excited, and this experience filled me with optimism for my technical journey ahead.