Sentinel Ai- An AI Powered Autonomous Security & Threat Detection Platform

Sentinel AI proposes a centralized security and governance layer for autonomous AI agents. The submission walks through six modules that sit in front of every agent request: Prompt Firewall, Threat Detection, Tool Monitor, Response Validation, Timeline Replay, and a Security Graph that visualizes how agents interact. On the stack side, the dashboard runs on React, the backend on FastAPI and Python, the model is served through Groq, storage lives in PostgreSQL, and the whole thing ships in Docker. The framing is unified governance for prompt injection, unauthorized tool execution, data leakage, hallucinated responses, and missing audit trails.

The scope here is genuinely ambitious for a weekend, and that deserves to be said up front. Six interlocking modules, a real backend, a dashboard, and a containerized deploy add up to a lot of moving parts for a B.Tech student to wire together in 48 hours. Putting a request pipeline in front of agent execution is also the right architectural instinct. The split between firewall, detection, validation, and replay maps cleanly onto how production AI security teams actually carve up their controls. Timeline Replay and the Security Graph are the most interesting pieces, since attack-chain reconstruction is one of the weaker spots in current open tooling, and pushing past single-prompt defense matters for the Asia technical safety track.

Where the submission would benefit most is reproducibility on the code side. A demo video is shared via the project drive, which is a real piece of evidence and shifts the read of the work substantially. The Results section itself is still six green checkmarks with no logs and no benchmark numbers, and the source repository is not public. Together this means a reviewer can see that something runs, but cannot pull it down and replicate the modules independently. A public repository (even rough) would close that gap. Alongside that, a small adversarial prompt set with results compared to Garak, PyRIT, or NeMo Guardrails would let readers locate Sentinel AI on the same evaluation axis as prior art. Two or three end-to-end scenarios walked from an injected prompt to the logged event on the dashboard, ideally with timestamps that map back to the video, would also anchor the architecture claims in observable behavior.

The broader signal is positive. A student shipping an integrated agent-security platform with a working backend, a dashboard, and a containerized deploy is aiming at the exact gap that industry teams are scrambling to fill right now. Future iterations would benefit from plugging into the open ecosystem on both sides, red-team tools like Garak and PyRIT for evaluation, and runtime guardrails like NeMo Guardrails or Llama Guard for defense. That positioning would move the work from adjacent to the conversation into a recognized contributor to it, and would also sharpen the pitch when the platform is presented to research or industry audiences.

There is clearly real building effort behind this, and the screenshots show it. The interface is polished and the scope is broad — a working dashboard with a prompt firewall, tool monitor, risk engine, response validation, timeline replay, and a security graph, with what look like genuine UI states (a 95/100 grounded response, a 47.3 average-risk tool monitor, a security graph of agent interactions). For a solo build, getting that many modules into a live, coherent-looking product is an accomplishment, and the problem framing — autonomous agents needing a unified monitoring and governance layer — is a real and current concern.

I want to be honest with you about where this stands as a research submission, because that is what is being judged here, and that is where the gaps are:

1. This is a product pitch deck, not a research report. It is nine presentation slides describing what the platform does, with no methodology, no description of how any module actually detects anything, and no statement of what was measured. The other submissions in this track describe a hypothesis, a method, an experiment, and a result. This describes features. For the work to be evaluable as safety research, it needs to explain how the prompt firewall decides a prompt is malicious, what the risk engine computes, and how response validation grounds an output — none of which is here.

2. There are no results in the research sense. The "Result & Testing" slide is a list of checkmarks — "Prompt Firewall blocked malicious prompt," "Threat Detection identified attack chain" — next to a screenshot. There is no dataset, no number of attacks tested, no detection rate, no false-positive rate, no baseline. The screenshot shows "9 attack vectors found" on what appears to be a single hand-entered test prompt. So there is no way to tell whether the firewall catches injections in general or just the one shown. A claim like "blocked malicious prompt" needs a test set and a measured rate behind it.

3. No evaluation of the hard part. Every module here wraps an LLM (Gemini/Groq) calling another LLM to judge prompts and responses — which means the firewall and validator are themselves susceptible to the exact attacks they are meant to stop (prompt injection of the judge, hallucinated risk scores). The interesting safety question is whether an LLM-based monitor can be fooled, and that is not tested at all. Without it, the platform asserts security rather than demonstrating it.

4. Smaller points: the audit-log module is marked "Coming in Phase 2+," so part of what is shown is not built; there is no related-work or comparison to existing tooling (and there is a lot of it in this space — Lakera, LLM Guard, NeMo Guardrails — which the deck does not engage); and there is no LLM-usage statement or code repository link that I can see in the document.

On presentation: judged as a slide deck it is clean and the diagrams are easy to follow, but judged as a hackathon research submission the format itself is the problem — there is no abstract, no method section, no results section, and the reader cannot find the core content (problem, method, findings, limitations) that the rubric asks about because most of it is not present. The screenshots carry the substance, and a reader cannot extract from them what was actually done or measured.

Overall this is an ambitious, nicely-built product prototype that has not yet been turned into evaluable safety research. The single most important next step is to pick one module — the prompt firewall is the natural choice — assemble a labeled set of injection and benign prompts, and report how often it catches them and how often it false-flags, including attempts to fool the LLM judge itself. That one experiment would convert this from a demo into a finding.

Sentinel AI targets a relevant and practical problem: autonomous agents need centralized monitoring, prompt filtering, tool-use visibility, risk scoring, and response validation. The proposed platform architecture is easy to understand, and the dashboard-oriented approach could be useful for teams deploying agents in production.

The strongest part of the project is its broad systems framing. The modules listed — prompt firewall, threat detection, risk engine, response validation, timeline replay, and security graph — cover many of the right surfaces for AI agent governance. The technology stack also seems practical for a hackathon prototype.

The main weakness is that the submission is too high-level to evaluate the technical contribution. It does not provide enough detail on how threats are detected, how the risk score is computed, what prompt-injection dataset or test cases were used, how response validation works, or how tool execution is monitored. The results are presented as checklist claims rather than measured outcomes, so it is unclear whether the system reliably detects real attacks or only demonstrates a few scripted examples.

To improve, the paper should include a concrete threat model, system diagrams with data flow, implementation details for each security module, and quantitative evaluation: attack types tested, number of prompts, detection rates, false positives, latency overhead, and comparison against simple baselines. It would also help to narrow the scope around one or two core innovations rather than claiming a full AI SOC platform.

Overall, this is a useful product concept and prototype direction, but the current submission needs more technical depth, reproducible experiments, and measured evidence to support its security claims.