Enterprise-Grade Without Enterprise Pain: Security, Governance, and Trust

"Security is always excessive until it's not enough." — Robbie Sinclair

Reading time: 14 minutes Series: The Matih Platform Blog Series (7 of 8) Audience: CISOs, Compliance Officers, Platform Architects, Anyone who's ever stayed up the night before an audit

The 3 AM Phone Call Nobody Wants

It's 3 AM. Your phone buzzes. The message from your compliance team: "Auditors found that three business units can see each other's data. The SOC 2 report is due in 72 hours."

You trace the problem. Somebody added a new dashboard six months ago. The query behind it didn't include the tenant filter. Nobody caught it in code review because the filter was supposed to be automatic — except "automatic" meant "the developer remembers to add WHERE tenant_id = ?" to every query.

One missing clause. Six months of data leakage between business units. Seventy-two hours to explain it to auditors.

This is what happens when security is a convention instead of a structure. When isolation depends on developers remembering to add a WHERE clause. When classification is a spreadsheet that nobody updates. When the audit trail lives in six different systems that nobody can correlate.

Matih takes a different approach: security and governance are architectural decisions, not afterthoughts. They're enforced by the infrastructure, not by developer discipline. They're structural, not procedural.

Multi-Tenant Isolation: You Can't See What Doesn't Exist

The foundation of enterprise trust is isolation. Your data, your queries, your models, your dashboards — nobody else can see them, touch them, or be affected by them.

Matih implements isolation at four independent layers, each reinforcing the others:

The multi-tenancy architecture: each tenant gets an isolated Kubernetes namespace with its own Data Plane services, database schema, network policies, and resource quotas. The Control Plane manages tenant lifecycle while never touching tenant data.

Layer 1: Kubernetes Namespace Isolation

Each tenant gets its own Kubernetes namespace: matih-data-plane-{tenant-slug}. That namespace contains the tenant's services, secrets, configuration, and nothing else.

Kubernetes NetworkPolicies enforce a default-deny posture — pods in one tenant's namespace cannot reach pods in another's. This isn't application logic. It's infrastructure-level enforcement. Even if a bug in the application code tried to call a cross-tenant service, the network layer would block it.

Resource quotas guarantee that one tenant's workloads can't starve another's. CPU limits, memory limits, and pod count limits are set per namespace. A runaway query in Tenant A doesn't slow down Tenant B's dashboards.

Layer 2: Database Schema Isolation

Within PostgreSQL, each tenant gets their own database schema: tenant_{uuid}. Queries execute within the tenant's schema using SET search_path. Row-Level Security (RLS) policies provide defense-in-depth — even if a query somehow escaped schema boundaries, the database would filter results by tenant_id.

For enterprise-tier tenants with stricter requirements, dedicated database instances provide complete physical isolation.

Layer 3: Data Path Isolation

Cache keys are prefixed with the tenant ID. Message queues carry tenant context. Object storage uses namespace-level isolation. At no point in the data path can one tenant's data intermingle with another's.

Layer 4: JWT Tenant Claims

Every API request carries a JWT token with a tid (tenant ID) claim. Every service validates this claim. Every database query filters by it. The tenant context propagates automatically through the entire call stack — developers don't add WHERE clauses manually; the infrastructure does it for them.

Defense in depth means any single layer can fail without compromising isolation. The namespace blocks network access. The schema restricts database scope. RLS filters rows. JWT claims validate identity. All four must fail simultaneously for a cross-tenant data leak — and that's by design, not by accident.

Authentication: Proving Who You Are

Identity is the first gate. Matih implements multiple authentication mechanisms, each appropriate for different contexts:

JWT Tokens (RS256) — The primary authentication mechanism. Access tokens (15-minute lifetime, memory-only) carry user identity, tenant, role, and permissions. Refresh tokens (24-hour lifetime, HttpOnly cookies) enable session continuity without re-authentication. Asymmetric signing (RS256) means tokens can be verified by any service without sharing the signing key.

Multi-Factor Authentication — TOTP via authenticator apps (Google Authenticator, Authy), SMS codes with 5-minute validity and three-attempt limits, and backup recovery codes. MFA is configurable per tenant — required for all users, required for admin roles only, or optional.

API Keys — For programmatic access (CI/CD pipelines, SDK integrations, automation). Keys carry scoped permissions, configurable expiration (up to one year), and are prefixed (matih_sk_live_*) for easy identification in logs.

Account Security — Password requirements enforce complexity (uppercase, lowercase, digit, special character, 8-72 characters). Password history prevents reusing the last 5 passwords. Progressive lockout escalates from 5-minute to 15-minute to admin-required unlock after repeated failures.

Authorization: Controlling What You Can Do

Authentication proves identity. Authorization controls access. Matih implements a layered authorization model that scales from simple role-based access to fine-grained attribute-based policies:

Role-Based Access Control (RBAC)

Five predefined roles cover the most common organizational patterns:

Permissions follow a resource:action format (query:execute, dashboard:write, model:deploy) with wildcard support. Roles are assignable per tenant, so a user can be an Admin in one business unit and a Viewer in another.

Row-Level Security

Beyond roles, PostgreSQL RLS policies automatically filter data by tenant. This is the safety net that catches everything else — even if application code misses a filter, the database enforces it.

Resource-Level Access Control

Individual resources (dashboards, queries, models) support granular sharing with configurable visibility levels: PRIVATE (creator only), TEAM (shared with a group), ORGANIZATION (all tenant users), or PUBLIC. Each share grant specifies a permission level: VIEW, EDIT, or MANAGE.

Data Classification: Know What You're Protecting

You can't protect what you haven't classified. Matih's Governance Service automatically discovers and classifies sensitive data across all cataloged sources:

Sensitivity Labels

Every column in every table gets a classification:

Automatic PII Detection

The platform scans for three categories of personally identifiable information:

• Direct PII — Names, email addresses, social security numbers, phone numbers. Detected via pattern matching and NLP. Tagged for encryption, access logging, and dynamic masking.
• Quasi-PII — Age, ZIP code, gender, job title. Individually harmless, but combinable for re-identification. Tagged for access control and aggregation requirements.
• Derived PII — Behavioral scores, credit ratings, churn probabilities. Not directly identifying, but can reveal personal attributes. Tagged for lineage tracking and review.

Dynamic Data Masking

When a user doesn't have clearance to see raw sensitive data, masking rules apply at query time — not by modifying the data, but by transforming it in the result set:

• Full masking: john.doe@company.com → ****
• Partial masking: john.doe@company.com → j***@***.com
• Hash masking: john.doe@company.com → a1b2c3d4e5f6 (consistent for joins)
• Custom patterns: SSN 123-45-6789 → ***-**-6789

Masking policies are defined per role and per classification. An Admin sees raw data. An Analyst sees partially masked data. A Viewer sees fully masked data. Same query, same table, different results — enforced by the platform, invisible to the user.

The Audit Trail: An Immutable Record of Everything

Every significant action across the entire platform — every login, every query, every configuration change, every data export — is captured in an immutable, tamper-evident audit trail.

What Gets Logged

Authentication events: Login success and failure (with IP and user agent), MFA challenges, token refresh, session expiry.

Authorization events: Role assignments, permission changes, access denied attempts — every time someone's access changes or someone tries to access something they shouldn't.

Data access events: Every query executed (with the SQL, rows returned, data sources touched, and duration), every dashboard viewed, every data export downloaded.

Administrative events: User creation and deactivation, tenant configuration changes, API key management, policy updates.

How It's Stored

Audit events flow through Kafka to PostgreSQL, partitioned by month for query performance. Retention is configurable per category — authentication events might retain for 90 days, while data access events retain for 3 years to satisfy compliance requirements.

The storage is append-only. Events cannot be modified or deleted (even by administrators) within the retention window. This is the foundation that SOC 2 auditors verify — and because it's structural rather than procedural, the verification is straightforward.

Compliance-Ready Reporting

Pre-built audit reports cover the questions auditors always ask:

• Access summary: Who accessed what data, when, and from where?
• Admin actions: What administrative changes were made, by whom, and what was the business justification?
• Failed access attempts: Where are the patterns that suggest unauthorized access attempts?
• Data export log: What data left the platform, in what format, and who authorized it?

Reports export to CSV, JSON, or Parquet. Full-text search across the audit trail means finding "all queries by user X that touched table Y in the last 90 days" takes seconds, not weeks of manual archaeology.

Encryption: Protecting Data at Every Stage

In Transit

All communication — client to gateway, service to service, service to database — is encrypted with TLS 1.3 (minimum TLS 1.2). Internal service-to-service communication uses mutual TLS (mTLS), where both sides verify each other's identity. HTTP Strict Transport Security (HSTS) ensures clients never accidentally downgrade to unencrypted connections.

At Rest

All stored data is encrypted with AES-256-GCM. Database encryption is transparent via cloud KMS integration. Object storage uses server-side encryption. Backups use separate encryption keys from primary data — so compromising one doesn't compromise the other.

Key Management

Encryption keys follow a hierarchy: a master key (HSM-backed, never exported) generates per-tenant Data Encryption Keys (DEKs). Keys rotate quarterly with zero-downtime re-encryption. Each tenant gets their own DEK — so even in a shared infrastructure model, tenant data is cryptographically separated.

Tenant Provisioning: Security from the First Second

When a new tenant joins the platform, the provisioning pipeline executes a multi-step automated process that creates their entire isolated environment:

1. Namespace creation — Kubernetes namespace with network policies and resource quotas
2. Database provisioning — Tenant schema with RLS policies and encrypted credentials
3. Service deployment — Data Plane services configured for the tenant's tier
4. Secret management — Credentials generated and stored in the vault, never exposed
5. Monitoring setup — Prometheus metrics, Grafana dashboards, alerting rules
6. Security validation — Automated checks that isolation is correctly enforced

Each step has error handling, rollback capabilities, and retry logic with exponential backoff. If step 4 fails, steps 1-3 are rolled back cleanly. The process is fully automated — no human intervention required, and no opportunity for manual configuration errors.

For enterprise-tier tenants with additional requirements, the provisioning pipeline extends to include dedicated compute resources, cloud infrastructure (via Terraform), and custom DNS configuration.

Compliance: Built In, Not Bolted On

Matih is designed to satisfy multiple compliance frameworks simultaneously, because the controls are architectural — not checklist items applied after the fact:

SOC 2 Type II

The platform addresses all five Trust Service Criteria:

• Security (Common Criteria): Access control, change management, incident response, vulnerability management
• Availability: 99.9% SLA target, failover capabilities, RTO 4 hours, RPO 1 hour
• Processing Integrity: Input validation, transaction logging, error handling
• Confidentiality: Encryption at rest and in transit, classification, access controls
• Privacy: Consent management, data subject rights, retention policies

HIPAA

For healthcare tenants, additional safeguards include mandatory MFA, 6-year audit retention, emergency break-glass access (with 2-hour expiration and full audit trail), HMAC-SHA256 integrity checksums on all records, and quarterly risk assessments following NIST SP 800-30.

GDPR

Data subject rights are supported natively: right to access (data export API), right to rectification (profile editing), right to erasure (account deletion with 30-day grace period), right to portability (JSON/CSV export), and right to object (contact preference management).

How Governance Integrates with Intelligence

Security and governance aren't isolated concerns in Matih. They're woven into every intelligent capability:

Governance + Semantic Layer: When the semantic layer defines a "Revenue" metric, it also inherits the classification of the underlying columns. If customer_email is CONFIDENTIAL, any metric that touches it carries that classification forward.

Governance + AI Agents: When an AI agent generates SQL, the governance layer applies masking rules before results are returned. The agent sees masked data — it literally cannot access raw PII unless the user has clearance. This means AI-generated insights are governance-compliant by default, not by careful prompt engineering.

Governance + Context Graph: The Context Graph tracks data lineage with governance metadata. "This dashboard shows CONFIDENTIAL data because it queries a table that contains email addresses" — the lineage doesn't just show data flow; it shows sensitivity flow.

Governance + Audit Trail: Every AI agent interaction is audited: what question was asked, what SQL was generated, what data was accessed, what masking was applied. If an auditor asks "Did the AI ever access restricted data?", the answer is a query, not an investigation.

"The price of freedom is eternal vigilance." — Thomas Jefferson

In data platforms, the price of trust is structural enforcement. Not guidelines. Not training. Not developer discipline. Architecture.

What This Means for Your Organization

If you're a CISO, this means security that's enforced by infrastructure, not policies. Multi-layer isolation, automatic PII detection, dynamic masking, and an immutable audit trail — all architectural, all auditable, all automatic.

If you're a compliance officer, this means audit preparation that takes hours instead of weeks. Pre-built compliance reports, queryable audit trails, and structural controls that satisfy SOC 2, HIPAA, and GDPR requirements simultaneously.

If you're a platform architect, this means multi-tenancy that scales without compromising isolation. Add 50 tenants, and each gets the same security posture as the first — because it's automated, not manual.

If you're a data engineer, this means governance that doesn't slow you down. Classification is automatic. Masking is transparent. Audit logging is structural. You build features; the platform handles compliance.

Coming Up Next

This is the penultimate post in the series. We've covered why Matih exists, how it's architected, how it understands data, how it remembers, how its agents work, how it processes data, and how it secures everything. In the final post, we pull back the curtain on how Matih itself was built.

• Blog 8: 34 Microservices, 960 Docs Pages, 1 AI Pair Programmer: Building Matih with Claude Code — What happens when you build an enterprise platform with an AI coding partner, and what we learned about the future of software development

About Matih: Matih is a cloud-agnostic, Kubernetes-native platform that unifies Data Engineering, Machine Learning, Artificial Intelligence, and Business Intelligence into a single system with a conversational interface at its core. Learn more at matih.ai (opens in a new tab).

Tags: #Security #Governance #MultiTenancy #Compliance #SOC2 #HIPAA #GDPR #DataProtection #Enterprise #ZeroTrust

Previous: From Bytes to Brilliance: Data Processing at Planetary Scale Next: 34 Microservices, 960 Docs Pages, 1 AI Pair Programmer: Building Matih with Claude Code