sEyeber Hub is designed around read-only discovery, organization-scoped isolation, least-privilege access, and a vendor stack chosen for strong security controls. Our objective is to help firms understand risk without creating new operational risk.
The platform security model is built to minimize blast radius, avoid unnecessary privileges, and keep one customer organization's data logically separate from another's.
sEyeber Hub is designed to request read-only connector scopes wherever supported so it can observe security posture without changing settings, deploying policies, or writing back into customer environments.
Each customer organization is designed to operate inside its own tenant boundary with separate access control, data storage boundaries, and processing context so firms are not exposed to each other's scan data.
Because subscriptions are organization-based, admin access, billing access, connector management, and operational actions are designed to align with organization roles instead of being tied permanently to one individual user.
The product is intended to retain only the data needed to deliver discovery, evidence, mappings, and mitigation workflows, rather than collecting broad unnecessary datasets that expand customer risk.
sEyeber Hub is being designed to use organization-scoped AI processing contexts. In practice, that means a firm's scan inputs, retrieved evidence, prompts, intermediate artifacts, and generated outputs are intended to stay within that firm's own processing boundary rather than being reused as context in another firm's scan workflow. Planned AI controls include strict tenant scoping for retrieval, least-privilege human access to outputs, minimized prompt logging, secrets isolation, and a policy that customer scan data should not be used to train shared models unless the customer explicitly opts in.
These are the security concepts prospects typically ask about when reviewing a cybersecurity platform for financial services use.
Connector credentials, API tokens, and other sensitive secrets should be stored encrypted, tightly scoped, revocable, and inaccessible to unauthorized users or downstream customers.
Customer data should be protected in transit and at rest throughout the application stack, including application traffic, internal services traffic, and database storage layers.
Administrative actions, connector changes, authentication events, and security-relevant workflow actions should be auditable so organizations can review how the platform is being used.
Infrastructure and application components should be maintained with timely patching, secure code review, dependency hygiene, and controlled deployment practices.
The following capabilities are based on vendor-documented security materials for our current stack architecture as of April 12, 2026.
Stripe underpins billing and subscriptions so payment-card handling can stay inside a mature payments-security environment rather than being recreated inside the core application.
Netlify serves the static marketing surface with a reduced attack surface, encrypted traffic, enterprise access controls, and built-in DDoS protections at the edge.
Fly.io runs the FastAPI backend with hardware isolation, encrypted networking, internal service protection, and secure storage primitives designed for cloud infrastructure.
Neon provides the PostgreSQL layer with strong compliance posture, database security features, and support for read-only compute patterns that fit least-privilege design.
Security FAQ
A few high-frequency questions from this page’s topic. For the full list, see the FAQ.
Each customer organization is designed to operate inside its own tenant boundary in the sEyeber Hub data model — separate access control, storage scope, and AI processing context. One firm's scan inputs, evidence, prompts, and generated outputs are not used as context for another firm's workflows.
No — not by default. AI is used to suggest questionnaire answers, draft narratives, and propose remediation language, with processing scoped to the customer organization. Customer scan data is not used to train shared models unless the customer explicitly opts in.
The app runs on Fly.io, data lives in Neon (PostgreSQL), the marketing site runs on Netlify, and payments are processed by Stripe. Each vendor carries documented SOC 2 / ISO 27001 posture so buyer-diligence conversations reference third-party controls rather than self-attested ones.
