09Trust · Security
How we secure your data — and what we're working on.
Jubi's security posture as of today, control by control. Covers infrastructure, identity, application security, operations, personnel, vendors, business continuity, and incident response. Each control is marked active, in-build, or roadmap — we don't list anything we don't actually do.
What you can rely on today
- Identity bound to every request. SSO via the customer's IdP. The AI cannot see what the user cannot see.
- Tenant isolation. Logical isolation across storage and inference; physical isolation available in VPC-isolated and on-prem deployments.
- Encryption everywhere. TLS 1.2+ in transit; AES-256 at rest.
- End-to-end audit log. Guardian records the request, the policy decision, the data accessed, and the response. Replayable.
- No training on customer data. Provider enterprise endpoints with training and retention disabled.
- Read-only AI access by default. Write paths (Metabase dashboards, Atlas semantic layer) are explicit and gated.
Activein production today
In buildpartial; landing this quarter
Roadmapscoped, not yet started
01Architecture & infrastructure
Where the platform runs, how it's segmented, and how customer data is isolated from other tenants.
Hosting
Active
Pilot deployments run on a single hyperscaler region, selected at engagement start (typically Singapore for APAC customers). The hyperscaler is listed as a subprocessor in the DPA, Annex C.
Network isolation
Active
Application services run in a private subnet. Public ingress passes through a CDN/WAF (Cloudflare) that terminates TLS, applies rate limits, and forwards to load balancers. No public database endpoints.
Tenant isolation
Active
Logical isolation by default: each tenant's data lives under a tenant-scoped schema with row-level enforcement. Inference contexts are tenant-scoped — prompts and responses for one tenant cannot be reached from another tenant's request path.
VPC-isolated deployment
In build
Customer-dedicated VPC for select enterprise engagements. Includes private connectivity (VPC peering or PrivateLink) to the customer's warehouse and IdP. Available in pilot for design partners; GA Q3.
On-prem deployment
Roadmap
Air-gapped or customer-cloud-hosted deployment for highly-regulated workloads. Scoped for selected enterprise customers. Quoted per engagement.
Multi-region failover
Roadmap
Single-region today; cross-region active-passive failover is roadmap. RPO/RTO targets at GA documented in the SLA.
02Identity & access
How Jubi authenticates users, applies their permissions, and prevents the AI from seeing more than the user can.
Single sign-on (SSO)
Active
Customers sign in via their identity provider over SAML 2.0 or OIDC. Tested with Authentik, Okta, Microsoft Entra ID (Azure AD), and Google Workspace. Other SAML/OIDC IdPs work; we test on request.
Multi-factor authentication
Active
MFA is delegated to the customer's IdP. Jubi does not maintain a separate password store for customer users — there's nothing for an attacker to phish into.
Role-based access
Active
SSO group memberships flow through to Jubi roles and Metabase permissions. Atlas permission semantics (field-level visibility, masking) are enforced at Guardian on every request. See the security model.
Service accounts & API keys
In build
Workspace-scoped API keys for headless playbooks and integrations. Keys are tenant-bound, role-scoped, rotatable, and audit-logged like any other actor. GA next quarter.
Just-in-time support access
In build
Jubi staff cannot read into a customer tenant by default. Diagnostic access requires a time-bound, customer-approved JIT grant; every action is logged and surfaces in the customer audit log alongside customer activity.
Customer-managed encryption keys
Roadmap
CMEK with KMS integration for VPC-isolated and on-prem deployments. Scoped for GA Q4.
03Data protection
Encryption, classification, retention, and the AI-specific guarantees about training and tenant boundaries.
Encryption in transit
Active
TLS 1.2+ for all customer-facing traffic, with HSTS and modern cipher suites. Internal service-to-service traffic uses mTLS where supported by the runtime.
Encryption at rest
Active
AES-256 for all persisted customer data and audit logs (provider-managed keys today; CMEK on the roadmap). Database backups are encrypted with the same posture.
Field-level visibility
Active
Atlas defines field-level visibility (PII classes, masking rules). Guardian enforces them on every request — for retrieval, summarisation, and inference paths. The AI cannot return what the user is not permitted to see.
No training on customer data
Active
We use enterprise endpoints from our model providers (Anthropic, OpenAI) configured for no-training and no-retention beyond inference. We do not train or fine-tune our own models on customer data. Documented in the AI use & data policy.
Tenant boundary in inference
Active
Each inference call is constructed in a tenant-scoped context. Conversation history, attachments, and Atlas references are tenant-bound; cross-tenant leakage at the model layer is structurally prevented.
Data classification & minimisation
In build
Atlas tags fields by class (public / internal / confidential / PII). Inference paths filter by class and minimise data sent to the model — a question about sales counts does not need raw email addresses in the context.
Backups
Active
Regular full and incremental backups for the platform's own databases. Backups are encrypted at rest, retained per the engagement, and periodically tested for restorability. Specific cadences and retention windows are agreed in the engagement.
Data deletion
Active
On termination or written customer instruction, we return or delete customer data in accordance with the DPA. Backups containing the data age out of retention in the ordinary course; specific timelines are documented in the engagement.
04Application security
How we build the platform safely. Secure SDLC, dependency hygiene, testing.
Secure SDLC
Active
Mandatory peer review for every change. Branch protection on production branches. Threat modelling for new surfaces (e.g. API additions, integration partners).
Static analysis (SAST)
Active
Static analysis runs on pull requests. Findings are triaged and remediated based on severity; critical findings are addressed before deploy.
Software composition (SCA)
Active
Dependency scanning with CVE alerting. We generate a software bill of materials per release and patch promptly, prioritised by severity. Specific patch timelines are documented in the customer engagement where relevant.
Dynamic testing (DAST)
In build
Authenticated dynamic scans against staging on a regular cadence, with the goal of integrating into the CI pipeline.
Penetration testing
In build
Periodic third-party security testing scoped to the application surface and Guardian's policy enforcement. Test cadence and the most recent test summary are available on request under NDA. A coordinated vulnerability research programme is on the roadmap.
Vulnerability disclosure
Active
Public responsible-disclosure policy with safe harbour for good-faith research. Reports go to security@jubi.my.
Prompt-injection & AI abuse defence
Active
Guardian inspects inputs for known prompt-injection patterns and validates outputs against Atlas grounding. AI-specific evasion attempts (instruction-override, hidden text, indirect injection via tool outputs) are catalogued and tested. See the security model for per-gate behaviour and the AI policy for governance.
05Operational security
Day-to-day controls — logging, monitoring, anomaly detection, change management.
Audit logging (customer-facing)
Active
Every AI request, policy decision, data access, and response is logged in the tenant's audit trail. Replayable end to end. Exportable to a customer-side SIEM.
Platform logging & SIEM
In build
Centralised platform logs (auth, deploy, infrastructure changes) shipped to a SIEM with anomaly rules. Retained 12 months. Dashboards for sign-in anomalies, privilege changes, and unusual data egress.
Change management
Active
All production changes go through code review + automated tests + staged rollout. Deploys are tracked, attributable, and reversible. Emergency-change process documented internally.
Endpoint security
Active
Employee endpoints are MDM-managed with disk encryption, screen-lock policy, and EDR. Production access requires hardware-backed MFA and is restricted to a managed device.
Secrets management
Active
Production secrets live in a dedicated secret manager. No long-lived credentials in source. Rotation is automated where the underlying provider supports it.
Anomaly & abuse detection
In build
Per-tenant rate limits and behavioural baselines for unusual query volumes, jailbreak patterns, and exfiltration-shaped traffic. Alerts fire to on-call.
06Personnel security
Who can touch what, and what's in place to keep that contained.
Background checks
Active
Pre-employment background checks for all staff, calibrated to local law. Re-verification before granting production access.
Confidentiality & IP agreements
Active
Every employee, contractor, and intern signs confidentiality and IP-assignment agreements before the first day. NDAs flow through to vendors with access to non-public information.
Security awareness training
Active
Onboarding security training for all staff. Annual refresher. Engineering teams have additional content on secure coding, AI-specific abuse patterns, and incident response drills.
Least-privilege access
Active
Production access is role-scoped, time-bound, and reviewed quarterly. Customer-tenant access requires JIT grant; standing access to customer data is denied by default.
Onboarding & offboarding
Active
Account provisioning runs from a single source of truth (the IdP). Offboarding promptly revokes access on HR signal, and service-account audit confirms no orphaned credentials remain.
07Vendor management
Who else processes customer data on our behalf and how we hold them to a comparable standard.
Subprocessor list (public)
Active
Current subprocessors are listed at subprocessors.html. Material changes are notified to customer admins ≥ 30 days before they take effect.
Vendor security review
Active
Every new vendor with access to customer data passes a documented security review (SOC 2 or equivalent attestation, DPA in place, breach-notification clause). Reviews are repeated periodically.
Model providers (Anthropic, OpenAI)
Active
Used via enterprise endpoints with no-training and no-retention beyond inference. Their security postures (SOC 2 Type II, encryption, isolation) are documented and reviewed annually.
08Business continuity & disaster recovery
What happens when something breaks.
Backup cadence
Active
Full and incremental backups for stateful services on a regular cadence. Backup encryption keys are separated from service-account credentials. Engagement-specific cadences are agreed in writing.
Restore testing
In build
Periodic restore exercises against a staging environment, with documented runbooks. Larger-scale recovery exercises will be in scope at GA; cadence will be agreed per engagement.
RPO / RTO targets
In build
Operational RPO and RTO objectives are documented per engagement. Contractual SLA targets at GA will be set in the engagement-specific service level agreement; deployment scope (managed vs VPC-isolated vs on-prem) affects the achievable numbers.
Cross-region failover
Roadmap
Single-region today. Active-passive failover for the managed deployment is on the roadmap.
Tabletop exercises
In build
Periodic tabletop exercises covering likely incident classes (credential compromise, model-provider outage, data-exposure scenarios, ransomware against an internal system).
09Incident response
How we detect, contain, communicate, and learn.
On-call & triage
Active
Engineering on-call covers platform availability and security alerts. Extended-hours coverage for severity-1 events. Documented severity matrix and escalation tree; specific response targets are agreed in the engagement SLA.
Customer notification
Active
For a confirmed personal-data breach affecting customer data, we notify the customer's designated security contact without undue delay, in accordance with the DPA. The customer is responsible for keeping the designated contact current. For general incidents affecting availability, we communicate as soon as we have a clear picture of scope and impact.
Post-mortems
Active
Blameless post-mortems for severity-1 incidents, completed in a timely manner. Customer-affecting findings are summarised and shared with affected customers; a sanitised version is published internally for institutional learning.
Forensic readiness
In build
Tamper-evident logging for security-relevant events. Building toward independent log custody for forensic admissibility.
10Compliance & certifications
Where we are. Where we're going. No invented audits.
PDPA Malaysia (PDPA 2010, as amended)
Aligned
We operate in alignment with PDPA principles, including notice, consent, purpose limitation, security, and data subject rights. Designated PDPA contact: privacy@jubi.my. Customers remain responsible for their own PDPA obligations as data users.
GDPR (EU/EEA, UK)
Ready
DPA available with Standard Contractual Clauses and UK addendum where applicable. Sub-processing list, retention schedule, and data-subject-request workflow documented. An Article 27 representative will be appointed if and when Jubi targets EU/EEA markets at scale. Customers acting as controllers remain responsible for their direct GDPR obligations.
SOC 2 Type II
Roadmap
Audit firm engaged. Scoped for the Trust Services Criteria: Security, Availability, Confidentiality. Observation period and report timeline are subject to audit firm scheduling and our environment readiness; we will publish the report on this page when issued.
ISO 27001
Roadmap
Information Security Management System scoping is in progress. Stage 1 audit timing is subject to ISMS readiness and audit firm scheduling.
EU AI Act
Tracking
In its default configuration Jubi is general decision-support tooling. Whether a particular customer use case constitutes a high-risk AI system under Annex III, or otherwise falls within the EU AI Act's regulated categories, depends on the use case and the customer's deployment. The customer is responsible for assessing their use case and meeting any obligations as the deployer of the AI system. Our positioning and customer-facing transparency support are described in the AI use & data policy.
HIPAA, PCI DSS, FedRAMP
N/A
Not in scope today. We do not target US healthcare or card-holder workflows. We will revisit if and when we do.
11Customer security features
What you get out of the box, and what's available per deployment scope.
SSO (SAML / OIDC)
Active
Available on every deployment. No lower tier without SSO.
Audit log export
Active
Customer-controlled export of the tenant audit log to a SIEM (Splunk, Elastic, Datadog, custom S3 sink). Replayable end to end.
IP allowlisting
In build
Per-tenant network allowlist for the customer console and API. Available on VPC-isolated deployments first.
Data-residency choice
In build
Customer-selected hosting region at engagement start. In-region AI inference is on the AI-policy roadmap; default today is US-region provider endpoints.
Customer-managed keys (CMEK)
Roadmap
CMEK with customer KMS for VPC-isolated and on-prem deployments. Quoted per engagement.
Private connectivity
In build
VPC peering or PrivateLink to the customer's warehouse and IdP, available with VPC-isolated deployment.
12Documents & questionnaires
What you can request, and what we publish.
- Data processing agreement — public summary on this site; executable version on request.
- AI use & data policy — current posture, EU AI Act framing, Article 22 GDPR position.
- Security model — Mode 1 / Mode 2 pipelines, R1–R5 risk catches, audit coverage.
- Platform architecture — full reference for technical buyers.
- Responsible disclosure policy — for security researchers and customer-side red teams.
- Subprocessors list — current as of last update; subscribe via privacy@jubi.my for change notifications.
- Pen-test summary — available under NDA. Email security@jubi.my.
- Security questionnaires — we respond to CAIQ, SIG-Lite, and customer-supplied formats. Turnaround depends on questionnaire scope and current load; we will indicate timing on receipt.
Security: security@jubi.my · Privacy: privacy@jubi.my · Vulnerability reports: responsible-disclosure policy · security.txt
Disclaimer. This document is provided for informational purposes only. It is not legal advice and does not create a contract or extend warranties. Binding security commitments arise only from a signed engagement (Master Service Agreement, Data Processing Agreement, and any deployment-specific addenda) executed between the customer and Jubi's contracting entity. The controls described here reflect Jubi's current operational posture and may change as our environment evolves. Specific cadences, response times, and recovery objectives applicable to a given customer are set out in the engagement documents and supersede anything stated on this page.