SentinelAI

Inspiration

Security alerts often arrive as a short, technical warning, leaving people to figure out what happened, which systems are affected, and who needs to act. We built SentinelAI to connect those pieces and help data-center teams move from a suspicious log entry to a clear, reviewable incident summary—while keeping a human in control.

What it does

SentinelAI analyzes security logs for suspicious activity, investigates the timeline and related permissions, identifies affected assets and their owners, and prepares a tailored alert for each owner. A reviewer can examine the evidence, approve or reject the alerts, and see the decision in an audit trail. SentinelAI recommends actions but never changes infrastructure automatically.

Our demo uses fictional data. It includes an unusual admin login, access under an expired permission, and denied attempts against a critical database. It also includes benign lookalike activity to show that unusual events aren’t automatically treated as attacks.

How we built it

We built a React dashboard backed by a FastAPI service and SQLite data store. Detection and investigation use structured outputs and evidence IDs; owner matching produces separate notification drafts for affected assets. The dashboard includes viewer and reviewer roles, approval controls, and an audit history. Notifications can use a mock adapter for safe demos or a configured Photon adapter.

The design defines five agents: detection, investigation, intelligence retrieval, orchestration, and employee notifications.

Challenges we ran into

A security finding needs to be traceable to evidence, and an alert should only reach people responsible for the affected systems. We had to keep detection, investigation, and recipient matching grounded in structured data while limiting each draft to the relevant asset. We also had to make review and approval part of the workflow rather than treating sending as automatic.

Connecting to a live messaging channel brought a separate challenge: Photon and carriers have channel-specific setup and eligibility requirements. That’s why the project includes mock mode for demos.

Accomplishments that we're proud of

We built a working path from suspicious activity through investigation to owner-specific drafts and human review. The system links findings to log and permission IDs, separates denied access from successful access, and avoids automatically declaring a breach. The demo also shows benign cases that should not trigger alerts.

What we learned

We learned that security automation needs clear boundaries. Deterministic checks are a better basis for decisions like whether access was authorized; language models can help explain results, but shouldn’t invent evidence or make the final call. We also learned that useful alerts depend on knowing asset ownership and providing reviewers with enough context to make an informed decision.