Sentinel AI

Find the vulnerabilities AI helped you write, before someone else does.

Comment

Inspiration

AI coding assistants have completely changed how software is written, but security practices haven't kept up. Companies are building AI agents that have permission to read databases, execute terminal commands, and send emails. If an attacker can manipulate an AI agent, they can gain control of the underlying system. Traditional security scanners are blind to many AI-specific vulnerabilities. Standard vulnerability scanners are designed to detect known CVEs or structural code flaws. They cannot detect threats such as indirect prompt injection, where an AI reads a malicious webpage or document and becomes hijacked, or data poisoning, where an attacker embeds malicious code inside model serialization formats such as unsafe PyTorch .bin or .pkl files that execute arbitrary code the moment the model is loaded into memory. AI systems are also vulnerable to slopsquatting, where a model hallucinates a non-existent package name that an attacker later registers to distribute malware. AI coding assistants allow developers to move at lightning speed, but they also make it incredibly easy to ship enormous amounts of code that developers did not fully write and often do not fully audit. That code carries a specific and repeatable set of risks, including hardcoded secrets left over from working examples, insecure default configurations reproduced from an AI model's training data, authentication logic that appears complete but silently short-circuits, and increasingly sophisticated backdoor patterns such as obfuscated shell execution or hidden authentication bypasses. Traditional security tools were not built for this new failure mode. They treat all code the same, regardless of whether every line was written by a human or generated by an AI model. This motivates me to develop Sentinel AI, an autonomous remediation loop that detects and remediates a targeted set of security vulnerabilities in AI-generated code, providing developers with a practical first line of defense for AI-accelerated software development. Sentinel AI combines deterministic static analysis, AI-grounded explanations, and tiered autonomous remediation to secure AI-generated application code.

What it does

Sentinel AI scans a GitHub repository and:

  1. Detects real vulnerabilities using 8 deterministic static detectors hardcoded secrets, insecure configs, typosquatted dependencies, obfuscated backdoors (decoded payloads fed into shell execution), hidden auth bypasses, suspicious outbound network calls, prompt injection risk, and unsafe model deserialization (pickle.load).
  2. Explains every finding in plain language such as severity, confidence, and real exploitability, using an AI reasoning layer that only ever explains what static detection already found. It never invents new findings, which keeps every result verifiable, not hallucinated.
  3. Fixes what it finds, with tiered autonomy:
    • Low-risk findings (secrets, bad config, bad dependencies) are auto-patched and opened as a real GitHub pull request.
    • Higher-risk findings (backdoors, auth bypasses) get a generated fix you review and approve with one click before a PR opens.
    • The riskiest, most ambiguous findings (like an unexplained outbound network call) are flagged with guidance only, Sentinel doesn't guess at a fix when the false-positive risk is genuinely high. Sentinel never pushes directly to your default branch. Every fix even fully automated one’s lands as a reviewable pull request on an isolated branch.

How we built it

I built Sentinel AI using Codex as our primary build agent across 10 structured sessions, backend scaffolding and database schema, the 8 static detectors, the AI reasoning layer, the tiered remediation engine, the scan orchestrator tying everything together, report generation, a Next.js frontend, and a landing page. At every stage, we validated against a real, intentionally vulnerable sample application built specifically for this project, not just unit test fixtures. This uncovered real gaps that synthetic tests missed: our config auditor initially only checked named configuration files and missed DEBUG=True set directly in application code; our backdoor detector initially only caught eval()/exec() and missed the actual planted backdoor, which used subprocess.run() fed by a decoded payload instead. We improved both detectors and verified the fixes against the same application. Sentinel AI is fully deployed as a live, end-to-end application where users can authenticate with GitHub, scan repositories, review AI-grounded findings, and open real remediation pull requests from the browser. Next.js frontend on Vercel, FastAPI backend and a dedicated scan worker on Railway, PostgreSQL on Neon, and Redis on Upstash so it's fully testable by anyone right now, not just runnable locally.

Challenges we ran into

  • OpenAI API credits turned out to be Codex-only for this hackathon, with no separate API credit pool for the app's runtime AI features. Rather than block on that, we pivoted the AI Reasoning Layer and Remediation Engine to Google's Gemini API, behind a provider abstraction that can switch back to GPT-5.6 with a config change and zero code changes.
  • Cross-domain production deployment surfaced a string of real, non-obvious bugs that never appeared in local development: a NEXT_PUBLIC_API_URL environment variable that silently held placeholder text instead of a real value; a GitHub OAuth redirect URI that didn't match between the OAuth App and our backend config; cross-domain session cookies that needed SameSite=None and Secure=true to work at all; a missing git binary in Railway's runtime container; and a git commit author identity error on fresh containers with no global config. Each one only appeared once the app was genuinely live, we found and fixed all of them through real, hands-on production testing rather than assuming things would "just work."
  • Deciding where to stop scope was its own challenge. I was asked directly whether Sentinel AI could detect AI-specific risks like data poisoning and model weight manipulation. After real investigation, I concluded those require analysing actual training data or model internals a fundamentally different problem from static code scanning, and deliberately did not claim that capability, instead adding two detectors that do fit the current architecture: prompt injection detection and unsafe model deserialization.

Accomplishments that we're proud of

  • A fully working, verified, live product not a mockup. Every claim we make is backed by evidence we produced ourselves: real PRs opened on a real GitHub repository (not simulated), a real 10-finding scan against our own planted vulnerabilities, real AI-generated explanations we can point to.
  • A safety-conscious remediation design. Sentinel never writes directly to a default branch, uses tiered autonomy instead of blanket auto-fix, and our AI reasoning layer is architecturally prevented from introducing findings it didn't detect deterministically first.
  • Catching our own tool's real gaps through real testing, not just assuming our detectors worked because unit tests passed on synthetic fixtures.
  • Deploying to real infrastructure under real hackathon constraints (Codex-only API credits, a tight timeline) without compromising on the core product experience.

What we learned

  • Static detection and AI reasoning are stronger together, in that specific order. Static-first, AI-second means every finding is grounded in something real and verifiable the AI layer adds understanding and prioritization, not new claims.
  • Production reveals bugs local development never will. Nearly every bug I hit post-deployment (cookies, redirect URIs, missing system binaries, environment variable configuration) was invisible until we actually tested the live, deployed system end-to-end.

What's next for Sentinel AI

  • Phase 1
  • Full multi-language AST parsing (Tree-sitter) to bring JS/TS detection up to the same structural precision as our Python analysis, beyond the current regex-based approach.
  • A same-origin proxy between frontend and backend to eliminate the cross-domain cookie limitation entirely, so sign-in works reliably in every browser privacy mode.
  • CI/CD integration automatically scan every commit, pull request, and deployment instead of relying solely on manual scans.
  • Phase 2
  • Deeper dependency intelligence real vulnerability database (CVE) matching and known-malicious package version checks, instead of heuristic-only typosquat detection.
  • Controlled, sandboxed dynamic analysis execute applications in isolated environments to uncover hidden backdoors, malicious runtime behavior, and logic that static analysis cannot reliably detect.
  • IDE extensions (VS Code, Cursor, Windsurf, JetBrains)/Public API & SDK
  • Phase 3
  • Automated Red Team mode Simulate AI-specific attacks, including prompt injection, dependency poisoning, command injection, and jailbreak attempts, to validate application resilience.
  • Cloud misconfiguration scanning detect security issues across AWS, Azure, and Google Cloud environments.
  • Compliance mapping generate security reports aligned with OWASP Top 10, SOC 2, and other industry frameworks.
  • Phase 4
  • Executive Risk Dashboard provide a centralized security overview across repositories, teams, and projects.
  • Incident response workflowsautomate alerting, remediation tracking, and response coordination.
  • Threat intelligence integration continuously incorporate emerging AI attack techniques and threat intelligence into detection capabilities.
  • Enterprise collaboration and RBACsupport team-based workflows with role-based access control, audit logs, and centralized administration.

Built With

Share this project:

Updates