Trust

Compliance built into the architecture.

SOC 2, HIPAA, GDPR, India DPDP, ISO 27001. Tenant isolation enforced at the database. Sovereign deployment that's air-gappable. Audit trail that satisfies tier-1 regulators.

Book a security review → See the platform →

Posture at a glance

SOC 2

Type II audit in progress

ISO 27001

Aligned

HIPAA

Eligible on Sovereign

GDPR

Compliant by design

India DPDP

2023 compliant

PCI-DSS

Recording compliant

The opening act

The prompt is never the fence.

Guardrails written into a system prompt are a request. Guardrails built into the platform are a constraint. Six of them are enforced on every interaction, and measured on every interaction.

Prompt-injection detection

PII redaction

Manipulation detection

Sector compliance modes

100% interaction audit

Human approval gates

The principle

Security is the architecture, not a feature

Most AI vendors talk about security as a feature. We treat it as the architecture. Every design decision in AIWRKR starts with three questions: where does the data live, who can access it, and how is access proven. If a feature can't answer those three questions cleanly, the feature doesn't ship.

This page is the deep dive on what that means in practice — for security teams, for compliance officers, for legal review, and for the auditors who will eventually assess your deployment.

Sovereignty

What sovereign deployment actually means

Sovereign deployment means three concrete things:

The AI inference plane runs on customer-controlled GPUs.

Not "in the customer's account on a hyperscaler" — on hardware the customer owns and physically controls. On GPU infrastructure in the customer's own data centres or colocation facilities, specified to the workload.

Customer voice, chat, and document data never leaves the customer's network perimeter.

No external LLM API calls. No third-party model providers. No telemetry data egress to vendor systems. The platform operates entirely within the customer's network.

The deployment is air-gappable.

The platform can run with zero external network connectivity — no internet, no vendor connectivity, no third-party services. Suitable for government, defence, and the most sensitive BFSI workloads.

How sovereignty is enforced

— Network-level isolation: separate VPCs, separate subnets, separate firewalls per tenant

— Application-level isolation: tenant ID enforced at every API boundary

— Database-level isolation: each tenant's data in physically separate database partitions with separate encryption keys

— Runtime isolation: AI inference workers run in tenant-dedicated containers with no cross-tenant data access

— Audit-level isolation: every data access is logged with tenant ID, user ID, timestamp, and purpose

What this enables

— BFSI deployment without regulatory review headaches

— Healthcare deployment with HIPAA compliance by construction

— Government deployment with FedRAMP-equivalent posture

— Defence deployment with full air-gap capability

Tenant isolation

Isolation enforced at the database

How we isolate

Most multi-tenant SaaS platforms isolate tenants at the application layer. The tenant ID is checked in code. If the code has a bug, tenants can theoretically see each other's data. This is the "shared database, separate schema" pattern.

We don't do that. Tenant isolation in AIWRKR is enforced at the database layer. Each tenant has its own physically separate database partition with its own encryption keys (customer-managed on Sovereign deployment). A code-layer bug cannot cause cross-tenant data leakage because the database itself doesn't permit cross-tenant queries.

The same principle applies to AI inference. Each tenant's inference workloads run in dedicated containers on dedicated GPUs (on Sovereign) or in dedicated GPU partitions (on Cloud). There is no inference-level data sharing between tenants.

What this proves

A leak between tenants would require simultaneous compromise of:

The database physical isolation

The encryption key management system

The container runtime isolation

The GPU partitioning layer

This is the same isolation model that hyperscaler cloud providers use to isolate their own customers from each other. We use the same standard, applied to AI workload isolation.

Audit

Audit trail · what we log

Every action taken by every AI Worker on every customer interaction is logged. The audit trail is immutable, timestamped, and queryable.

What's logged

Incoming voice or text payload (or hashed reference where regulatory rules require redaction)

Intent classified by the AI Worker

Tools invoked (system name, action name, parameters)

Responses received from tools

Outputs generated by the AI Worker

Escalations triggered (reason, threshold crossed, human routed to)

Worker version active during the interaction

Model identifier and version active during the interaction

Timestamps to millisecond precision on every event

Audit characteristics

Immutable — append-only ledger, no edits or deletes

Cryptographically chained — each entry references the hash of the prior entry

Tenant-isolated — auditors see only their tenant's data

Role-based access — different audit views for security, compliance, operations

Exportable — CSV, JSON, secure SFTP for regulator-grade exports

Retention-configurable — customer sets retention from 30 days to 7+ years per regulatory requirement

Compliance

Compliance certifications and alignment

Certification	Status	Scope
SOC 2 Type II	Audit in progress	Full platform
ISO 27001	Aligned · formal audit in progress	Full platform
HIPAA	Eligible on Sovereign deployment	US healthcare
GDPR	Compliant by design	EU customers and EU data subjects
India DPDP 2023	Compliant by design	Indian customers
PCI-DSS	Recording-level compliance (pause-resume)	Payment card capture
Colorado AI Act	Compliant by design	US Colorado-resident interactions
California AB-2013	Compliant by design	California-resident interactions
NY SHIELD	Compliant by design	New York data subject interactions
EU AI Act	Compliant by design (Risk class 2)	EU customers and EU data subjects

What "by design" means

Compliance "by design" means we built the architecture around the regulatory requirements. We didn't build the platform and then add a compliance reporting module. Concretely:

✓ Data subject rights (access, deletion, portability) are first-class API operations

✓ Consent management is enforced at the data ingestion layer

✓ Audit log retention is configurable per record type to match jurisdiction-specific rules

✓ Data residency is enforced architecturally (a Sovereign deployment cannot accidentally send data to another region)

✓ Right-to-explanation is supported via the audit trail (any AI decision can be traced)

Security

Security architecture detail

Encryption

—

In transit: TLS 1.3 for all external communication, SIPS/SRTP for voice media, mTLS for internal service-to-service

—

At rest: AES-256-GCM for all data at rest, customer-managed encryption keys on Sovereign deployments via your enterprise key-management system (HSM/KMS)

—

In use: Confidential computing on supported hardware (Intel TDX, AMD SEV-SNP, NVIDIA Confidential Computing) for the most sensitive workloads