HoneyKey

HoneyKey is a canary trap-based security app that plants realistic honeypot API endpoints to detect intrusion attempts, capture attacker behaviour, classify threats, and auto-generate SOC reports.

Comment 1

Inspiration

HoneyKey was inspired by the recent lack of security systems in the age of AI-based design. Most teams only notice gaps in their security after real damage has been done, which leads to unexpected bills and compromised data. From reading Reddit posts detailing vibecoding gone wrong and thousands of dollars wasted in AWS bills, our team decided to bridge the gap by addressing attackers before they reach the real data. That is where HoneyKey comes in: a canary trap that employs live honeypot API keys in GitHub repositories to safeguard real secrets.

What it does

HoneyKey focuses on what happens after an API endpoint has been touched, beginning with an executive summary for non-technical stakeholders to understand the severity of leaked data and intrusion attempts. The generated SOC report details indicators of compromise, including bursty request rates, resource enumeration etc. This info contains confidence and severity levels to help contextualize attackers. Attack techniques are summarized based on the MITRE ATT&CK database, and HoneyKey prompts the user with specific recommended actions, including blocking attacker IPs, removing compromised honeypot APIs, and pushing for forensic investigation based on which endpoint was touched.

How we built it

We built HoneyKey by first designing a backend that could safely accept attacker traffic while behaving like a real production API. We started with FastAPI to define realistic endpoints and a transparent proxy layer, then used Uvicorn to serve the application and handle concurrent requests during simulated attacks. As requests flowed through the system, we structured all telemetry and incident data with Pydantic models to ensure consistency and make downstream analysis reliable. We stored this data using SQLite via sqlite‑utils, which allowed us to quickly persist events, query incidents, and export SOC‑ready JSON, and we integrated Gemini 2.5 to generate readable SOC and executive reports directly from the structured incident data.

  • FastAPI (Python 3.8+) for building the honeypot and proxy APIs

  • Uvicorn to serve and handle high‑volume API traffic

  • Gemini 2.5 to generate human‑readable SOC and executive reports

  • Pydantic for strict data modeling and JSON serialization of telemetry and incidents

  • sqlite-utils / SQLite to store telemetry, incidents, and export SOC‑friendly JSON

  • HTTPX for forwarding requests and simulating realistic upstream APIs

For the front-end, we first brainstormed a rough layout of the website which included the amount of pages we wanted, what each page would include, and their overall colour palette and style. We did this through drawing physical mockups on paper which were then transferred onto Figma. With the help of Figma Make, we prototyped a functional website with some placeholder data. After fleshing this out, we moved the Figma code onto VSCode to deploy locally and make further changes. Finally, after the website was fully integrated with the back-end, we deployed the website using a .tech domain on Vercel.

Challenges we ran into

One of the largest challenges we ran into on the front-end side of our program was converting our Figma design to VSCode. Instead of writing in languages like JSX and CSS that we were more familiar with, Figma wrote its code in TSX and Tailwind CSS, which had slight variations that we were not accustomed to. In the end, we were able to find a way to merge the components onto VSCode, and successfully deployed our website.

Our backend served two opposing roles: exposing realistic, fake endpoints to attackers while also delivering real-time, trusted intelligence to the dashboard. We did this by strictly separating security contexts with FastAPI middleware to prevent leakage of real admin data. To handle slow AI response times, we disconnected attack capture and analysis so our frontend showed “in progress” instead of blocking or failing.

Accomplishments that we're proud of

Each of us worked extensively with unfamiliar languages and frameworks throughout this hackathon, struggling but ultimately learning a lot. As first-time hackers, we are very proud of ourselves for being able to create a functional and viable product.

What we learned

We learned that relying solely on external AI APIs (like Gemini) can be risky for critical security tools. We had to engineer a robust "hybrid" system that uses AI for deep analysis but falls back to deterministic, rule-based reporting during outages or rate-limits to ensure users always get an alert.

We also found that a honeypot only works if it feels real. We spent time crafting realistic "fake" JSON responses (mock project lists, fake secrets) to keep attackers engaged long enough to gather actionable telemetry.

Connecting a React frontend design to a Python/FastAPI backend required careful API design. We learned how to map complex security data (MITRE ATT&CK techniques, IP telemetry) into user-friendly dashboards.

To create a functional website, we learned crucial skills in Typescript and React, two languages that we previously have not been exposed to. Importantly, we learned how the two combine with frameworks such as Framer Motion to streamline web design and allow us to broaden interactivity with our users.

What's next for HoneyKey

  • Real time alerting: HoneyKey currently generates reports on the dashboard. In the future, we can integrate Slack webhooks to notify security teams the moment a trap is triggered.

  • Cloud-native traps: We plan to expand beyond API keys to generate fake WS IAM credentials and Database Connection strings. If an attacker tries to use them, we could use CloudTrail logs to detect it.

Built With

Share this project:

Updates