Built for CISOs who verify everything.
SentinelEra runs on a closed-vocabulary architecture with a verifiable three-layer admin gate, hardware-bound agent identity, and tenant-controlled data residency. Every claim on this page maps to a shipped feature with test coverage — no marketing fluff.
Data Sovereignty
Tenants pick their data region at sign-up (EU / Saudi Arabia / UAE / Qatar / Bahrain / Oman / Kuwait). Per-tenant `ai_residency_policy` controls whether enrichment runs on a Frontier LLM, falls back to a deterministic rule engine, or runs entirely on-prem. Sovereign Saudi tenants on `rules_only` policy never see their data leave the configured region.
↳ T71 v1 — Sovereign Data Residency & AI Routing
Zero-Trust Endpoint Identity
Every agent computes a one-way hash of its hardware identity (hostname + MAC + OS family + OS version) on install. The backend stores it on first heartbeat and compares on every subsequent beat. Copying the installer to a rogue VM produces a different fingerprint within seconds — audit log fires, operator alerts within one refresh cycle.
↳ T97 v1 — Hardware-bound Agent UUID
Encryption Standards
Tenant secrets (Stripe customer IDs, Fernet-managed encryption keys for OpenSearch tokens, magic-link tokens) are stored under Fernet authenticated encryption (AES-128-CBC + HMAC-SHA256) at rest with a separate `pseudonymize_salt` for PII analytics export. All API traffic is TLS 1.3; the public dashboard pins HSTS preload + Strict-Transport-Security on the marketing surface.
↳ Task 30 §B.1 + Fernet via the shipped `core/security.encrypt_str`
Three-Layer Admin Gate
Every superadmin surface gates three ways: UI sidebar entries hidden from non-superadmins, soft-redirect on the frontend if the URL is typed directly, and a strict `require_role("superadmin")` dependency on every backend endpoint. Cross-tenant access returns HTTP 404 (not 403) so tenant IDs never leak across the boundary.
↳ T96 v1 — Admin Segregation Audit
Continuous Integrity Audit
An admin-only ENV Integrity Guardian walks the backend's Pydantic settings every page load, surfacing missing required keys + known dev-placeholder values. A closed-pattern leak scanner runs against the frontend build artefact (Stripe live keys, AWS access keys, Anthropic tokens, MongoDB URIs, PEM private keys) on operator demand. Every 401/403 hit on the admin surface writes an `admin.access_denied` audit row.
↳ T96 v1 — Environment Integrity Guardian
Compliance Catalogs
Closed framework catalogs: ISO 27001:2022, NCA ECC (Saudi Arabia), NESA IAS (UAE), HIPAA, PCI DSS 4.0, CIS Controls v8, GDPR Article 32, SOC 2 Type II, NIS2 Directive. Continuous evidence poller walks each tenant's framework set every 6 hours; per-framework progress rings on the compliance dashboard. Auditor Pack endpoint streams a SHA-256-signed PDF + structured ControlResults JSON bundle on demand.
↳ T1 / T17 / T67 / T76 / T82 — Compliance Stack
No Vendor Lock-in
Tenant admins export their workspace data as a ZIP archive of CSVs (audit logs, security logs, endpoints, users, playbooks) at any time. Secrets redacted via closed `<REDACTED>` policy — the archive proves field existence without leaking credentials. Workspace deletion is self-service with a 30-day grace period; type the workspace slug + a fresh TOTP to confirm.
↳ T99 v1 — GDPR Tooling
Closed-vocabulary commitments
Each commitment maps to a deliberate code change in our closed Pydantic Literals + automated tests. Adding or removing one of these is impossible without a tracked git commit.
- 100% GDPR Article 32 compliant — telemetry data processed under explicit EU data sovereignty rules
- MFA mandatory on every login (TOTP + WebAuthn / FIDO2 support)
- Step-up MFA required for destructive actions (host quarantine, IP block, kill process, workspace deletion)
- Per-tenant per-IP rate limits on every public endpoint
- Closed action vocabulary on SOAR playbooks — no free-form shell commands ever leave the dashboard
- Audit log for every authority decision; 90-day TTL on sensitive collections
- Cryptographically signed compliance PDFs (SHA-256) for auditor handoff
Where your telemetry actually goes.
Four stages, each verifiable in our open source code base and our security audit documents. We do not claim on-endpoint AI inference — our agent is a Wazuh-shim, collection-only. Enrichment runs server-side.
Stage 1
Customer endpoint (laptop / server / VM)
Wazuh-shim agent
Collects standardised event metadata (process create, file integrity, authentication, network) via Wazuh's syscheck + rootcheck modules. Binary file contents, screen contents, document contents are NEVER ingested.
↳ T27 — SIA agent shim
Stage 2
Transport (TLS 1.3)
TLS-encrypted REST
Outbound TCP 443 only. Agent POSTs heartbeat + log batches to the API on a bounded cadence; certificate chain pinned to the operator's API hostname. No inbound port opened on the endpoint.
↳ T54 — CGO=0 cross-compile + SHA256SUMS-verified release
Stage 3
SentinelEra API (operator-configured region)
Tenant-scoped storage
Tenants choose their data region at sign-up; multi-region routing is deployment-shape (one instance per region) rather than runtime-routed. Server-side PII pseudonymisation hashes emails / usernames / IPs via HMAC-SHA256 over a separate salt before analytics export.
↳ T71 — Sovereign Data Residency; T30 §B.1 — PII pseudonymise
Stage 4
Optional: Claude API enrichment (Anthropic, USA)
Frontier LLM enrichment
When the tenant's `ai_residency_policy` is `frontier_ok` (the default), the alert pipeline sends event metadata to Anthropic's Claude API for severity + MITRE technique + plain-English summary. Tenants on `rules_only` policy skip this stage and route through the SHIPPED `claude_fallback.py` deterministic rule engine — no data leaves the configured region.
↳ T23 — claude_fallback.py rule engine; T71 — ai_residency_policy
rules_onlyAI residency policy skip the Anthropic call entirely; the SHIPPED rule-engine fallback (T23 v1) produces the same enrichment shape, deterministically, inside the operator’s configured region. Tenants who do allow Claude enrichment send event metadata only — never raw file contents or screen captures.How EU-GDPR carries into UK-GDPR.
Where the operator chooses a UK-based deployment region, SentinelEra relies on the European Commission’s Adequacy Decision for the United Kingdom (Commission Implementing Decision (EU) 2021/1772 of 28 June 2021). For deployment regions outside the EU+adequacy area, we rely on the European Commission’s Standard Contractual Clauses (SCCs) adopted on 4 June 2021, supplemented by encryption in transit + at rest and server-side PII pseudonymisation.
EU-UK Adequacy Decision
Personal data transferred from the European Economic Area to a UK-hosted SentinelEra deployment region qualifies for the adequacy basis under Art. 45 GDPR, without additional safeguards. The decision’s sunset review is scheduled for 27 June 2025; SentinelEra tracks adequacy status and will publish an SCC fallback runbook if the decision is not renewed.
↳ Commission Implementing Decision (EU) 2021/1772
BSI-Grundschutz alignment
SentinelEra’s closed-vocabulary controls + audit surfaces map onto BSI IT-Grundschutz baseline modules (ORP.4 Identity & access, OPS.1.1.5 Logging, OPS.1.2.5 Operations monitoring, CON.10 Development of web applications, NET.3.2 Firewall, SYS.1.5 Virtualisation, APP.4.4 Containers). We document the per-module mapping in our compliance pack; we are not BSI- certified — “aligned”, not “audited”.
↳ T1 / T100 — Compliance Catalog (13 frameworks)
Server-side PII pseudonymisation
Emails / usernames / IPv4 / IPv6 / MAC addresses are hashed at the audit-write boundary via HMAC-SHA256 over a separate pseudonymize_salt (distinct from the application encryption key). The hash is 16 hex characters — sufficient to deduplicate across analytics rollups without retaining the raw value in the long-tail audit table.
↳ T30 §B.1 — core/pseudonymize.py
Closed sub-processor list
Sub-processors are: Anthropic (Claude enrichment, optional + skippable via the closed rules_only AI residency policy), Stripe (billing — not tenant-affecting), Resend (transactional email). Other threat-intel providers (abuse.ch / NVD / TAXII / MISP / OpenCTI / VirusTotal / Shodan / AbuseIPDB / HIBP) are operator-opt-in feed sources, not data processors of customer PII.
↳ T62 — AI Security Gateway (prompt-injection defence)