Security you can verify,
stated honestly

All data is partitioned by a tenant boundary. Row-level tenant scoping is attached across every entity, so one tenant can never reach another tenant’s data.

• Row-level isolation

  A tenant-ID filter is enforced on every persistent entity, so queries only ever see the calling tenant’s rows.

• Boundary bypass blocked

  Disabling the tenant filter is only possible through an explicit, audited path; the default is always isolated (deny-by-default).

Data at rest is protected with AES-256, data in transit with TLS. Backups and export archives are sealed with customer-managed keys (SSE-CMK).

• AES-256 at rest

  Databases and storage are encrypted at rest with AES-256.

• TLS in transit

  All network traffic is TLS-encrypted, including internal service-to-service communication.

• SSE-CMK backups

  Backups and data-export archives are sealed with customer-managed keys, keeping key control with the customer.

Every model call routes through one audited AI Gateway, with no direct LLM calls in application code. Decisions are recorded in an immutable trail, and per-tenant keys (BYOK), PII redaction and an EU AI Act / OWASP-LLM posture underpin governance.

• Single audited AI Gateway

  One entry point for every AI call—routing, fallback, metering and streaming pass through one door, with zero direct LLM calls.

• Immutable decision trail

  Autonomous-agent decisions and tool calls are recorded in a tamper-evident trail for audit.

• Per-tenant keys (BYOK)

  Tenants can bring their own model keys, protected by envelope encryption.

• Guardrails · PII redaction

  PII redaction and an EU AI Act / OWASP-LLM posture act as guardrails and continue to mature.

The dev environment runs in Azure Korea Central. Region choice is supported for customers with residency requirements.

• Azure Korea Central

  Data and compute for the current dev environment stay within the Korea Central region.

• Region choice

  Deployment region can be chosen to meet regulatory and residency needs; exact scope is agreed in a sales/security review.

Every action is attributed to its actor. People, AI agents, systems and schedulers are all identified as actors, so who changed what and when is recorded immutably.

• Actor attribution

  The actor behind every create/update/delete is recorded by actor ID—covering AI, systems and schedulers, not just people.

• Immutable records

  Audit columns and trails are preserved immutably, enabling after-the-fact reconstruction.

Sensitive operations enforce maker-checker approval gates at the code level. Without passing the gate, the operation fails closed.

• Maker-checker

  Maker and checker are separated, so a sensitive change cannot finalize without independent approval.

• Fail-closed

  If an approval requirement is unmet, the default behavior is to block—and the approval record is persisted.

Personal data is handled with a PIPA / GDPR posture. Data-subject requests (DSR), PII retention/erasure and the sub-processor list are described in the privacy policy.

• PIPA · GDPR

  Personal-data processing, retention and erasure controls operate against PIPA and GDPR.

• Data-subject requests (DSR)

  DSR handling carries an SLA and escalation, and PII erasure is recorded auditably.

• Sub-processor list

  The sub-processor list is published in the privacy policy.

Stated honestly—SOC 2 and ISO 27001 are a posture in progress / planned, not certifications we hold. The platform is designed toward these controls, but we do not imply we are certified.

• SOC 2

  In progress — control design targets the SOC 2 trust-services criteria, but it is not a certification we currently hold.

• ISO 27001

  Planned — designed toward an information-security management system, but it is not a certification we currently hold.

• Request documentation

  Control-mapping and posture documentation for a security review can be requested through a sales/security review.