Overview
Security in LuMay is structural, not cosmetic. Tenant isolation is enforced at the PostgreSQL layer via Row-Level Security - not an application-level filter that can be bypassed by a bug in application code. Authentication flows through Keycloak (or your own identity provider). Authorisation uses a three-role RBAC model applied as decorators at every API route. Audit trails include a correlation ID on every request, linked to OpenTelemetry traces that capture every hop from API call to database query to connector dispatch.
Human-in-the-loop gates enforce human review on sensitive actions before execution. PII detection and masking is configurable per tenant. Secrets are managed via Azure Key Vault using workload identity - no credentials live in environment variables or configuration files.
Security Controls
| Control | Implementation |
|---|---|
| Authentication | Keycloak SSO - SAML / OIDC integration with your identity provider. JWT bearer tokens on every API call with configurable expiry. |
| Authorisation (RBAC) | Three roles applied as route-level decorators: authenticated (read), customer_admin (write within tenant), internal_admin (cross-tenant operations). No implicit privilege escalation. |
| Tenant isolation (RLS) | PostgreSQL Row-Level Security. Every application query runs as the app user with RLS enforced - queries can only see rows belonging to the authenticated tenant. SET app.current_customer_id on every query. |
| Audit trail | X-Correlation-ID generated server-side on every request. Full trace via OpenTelemetry. Every API call, database query, and connector dispatch is traceable end-to-end. |
| PII controls | Detection and masking of personally identifiable information, configurable per tenant. Applied at the interface layer before data enters the reasoning pipeline. |
| HITL gates | Human-in-the-loop approval gates on sensitive or high-value actions. Gates are defined at the orchestration layer and cannot be bypassed by individual agent configurations. |
| Secrets management | Azure Key Vault integration using workload identity. No credentials in environment variables or configuration files. Connector OAuth tokens stored in the vault, not in the application database. |
| Webhook validation | Twilio: X-Twilio-Signature verification on every inbound webhook. Stripe: webhook signature verification. All inbound webhooks are validated before processing. |
Evaluating AI vendors for compliance?
Book a 15-minute call. We'll map LuMay's controls to your specific regulatory obligations - SOC 2, HIPAA, GDPR, or your own security policy.
The Dual-User Database Model
LuMay uses two PostgreSQL users with different permission levels:
- App user - every application query runs under this user. Row-Level Security is enabled and enforced, meaning queries can only access rows belonging to the tenant identified by the
app.current_customer_idsession variable. A bug in application code physically cannot access another tenant's data - the database engine enforces the boundary. - Admin user - used exclusively by Alembic for database migrations. This user bypasses RLS, allowing schema changes and data migrations. It is never used for application queries and has no role in the request path.
This design means even a complete compromise of application code cannot expose cross-tenant data through the normal query path. The isolation boundary is at the database, not the application.
Compliance Alignment
- SOC 2 Type II - audit logging (every request with correlation ID and OTel trace), access controls (RBAC at every route), encryption in transit (TLS), and tenant isolation (RLS) directly support the trust service criteria.
- GDPR / UK GDPR - PII detection and masking, configurable data residency via deployment model, and audit-trail support for subject rights requests and data processing records.
- HIPAA - via private cloud or on-prem deployment with a Business Associate Agreement. Data residency, encryption, and access controls are the same across all deployment models.
Industry Compliance By Sector
Enterprise security requirements vary by industry. Here is how LuMay's controls apply across the sectors we serve.
Healthcare
Healthcare organisations handling Protected Health Information (PHI) can deploy LuMay in a private cloud or on-premises environment. LuMay signs a Business Associate Agreement (BAA) as part of the enterprise engagement. PII and PHI detection and masking is applied at the interface layer before data enters the reasoning pipeline. RBAC restricts access to authorised clinical and operational roles. Audit trails meet the HIPAA audit control standard (45 CFR § 164.312(b)). Voice agents, clinical document summarisation, and prior authorisation workflows all operate within this boundary.
Finance And Insurance
Financial services firms require regulator-ready audit evidence and strict data residency. LuMay's OpenTelemetry-linked audit trail-with correlation IDs on every request- provides the logging depth required for internal audit, external examination, and SOC 2 Type II assessments. Data residency is configurable via BYOC or private cloud deployment into your chosen Azure region. AI agents processing loan documents, claims, or financial records operate under tenant isolation enforced at the database layer.
Legal And Professional Services
Law firms and professional services organisations have strict confidentiality obligations. LuMay's per-tenant isolation means client matter data is physically separated at the database layer-not just logically separated in application code. PII masking protects personally identifiable information in documents before they enter the reasoning pipeline. HITL gates enforce human review on sensitive actions such as contract drafts or matter-related correspondence. Attorney-client privilege boundaries are preserved by design.
Manufacturing And Supply Chain
Operational data-production schedules, supplier records, quality metrics-is isolated per tenant and never shared across organisational boundaries. LuMay supports deployment within on-premises or private network environments where operational technology (OT) and IT systems must remain separated. Workflow automation agents operating on supply chain data respect the same RBAC and RLS controls as all other workloads.
Security FAQ.
Common questions from CISOs, compliance teams, and enterprise security reviewers.
Your data never co-mingles with another tenant's data. LuMay enforces tenant isolation at the PostgreSQL layer using Row-Level Security - not an application-level filter. Every query runs under a session variable scoped to your organisation, so even a bug in application code physically cannot reach another tenant's rows. For maximum control, LuMay supports private cloud and on-premises deployment where your data never leaves your infrastructure. In the SaaS model, data is hosted in Azure with AES-256 encryption at rest and TLS 1.3 in transit.
No. The application query user operates under Row-Level Security, which means standard queries are scoped to your tenant only. Cross-tenant access requires the admin database user, which is reserved exclusively for schema migrations (Alembic) and is never used in the request path. Support and engineering staff do not have ad-hoc query access to production customer data. Access logs are captured via OpenTelemetry traces and are available for your audit review on request.
LuMay supports HIPAA via its private cloud and on-premises deployment models, where all PHI stays within your infrastructure boundary. We sign a Business Associate Agreement (BAA) as part of the enterprise engagement. Controls include: PII and PHI detection and masking at the interface layer before data enters the reasoning pipeline, RBAC restricting access to authorised clinical or operational roles, full audit trails meeting the HIPAA audit control standard, and encryption at rest and in transit. Contact us to walk through how these controls map to your specific compliance posture.
LuMay is provider-agnostic. In the default SaaS configuration, the platform connects to Azure OpenAI, which processes your prompts within Microsoft's enterprise data boundary and does not use your data to train models (covered by Microsoft's Azure OpenAI data privacy terms). You can also configure LuMay to use your own Azure OpenAI resource, Anthropic, or a locally-hosted open-source model - meaning the model provider is entirely within your control. Credentials for all model providers are stored in Azure Key Vault using workload identity, not in environment variables.
Every request generates an X-Correlation-ID that links the API call, database queries, connector dispatches, and model calls into a single traceable chain via OpenTelemetry. This covers the SOC 2 logical access, system monitoring, and audit logging criteria. RBAC is enforced at every API route as a decorator - authorisation logic is not ad-hoc. Secrets are managed through Azure Key Vault, supporting the SOC 2 encryption and key management criteria. We can provide our security documentation package and architecture diagram to your auditors directly.
Yes. LuMay offers four deployment models: SaaS (LuMay-managed on Azure), Bring Your Own Cloud (BYOC - deployed into your Azure subscription), Private Cloud (dedicated single-tenant cloud environment), and on-premises. BYOC and on-premises deployments give you full control over data residency, network boundaries, and access policies. The platform architecture is identical across all deployment models, so you do not lose functionality by choosing a stricter deployment posture. Book a 15-minute discovery call to discuss which model fits your compliance and infrastructure requirements.
Related
- Architecture - the Governance layer (05) in the six-layer stack context
- Deployment - how deployment model affects data residency and compliance posture
- Connectors & Adapters - how connector credentials and OAuth tokens are secured
- AI Governance Framework - the six-layer governance architecture that this sits within
- Enterprise Guide to Agentic AI - how LuMay's governance model fits the agentic AI stack
- Platform overview - all four engines and four trust pillars