Skip to content

Security: lubobali/Sentinel-AI

Security

SECURITY.md

Security Policy

Sentinel-AI is an inbox-triage agent that operates on real email traffic. Vulnerabilities in this codebase can lead to unauthorized email access, prompt-injection-driven actions, or leakage of sender PII. We treat security reports with the seriousness that implies.

Supported versions

Only the latest tagged release on main receives security fixes. Older tags are kept for historical reference only.

Version Supported
main
< 0.1.0

Reporting a vulnerability

Please do not open a public GitHub issue for security reports.

Email lubobali23@gmail.com with the subject line SECURITY: Sentinel-AI — <short description>.

Include, at minimum:

  • A description of the issue and its impact.
  • Reproduction steps or a proof-of-concept (a failing test is ideal).
  • The commit hash, tag, or release affected.
  • Whether the issue is already public anywhere.
  • Optional: a suggested fix or mitigation.

We will acknowledge receipt within 72 hours and aim to provide an initial assessment within 7 days. Coordinated disclosure timelines are negotiated case by case; the default is 90 days from the date of the initial report.

Scope

In scope:

  • Code in this repository (sentinel/, tests/, scripts/, docker-compose.prod.yml, Dockerfile, CI workflows).
  • Default configuration documented in .env.example and the README.
  • Documented deployment patterns in docs/RUNBOOK.md.

Out of scope:

  • Vulnerabilities in upstream dependencies — please report those to the relevant project. We will of course bump our pin once an advisory is published.
  • Issues that require pre-existing local code execution, root on the host, or compromise of the operator's Google account.
  • Social-engineering of project maintainers.
  • Denial-of-service via legitimate API traffic without an amplification factor.

Threat model

Sentinel-AI's design assumes:

  1. Untrusted email content. All subject and body values are treated as adversarial input. The injection guard runs before any classification step.
  2. Untrusted LLM output. Provider responses are parsed defensively (strict JSON schema, fail-closed to Sentinel-Needs-Review).
  3. Trusted operator. The person holding the API key, OAuth refresh token, and .env is trusted. Compromise of those secrets compromises the agent — rotate immediately.
  4. No outbound write capability. The agent has Gmail modify scope (label only) and Calendar events scope (create only). It cannot send mail or delete anything by design. Any PR that adds send or delete capability requires explicit security review.

Hardening already in place

  • Sender allowlist enforced at fetch time (sentinel/safety/allowlist.py).
  • Prompt-injection pattern guard (sentinel/safety/injection_guard.py).
  • Idempotent processing via Postgres processed_emails table.
  • Fail-closed JSON parsing for all LLM responses.
  • PII hashing (sha256[:16]) on sender addresses in logs.
  • API-key auth on all non-health endpoints, with primary/secondary keys for zero-downtime rotation.
  • Rate limiting on the FastAPI surface.
  • Container hardening: non-root user, read-only root filesystem, 127.0.0.1 bind, dropped capabilities.
  • Dependency scanning in CI: pip-audit, bandit -ll.
  • Static type checking under mypy --strict.

Credit

We're happy to credit reporters in the release notes for the fix unless you ask us not to. Please tell us how you'd like to be named (or anon) when you report.

Out-of-band contact

If email is not viable, open a GitHub issue titled SECURITY: please contact me — no details and we'll reach out via the contact method on your GitHub profile within 72 hours.

There aren’t any published security advisories