Inspiration

Running a production application with a small team can be challenging. Many startups and smaller organisations host their applications and user data on a single low-cost server without having dedicated security or DevOps teams. When a deployment breaks something or a security vulnerability is discovered, it can go unnoticed for hours. And fixing things in a hurry can sometimes cause even bigger problems, including permanent data loss.

Security incidents also bring reporting responsibilities. CERT-In requires certain incidents to be reported within 6 hours, while DPDP Rules 2025 and GDPR have reporting requirements of up to 72 hours. For small teams, understanding these requirements and preparing the necessary documentation can be difficult.

Most monitoring tools can tell you when something goes wrong, but they leave the investigation and response entirely to the development team.

We wanted to build something that takes things a step further. Instead of simply detecting problems, what if an AI system could investigate an incident, identify the root cause, fix the vulnerable code, prove the fix through testing, protect affected data, and prepare the necessary reports?

That idea led us to build Alexia.

What it does

Alexia is an AI-powered security and incident response platform built around five specialised AI agents that work together to detect, investigate, and resolve production incidents.

Each agent has a dedicated responsibility:

  • Builder: Reviews vulnerable code, develops patches, and writes regression tests. Before opening a pull request, it runs the test in an isolated sandbox. The test must fail on the original buggy code and pass after the fix. Without this proof, no PR is created.
  • Deployer: Manages deployments through automated checks, monitors the release for three minutes, and rolls back automatically if something goes wrong.
  • Healer: Investigates application crashes and resource-related issues, identifies their root causes, and attempts recovery through restarts or fixes.
  • Sentinel: Detects suspicious activity such as leaked secrets, brute-force attempts, and SQL injection. It can block malicious IP addresses, preserve hashed evidence, and prepare security incident reports.
  • Integrity: Takes snapshots before data-related operations and investigates which records or tables an attacker could potentially have accessed.

The complete incident response workflow

Our main demonstration shows Alexia responding to a simulated SQL injection attack.

  1. An attacker launches a SQL injection against our demo application.
  2. Sentinel detects the suspicious activity within 30 seconds and blocks the attacker's IP.
  3. Integrity identifies potentially exposed tables and calculates the number of affected rows.
  4. Builder investigates the vulnerable code and creates a regression test alongside a parameterised-query fix.
  5. The isolated sandbox runs the test against both versions of the code, demonstrating that it fails before the fix and passes afterwards.
  6. Once the fix is verified, a pull request is prepared for human approval.
  7. The developer can approve the change remotely through the mobile app using a fingerprint or passkey.
  8. Deployer takes over and begins the controlled deployment process.
  9. Draft reports for CERT-In, DPDP, and GDPR are generated for human review.

Alexia also includes an installable Progressive Web App (PWA) that supports push notifications, remote approvals, and an emergency Pause All Autonomy button to stop automated operations whenever necessary.

How we built it

We built Alexia using five specialised AI agents, all powered by NVIDIA Nemotron models through Nebius Token Factory.

Instead of using the most powerful model for every task, we designed a model-routing system that selects the appropriate model based on the complexity of the operation.

  • Nemotron Nano handles quick tasks such as incident triage and summaries.
  • Nemotron Super handles deeper investigations, diagnosis, and code and test generation.
  • Nemotron Ultra handles complex planning, attack timelines, and patch reviews.

If a smaller model isn't sufficiently confident, the task is escalated to a more capable model. We also implemented a daily budget limit to keep the average incident cost at approximately $0.04.

For additional context during investigations, every diagnosis begins with a Tavily search for relevant error messages or CVEs. The retrieved sources are attached to the incident and its corresponding pull request, making the reasoning behind suggested fixes easier to verify.

Security-first architecture

One of our biggest priorities was ensuring that AI agents could never gain unrestricted control over production infrastructure.

Rather than relying only on prompts to control their behaviour, we implemented a predefined action system with three permission levels:

  • Automatic: Actions the agents can perform independently.
  • Requires approval: Actions that need explicit human permission.
  • Forbidden: Actions that agents are never allowed to perform.

The agents never receive direct shell access. Secrets and personal information are masked before being sent to AI models. Every action is also recorded in a SHA-256 hash-chained audit log, making unauthorised modifications detectable.

Technology stack

  • Backend: Python, FastAPI and SQLite.
  • Demo environment: ShopLite, running in Docker with PostgreSQL.
  • Frontend: React, TypeScript and Tailwind CSS.
  • Authentication and notifications: WebAuthn and Web Push.
  • AI infrastructure: NVIDIA Nemotron models through Nebius Token Factory.
  • Research: Tavily.
  • Integration: GitHub API.

The dashboard and mobile experience share a single React and TypeScript codebase.

We also developed an evaluation script covering nine different scenarios. Each scenario is executed three times, with every run checked against predefined acceptance criteria.

Challenges we ran into

Building an AI system that can take actions on infrastructure comes with serious security concerns. We didn't want to create another tool that blindly executes whatever an AI model suggests.

A significant part of our development went into designing safeguards. We implemented snapshots before data-related changes, single-use approval tokens with expiry times, and an emergency kill switch to pause autonomous operations.

Another challenge was getting consistent and valid JSON responses from the models. Since different agents depend on structured outputs, even a small formatting issue could break the workflow. We addressed this through schema validation, one retry, and escalation to a larger model when necessary.

One principle we were particularly strict about was:

No proof, no pull request.

It would have been much easier to let the AI generate a patch and open a PR based on its confidence. However, we wanted to make sure that every proposed fix actually worked. The regression test must fail against the original buggy code and pass against the patched version. If it cannot demonstrate this, the issue is handed over to a human.

Time was another major challenge. Building five AI agents, a dashboard, a mobile application, backend infrastructure, and an evaluation suite within a few days required constant prioritisation and a lot of difficult decisions about what to build first.

Accomplishments that we're proud of

Our biggest accomplishment is getting the complete incident response workflow working together, from detecting an attack to producing a tested fix and preparing a pull request.

We're particularly proud of:

  • Successfully integrating five specialised AI agents into a single incident response workflow.
  • Implementing the No Proof, No PR mechanism to ensure that proposed fixes are backed by actual regression tests.
  • Building an isolated testing environment to validate fixes before they reach production.
  • Implementing human approval through the mobile application using WebAuthn.
  • Creating a security-focused action permission system with an emergency kill switch.
  • Generating breach report drafts aligned with CERT-In, DPDP, and GDPR reporting requirements.
  • Maintaining a verifiable SHA-256 hash-chained audit log.
  • Successfully passing all nine evaluation scenarios across three consecutive runs.

What makes us most proud is that Alexia doesn't stop at identifying a problem. It attempts to take the entire process from detection and investigation to a verified fix while keeping critical decisions under human control.

What we learned

This project taught us that building reliable AI agents requires much more than choosing powerful models and writing good prompts.

Using different model sizes for different tasks helped us control costs while maintaining the quality of results. We also realised that schema validation, structured outputs, and controlled retries contribute far more to reliability than simply making prompts longer or more detailed.

One of our biggest takeaways was that AI autonomy needs boundaries. Critical safety decisions should be enforced through application logic and system-level restrictions rather than relying on the model to follow instructions.

We also learned how challenging it can be to coordinate multiple agents that depend on one another, especially when every action needs to be traceable, testable, and safe.

What's next for Alexia?

We see Alexia as a starting point for making production security and incident response more accessible to smaller development teams.

Some of the improvements we want to work on next include:

  • Kubernetes support: Extending Alexia beyond Docker-based environments to manage larger deployments.
  • Advanced threat detection: Adding more attack detectors and improving existing security monitoring.
  • Dependency vulnerability scanning: Detecting vulnerable dependencies and automatically preparing upgrade pull requests.
  • SOC 2 evidence export: Helping teams organise and export security audit evidence.
  • Nebius Serverless Jobs: Moving isolated sandbox tests to Nebius Serverless Jobs.
  • Native Android application: Building a dedicated mobile application for alerts, approvals, and incident management.

Our long-term goal is to make reliable, AI-assisted security and incident response accessible to teams that cannot afford dedicated security and DevOps infrastructure.

Built With

Share this project:

Updates

Submission history