Database-per-tenant
Each tenant has a separate PostgreSQL database and role. This is a strong defence against application-layer cross-tenant mistakes; it is not protection from a fully compromised host.
Benedam is sold to technical security teams. Our public claims are deliberately narrower than our ambitions and change only when a control is deployed, tested, and evidenced.
These statements describe implemented architecture, not certifications or future controls.
Each tenant has a separate PostgreSQL database and role. This is a strong defence against application-layer cross-tenant mistakes; it is not protection from a fully compromised host.
PostgreSQL RLS is applied inside the tenant database as defence in depth. Tenant identity is set with SET LOCAL inside a transaction so pooled connections cannot retain another caller’s context.
Cookies use the __Host- prefix and never Domain=.benedam.com. Tenant access tokens are bound to the host audience; cross-host transitions use a short-lived handoff code.
ROSS has no database network access and no write tools. It forwards the caller’s token to read-only domain APIs, and tenant identity never comes from a model-supplied argument.
Automated scan results are drafts. Only an authorised BalticSec operator can validate and publish a finding to a client.
The pilot engine uses a dedicated Redis stream identity and scoped callback token. It has no PostgreSQL route, no Docker socket, and no privileged container access.
EU hosting is active. Some customer-readiness controls remain blockers and are not marketed as complete.
Real customer scanning and evidence retention remain blocked until every gate is completed and recorded.
Please use our coordinated disclosure process. Do not test production customer workspaces or access data that is not yours.
Responsible disclosure policyExplore a read-only product tour, or tell us what you need to prove and we will scope it with you.