ArchitectureA supervised JVM-class runtime — OLTP on seven engines, OLAP on three. AI-native, MCP-native, observable as plain SQL.Read the architecture
Está viendo la edición Perú. Está viendo la edición Colombia. You're viewing the Pakistan edition. Cambiar a la edición global →Cambiar a la edición global →Switch to the global edition →
Platform · Security

Eight authentication mechanisms, multi-tenant by construction, audit by default.

A unified dynamic dispatcher routing to eight authentication mechanisms — HTTP Basic, Digest, Form + 2FA, JWT, OAuth 2.0, OpenID Connect, SAML 2.0 and mTLS. Multi-tenancy enforced through scoped per-request context at the runtime level. Row and column security injected into every query. Audit is a property of every write, not a feature added on top.

Eight authentication mechanisms — HTTP Basic, HTTP Digest, Form + 2FA, JWT Bearer, OAuth 2.0, OpenID Connect, SAML 2.0 and mTLS — flowing into a single unified perimeter that carries three uniform guarantees: tenant isolation, row and column security, and audit governance.

Eight mechanisms, one perimeter

HTTP Basic, Digest, Form + 2FA (TOTP / Email / SMS), JWT, OAuth 2.0, OpenID Connect, SAML 2.0, mTLS — unified under a single dynamic dispatcher. Mix LDAP, SSO and certificates inside a single installation.

Multi-tenant by construction

The runtime binds the authenticated principal and the target database to the request via scoped values (JEP 446). Applications cannot bypass tenant scoping; the runtime enforces it.

Row and column security injected by the compiler

The query compiler — not the application, not any AI agent that authored the query — injects tenant-scoping WHERE clauses, row-level expressions and column-level visibility rules into every generated SQL statement. Security is a property of the compilation, not a discipline the application has to remember.

Audit is a property of every write

Every transaction, master-data change and approval is recorded with timestamp, user identity, source document and prior-value history. The audit trail is the record, not a log of it.

Eight authentication mechanisms

Dispatched per request by a single dynamic authenticator. Same installation can authenticate users from LDAP, OAuth, SAML and client certificates concurrently.

HTTP Basic

Base64-encoded credentials over TLS. For service-to-service integrations where token lifecycle is unnecessary.

HTTP Digest

Challenge-response authentication; credentials never transmitted in plaintext.

Form + 2FA

Browser-form login with TOTP (RFC 6238), email OTP, SMS OTP or CAPTCHA. The default for interactive users.

JWT Bearer

Stateless signed-token validation. Signature, claims and expiry verified per request. Per-user revocation salt for instant invalidation.

OAuth 2.0

Authorisation-code flow, token introspection, refresh tokens. Integrates with enterprise identity providers.

OpenID Connect

OIDC discovery, ID-token validation, userinfo endpoint, claim mapping to platform principals.

SAML 2.0

SP-initiated SSO, assertion parsing, signature verification. The standard for enterprise federation.

mTLS

X.509 client certificates with DN-to-principal mapping. For service-to-service trust in regulated environments.

Multi-tenancy and access control

Tenant isolation is a property of the runtime, not a discipline applied by application developers.

Scoped per-request context

Every request runs inside a scoped context that binds the authenticated principal, the target database and the tenant identity. Scoped values (JEP 446) make it impossible for application code to read out-of-scope context.

Per-tenant database routing

The bound database in the request context determines which JDBC pool, which engine and which replica the request hits. Tenants share infrastructure; they never share data.

Row-level security — injected by the compiler

Per-object SQL expressions injected by the platform's query compiler into every SELECT. Roles, departments and ownership rules are enforced at the data tier — not by application code, not by any AI agent that authored the query, not by any layer that could be bypassed. The security expression is a property of the user's runtime context; the compiler resolves it into the WHERE clause every time.

Column-level security — injected by the compiler

Field-level visibility rules per role, applied during query compilation. Sensitive columns are not just hidden from the UI — they are removed from the generated SELECT for users not entitled to read them. The data never leaves the database for users without entitlement.

RBAC with explicit deny-by-default

Role enforcement applied at endpoint level, before handler execution. In-handler role and policy checks for data-dependent rules. No way to bypass.

Audit by default

Every write is recorded with full context — user, timestamp, IP, mechanism, source document, prior-value history. A separate audit channel records authentication events independently of the data-write log.

Defence in depth, applied per layer

Security on the platform is not a single feature. It is a chain of guarantees applied at each layer the request passes through — TLS at the network edge, IP rules at the perimeter, OWASP filter at the HTTP layer, the eight-mechanism authenticator at the application edge, scoped tenant context in the runtime, row and column security at the SQL layer, mandatory audit at the persistence layer. Each layer makes assumptions about the layer below; none of them trust the application above.

The result is a posture where misbehaving application logic cannot leak data, cannot impersonate another tenant, cannot bypass rate limits and cannot escape the audit trail. The application's job is to express business logic; the platform's job is to enforce that the logic operates inside the rules.

The same architectural property covers AI agents. Agents on the platform generate XDBL (the platform's XSD-described query grammar), not raw SQL; the compiler emits engine-native SQL with row-level and column-level security injected per the user's runtime context. The agent does not connect to the database; the compilation step sits between the agent and the data. See platform/ai-mcp.html for the full chain.

Security questions

What CISOs and security architects ask first.

Which authentication mechanisms are supported, and can we mix them in one installation?

Eight mechanisms — HTTP Basic, HTTP Digest, Form + 2FA (TOTP / Email OTP / SMS OTP / CAPTCHA), JWT Bearer, OAuth 2.0, OpenID Connect, SAML 2.0 and mTLS — unified under a single dynamic dispatcher that routes per request. A single installation can authenticate LDAP users for the back office, SAML for federated partners, OAuth for the customer portal and mTLS for service-to-service traffic concurrently. There is no requirement to standardise on one mechanism.

How is multi-tenant isolation enforced — at the application or at the runtime?

At the runtime, through scoped values (JEP 446) that bind the authenticated principal and the target database to the request. Applications cannot bypass tenant scoping because the runtime is what holds it ; the compilation step that turns metadata into engine-native SQL injects the tenant clause regardless of what the application asked for. Isolation is a property of the platform, not a discipline the application has to remember.

Where does row-level and column-level security live?

In the query compiler. The compiler — not the application, not any AI agent that authored the query — injects tenant-scoping WHERE clauses, row-level expressions and column-level visibility rules into every generated SQL statement. The same rule applies whether the query came from a generated screen, a server-side handler, an AI agent or an external MCP client. Security is a compilation step, not an application discipline.

What does the audit trail actually record, and how is it queried?

Every login, every REST call, every DML write, every approval, every AI invocation and every active session — captured with timestamp, user identity, source document and prior-value history. The audit trail is the record itself, not a log of it. Records are queryable as standard SQL through the platform's audit schemas alongside the rest of the application's data, so compliance teams use the same query surface engineers use.

How is offboarding handled — what happens when an account is revoked?

Offboarding is a single action that revokes database access, API access and active sessions in one step, propagated cluster-wide via Redis pub/sub. JWT tokens carry a per-user revocation salt so issued tokens invalidate immediately on revocation rather than at expiry. There is no "wait for the token to lapse" window after the account is closed.

Do AI agents and the MCP server respect the same security perimeter?

Yes — by construction. AI agents emit XDBL (the platform's XSD-described query grammar), not raw SQL ; the compiler emits engine-native SQL with row-level and column-level security injected per the user's runtime context. The agent does not connect to the database directly. The MCP server gates tool and resource access at the SPI level per caller role. The permission perimeter extends uniformly into autonomous agent interactions.

Talk to a security architect.

A scoping conversation about authentication, multi-tenancy, audit and compliance. Discovery call within 48 hours.