Trust Center

Security & Compliance

Last reviewed: June 2026 · Security contact: security@sentinelsecurity.io

🔐

AES-256 At Rest

All stored telemetry, command logs, and credentials encrypted with AES-256-GCM

🛡

TLS 1.3 Transit

All communications over TLS 1.3. TLS 1.0 and 1.1 are disabled across all endpoints

🪪

JWT Zero-Trust

Per-device signed JWT tokens with version revocation — no shared credentials

🌍

Kenya DPA 2019

Fully aligned with Kenya Data Protection Act 2019 requirements

🇪🇺

GDPR Aligned

Data minimisation, purpose limitation, and subject rights implemented

🔍

Pen Tested

Regular penetration testing of all API endpoints and web interfaces

Architecture Overview

Sentinel is built on a zero-trust, service-isolated architecture. Every device communicates independently through its own authenticated channel. No device can observe or influence commands issued to another device on the same account.

Device Agent ──── TLS 1.3 ────▶ API Gateway (Vercel Edge) ──▶ Flask API
Flask API ──── JWT verify ────▶ Command Queue ──▶ Device (poll model)
Admin Browser ── Session + CSRF ──▶ Flask API ──▶ Database (PostgreSQL)

Commands are stored server-side and delivered on the device's next poll cycle — typically within 15 seconds on an active connection. This pull-model means the server never holds an open connection to devices, reducing the attack surface.

Security Controls

Control	Implementation	Status
Authentication	Flask-Login session auth for dashboard; JWT HS256 tokens for device agents. Token version field enables instant per-device revocation.	Active
CSRF Protection	Server-generated CSRF token injected into every page and verified on all state-changing requests (POST/PUT/PATCH/DELETE) via X-CSRF-Token header.	Active
Session Security	Server-side session storage with HttpOnly, Secure, SameSite=Lax cookie flags. SESSION_PROTECTION="strong" enabled via Flask-Login.	Active
Security Headers	X-Content-Type-Options: nosniff; X-Frame-Options: DENY; Referrer-Policy: strict-origin-when-cross-origin; Permissions-Policy restricts camera/microphone/geolocation to same-origin.	Active
Password Hashing	bcrypt via Werkzeug security. Plaintext passwords are never stored or logged.	Active
Input Validation	Device type and action whitelists enforced server-side. All API inputs validated before database writes. No eval(), exec(), or shell interpolation of user input.	Active
SQL Injection	SQLAlchemy ORM with parameterised queries throughout. No raw SQL concatenation.	Active
Rate Limiting	Vercel edge rate limiting on login and token endpoints.	Monitoring
Audit Logging	All device commands, authentication events, and admin actions are logged with timestamps and IP addresses.	Active
Evidence Chain	Evidence hashes stored per-telemetry entry for chain-of-custody integrity on stolen-device cases.	Active
CORS Policy	CORS restricted to explicit allowed origins in production. No wildcard access to authenticated endpoints.	Active
2FA / MFA	Admin accounts support TOTP-based 2FA. Planned for all accounts in Q3 2026.	Roadmap Q3 2026

Penetration Testing

All major API endpoints and authentication flows are subject to regular penetration testing. Testing covers:

OWASP Top 10 Auth Bypass JWT Attacks IDOR SQL Injection XSS CSRF Broken Access Control Insecure Deserialization

Data Handling

At rest: Device telemetry, command logs, and user data are stored encrypted in a PostgreSQL database hosted on Vercel/Neon infrastructure in the EU (Ireland) region.
In transit: All HTTP traffic uses TLS 1.3 with forward secrecy ciphers. Certificate management is handled by Vercel's edge network.
Backups: Daily automated backups with 30-day retention. Backups are encrypted at rest.
Snapshot images: Stored with AES-256 encryption. Accessible only to the account holder and, if flagged as stolen-device evidence, to verified law enforcement with a court order.

Incident Response

Our incident response process follows a 4-stage model:

Detect — continuous monitoring of authentication anomalies, unusual command volumes, and API error rates
Contain — automatic account lockout after repeated failed authentication attempts; admin notification
Investigate — forensic review of audit logs with immutable timestamp chain
Notify — affected customers notified within 72 hours of confirmed breach per KDPA requirements

Vulnerability Disclosure

Responsible Disclosure Policy

We welcome security researchers who identify vulnerabilities in Sentinel Security System. To report a vulnerability:

Email security@sentinelsecurity.io with "SECURITY:" in the subject line
Include a description of the vulnerability, proof of concept, and potential impact
Do not exploit the vulnerability beyond what is necessary for demonstration
Do not access or modify other users' data

We commit to: acknowledging your report within 48 hours, keeping you informed of our investigation progress, and crediting you in our security acknowledgements (if desired) once the vulnerability is remediated.

We do not pursue legal action against researchers who act in good faith and comply with this policy.

Regulatory Compliance

Kenya Data Protection Act 2019 — Data controller registration, privacy policy, subject rights, breach notification within 72 hours
GDPR (Art. 3) — Applied to EU-resident users and EU data subjects; data processing agreements with all sub-processors
Kenya Computer Misuse and Cybercrimes Act 2018 — Platform terms prohibit unauthorised access; cooperation with law enforcement on reported incidents
Kenya Communications Act — Electronic communications standards applied to device agent protocols

Enterprise customers requiring formal compliance documentation (DPA templates, security questionnaire responses, audit reports) should contact security@sentinelsecurity.io.