Project Story
The idea behind CyberVoice AI
Cybersecurity incidents rarely happen when people are prepared for them.
A suspicious SMS arrives. Someone clicks a link. An unexpected login notification appears. A caller asks for information. In these moments, people often know that something feels wrong, but they may not know what details matter, what they should do next, or how to report what happened.
We wanted to explore a simple question:
What if reporting a cybersecurity incident felt more like having a calm conversation than filling out a complicated form?
That question became the foundation of CyberVoice AI.
Instead of asking users to understand cybersecurity terminology or navigate a long questionnaire, we designed a voice-first experience where they can simply explain what happened in their own words.
From conversation to incident report
Our approach was to make voice the starting point, not just an additional input method.
A user can describe an incident naturally, and the application can continue the conversation by asking relevant questions. For example, if someone says they clicked a suspicious banking link, the system can clarify whether credentials, OTPs, or financial information were entered.
The conversation then becomes structured information:
User's story → Clarifying questions → Relevant facts → Safety guidance → Incident preview → Human confirmation → Saved report
The important part is the final step.
We did not want an AI system to silently create or permanently store an incident based on its own interpretation. The user gets a structured preview first and remains the final decision-maker before the report is saved.
Building with AssemblyAI
For the hackathon, we wanted to make the voice interaction a genuine part of the application rather than simply adding speech-to-text to a traditional web form.
We used the AssemblyAI Voice Agent API as the core voice interaction layer.
The browser handles the microphone and user interface, while our Node.js backend manages the controlled connection and temporary voice-session token. The permanent AssemblyAI API key stays on the server.
The voice layer is integrated with the rest of the application so that the conversation is connected to an actual incident-reporting workflow rather than existing as an isolated chatbot.
Our stack includes:
- AssemblyAI Voice Agent API — real-time voice interaction
- React + Vite + TypeScript — frontend application
- Node.js + Express + TypeScript — backend
- SQLite — incident persistence
- Zod — request validation
- Tailwind CSS — interface styling
- Vitest + Supertest — testing
How we built it
We started by designing the user journey before implementing the individual features.
The core flow became:
1. Start a voice session
The user opens CyberVoice and starts a voice interaction.
2. Describe the incident
The user explains what happened naturally instead of filling out a predefined form.
3. Clarify the situation
The agent asks follow-up questions based on the information already provided.
4. Provide cautious guidance
The system presents practical safety recommendations without claiming that it has definitively detected malware, phishing, fraud, or compromise.
5. Generate an incident preview
The application organizes the conversation into structured information such as incident type, user actions, possible exposure, urgency, timeline, and recommended next steps.
6. Confirm and save
The user reviews the result and explicitly confirms it before the application persists the report.
7. Review later
Saved incidents can be viewed, filtered, updated, and reviewed through the dashboard.
This workflow helped us keep the project focused: voice should reduce friction, while the application should provide structure and control.
The biggest challenges
Making voice useful instead of just impressive
One of our first challenges was avoiding the temptation to build a generic voice chatbot.
A voice demo can look impressive, but it does not necessarily solve a real problem.
We therefore connected the conversation to a concrete workflow: collecting incident context, generating a structured preview, and requiring confirmation before persistence.
That shifted the project from "talk to an AI" to "use voice to complete a cybersecurity task."
Designing adaptive questions
Cybersecurity incidents do not follow one fixed questionnaire.
Someone who received a suspicious SMS may need completely different questions from someone who noticed an unauthorized login.
We had to think about which information actually changes the recommended next step and how to gather it conversationally without overwhelming the user.
Safety and overclaiming
Cybersecurity is a domain where incorrect advice can create additional risk.
We deliberately avoided presenting CyberVoice as a forensic investigator or a guaranteed malicious-link detector.
The system is designed to distinguish between what the user actually reported and what may simply be a risk indicator or recommendation.
We also designed the experience so users are never asked to provide highly sensitive information such as passwords, OTPs, API keys, or complete payment-card details.
Keeping the API key secure
Another important challenge was integrating a real-time voice API without exposing the permanent AssemblyAI credential in the browser.
We solved this by keeping the permanent key on the backend and providing the frontend with a controlled, short-lived session token.
This was an important lesson for us: a working integration is not enough; the way the integration handles credentials matters too.
Connecting AI output to reliable application state
Another challenge was making sure the conversational experience connected cleanly to a structured database workflow.
The AI can help understand the conversation, but the application still needs predictable data, validation, timestamps, statuses, and database operations.
This led us to separate the conversational experience from the application's persistence layer and validate data before it reaches the database.
What we learned
Building CyberVoice AI taught us that a successful AI application is not necessarily about giving the model more freedom.
Sometimes the better design is to give the AI a well-defined role inside a controlled workflow.
We learned several things during the process:
- Voice interaction is most useful when it removes a real source of friction.
- AI-generated information should be reviewable before it becomes permanent application data.
- Security-sensitive applications need clear boundaries around what the AI can and cannot claim.
- API credentials should never be treated as frontend configuration.
- Good UX can be a security feature: a calm, guided experience can help users avoid making impulsive decisions during a suspicious event.
- A prototype becomes much more meaningful when the AI component is connected to a complete, testable workflow.
What we would build next
CyberVoice AI is currently a prototype focused on the voice-first reporting experience.
If we continued developing it, we would explore integrations with organizational security workflows, richer evidence attachment, configurable incident playbooks, stronger authentication and authorization, persistent production-grade storage, audit logging, and integrations with existing security or incident-management systems.
We would also evaluate the system extensively with real users to understand whether conversational reporting actually improves the completeness and quality of incident reports.
Why this project matters
Cybersecurity tools are often designed for people who already understand cybersecurity.
CyberVoice AI approaches the problem from the other direction:
Start with the person.
Let them explain what happened naturally. Help them understand what information matters. Give them cautious next steps. Turn the conversation into something structured. And let the human remain in control.
That is the idea behind CyberVoice AI:
A calmer, clearer first step when something feels wrong online.
Built With
- api
- assemblyai
- css
- express.js
- node.js
- react
- rest
- sqlite
- tailwind
- typescript
- vite
- vitest
- websocket
- zod
Log in or sign up for Devpost to join the conversation.