OpenClaw Security Model, Data Residency, SOC 2 and ISO 27001

The hardest conversation in any enterprise AI agent rollout is not the model choice or the developer experience — it is the security review. CISOs and DPOs ask precise questions: where is data stored, how is it encrypted, who can access it, what evidence proves it. This article is OpenClaw's answers, in the form a security or compliance team can use directly during a vendor review.

We cover OpenClaw's security architecture, data residency options, audit and evidence model, and fitness against SOC 2, ISO 27001, GDPR, HIPAA, and adjacent frameworks. The article reflects ECOSIRE's experience deploying OpenClaw for clients in fintech, healthcare, government, and other regulated industries through 2026.

Key Takeaways

• OpenClaw separates the data plane (your runtime, your data) from the control plane (Marketplace, OpenClaw Cloud control surfaces) — self-host means your data never leaves your infrastructure.
• Encryption at rest (AES-256) and in transit (TLS 1.3) are defaults; bring-your-own-KMS is supported for envelope encryption.
• Audit logs are cryptographically chained and tamper-evident — every skill call, tool call, memory write captured.
• Data residency: choose your region for OpenClaw Cloud (US, EU, UK, AP) or self-host anywhere including air-gapped on-prem.
• SOC 2 Type II and ISO 27001 certifications cover OpenClaw Cloud; self-hosted inherits your environment's certifications.
• GDPR fitness includes data minimization, right to erasure, DPA template, and EU-region OpenClaw Cloud.
• HIPAA fitness available for healthcare clients with a BAA from ECOSIRE on Cloud Plus tier; self-hosted with HIPAA-aligned controls also supported.
• Skill code from the Marketplace runs in your runtime — sandbox untrusted Skills, audit Verified Skills, pin versions.

---

Threat Model

What we protect against:

1. Tenant data leakage — one tenant's data appearing to another.
2. Credential theft — secrets exfiltrated via prompt injection or compromised dependencies.
3. Audit log tampering — bad actor altering history to hide actions.
4. Untrusted skill code — malicious or buggy Marketplace Skill exfiltrating data.
5. LLM provider data retention — sensitive prompts retained by external models.
6. Insider misuse — admin access used for unauthorized purposes.
7. Network-level attacks — MITM, replay, packet capture.

What we do NOT solve:

• Application-layer prompt injection that follows your business logic into legitimate tool calls. (Mitigations exist; perfect prevention is research-grade.)
• Compromise of underlying cloud infrastructure (your AWS/GCP/Azure account security).
• Compromise of the LLM provider itself.

The architecture below addresses 1-7 with documented controls.

Architecture: Data Plane vs Control Plane

OpenClaw splits responsibilities clearly:

Data plane (your responsibility, runs in your environment for self-host; in your chosen region for Cloud):

• Runtime processes that execute agents.
• Skills code that runs against your APIs.
• Audit log storage.
• Memory storage.
• Secrets (via your secret manager).

Control plane (OpenClaw managed, only when using Cloud):

• Web console, telemetry collection, billing, scaling controls.
• Marketplace registry and Skill download.
• Per-tenant configuration and version management.

For self-hosted OpenClaw, the control plane is also self-hosted (Docker Compose / Helm). No connection to OpenClaw infrastructure is required.

For OpenClaw Cloud, the control plane is OpenClaw-managed; the data plane runs in your chosen region with your data isolated per tenant.

This split matters because regulated customers can run the data plane in their own VPC, with their own KMS keys, while still using OpenClaw Cloud's control plane for management. Or, for air-gapped environments, self-host both.

Encryption

At rest

• Audit logs, memory storage, and secrets: AES-256 at the storage layer.
• Database encryption via Postgres pgcrypto or AWS RDS / Azure SQL / GCP Cloud SQL native encryption.
• Object storage (S3 / GCS / Azure Blob) with provider-side encryption at minimum, customer-managed KMS keys for sensitive workloads.

In transit

• TLS 1.3 between runtime, control plane, and Skills calling external APIs.
• mTLS between OpenClaw runtime processes for self-hosted multi-node deployments.

KMS / envelope encryption

For per-tenant encryption keys (often required for highly regulated workloads), OpenClaw supports envelope encryption with:

• AWS KMS
• Azure Key Vault
• GCP Cloud KMS
• HashiCorp Vault Transit

# Runtime config
encryption:
  envelope:
    kms_provider: aws
    key_alias: alias/openclaw-tenant-{tenant_id}
    key_rotation_days: 90

Each tenant's data is encrypted with a tenant-specific key under your KMS. Compromise of one tenant's key does not expose others.

Secrets Management

Secrets must NEVER be in code, configuration, or logs. OpenClaw enforces this with a typed secrets API:

from openclaw.secrets import get_secret_for_tenant

@skill(name="erp.odoo.lookup_partner")
def lookup_partner(name: str) -> dict:
    creds = get_secret_for_tenant(context.tenant_id, "odoo")
    odoo = OdooClient(url=creds["url"], db=creds["db"], user=creds["user"], password=creds["password"])
    return odoo.search_partners(name)

Backends:

• AWS Secrets Manager
• Azure Key Vault
• GCP Secret Manager
• HashiCorp Vault
• Kubernetes Secrets (with RBAC + sealed-secrets recommended)

Audit logs record secret access events (which tenant, which secret, by whom) but never the secret value.

Rotation: secrets can be rotated at any time. Skills re-fetch on each call (with a configurable in-process cache TTL of typically 60-300 seconds for performance).

Audit Logs and Tamper Evidence

Every meaningful action is recorded:

• Agent run start, end, status.
• Each Skill call with arguments and result (PII redaction configurable).
• Each tool call to external services.
• Each memory read/write.
• Each LLM invocation with prompt and response token counts (full text optional).
• Configuration changes, deployments, rotations.

Audit entries form a hash chain — each entry includes a hash of the previous entry. Tampering with any past entry breaks the chain. The most recent hash is periodically signed and stored separately (S3 object lock, write-once storage) for non-repudiation.

For a SOC 2 audit, this gives you:

• Evidence that all production access is logged.
• Tamper-evidence that the log was not retroactively altered.
• Per-user attribution (who triggered what).
• Time-bounded queries ("show me everything that happened to tenant X between dates Y and Z").

OpenClaw Cloud Plus tier includes WORM (write-once-read-many) audit log archival to satisfy regulators that require it.

Tenant Isolation Controls

Multi-tenant deployments use defense in depth (also see our multi-tenant deployment architecture):

1. Logical: tenant_id stamped on every record, message, and operation.
2. Database: Postgres Row-Level Security policies.

ALTER TABLE audit_log ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON audit_log
    USING (tenant_id = current_setting('app.tenant_id'));

3. Network: namespace network policies in Kubernetes (Model 3 deployment).
4. Encryption: per-tenant KMS keys (envelope encryption).
5. Quotas: per-tenant CPU/RAM/token budgets prevent noisy-neighbor exfiltration via timing.

Penetration tests in our annual engagements specifically target tenant isolation — attempting to read another tenant's data via SQL injection, cache poisoning, side-channel timing, and privilege escalation.

Data Residency

OpenClaw Cloud regions (2026):

Choose your region at tenant creation. Data, audit logs, memory, and skill execution all stay in-region. Cross-region replication is opt-in (only for disaster recovery, with documented controls).

For self-hosted OpenClaw, you choose your data center — AWS, Azure, GCP, on-prem, air-gapped. The runtime has no outbound dependency on OpenClaw infrastructure.

LLM provider regions: Anthropic, OpenAI, Bedrock, and Azure OpenAI all offer region-specific endpoints. Configure per tenant:

tenants:
  eu-customer-acme:
    model_override:
      provider: anthropic
      endpoint: https://api.anthropic.eu
      region: eu

For maximum residency control, use a regional Bedrock or Azure OpenAI deployment that contractually keeps prompts and outputs in-region.

Compliance Certifications

SOC 2 Type II

OpenClaw Cloud is SOC 2 Type II certified for the Security, Availability, and Confidentiality trust service criteria. Annual report available under NDA.

Self-hosted OpenClaw inherits your environment's controls — your existing SOC 2 (if applicable) covers it.

ISO 27001

OpenClaw Cloud is ISO 27001:2022 certified. Statement of Applicability available under NDA.

HIPAA

For healthcare workloads, OpenClaw Cloud Plus tier includes:

• Business Associate Agreement (BAA) from ECOSIRE.
• HIPAA-eligible AWS regions (US-only).
• Mandatory encryption at rest and in transit.
• Audit logs retained per HIPAA timelines.
• Limited access controls and user provisioning workflows.

Self-hosted OpenClaw can run HIPAA-compliant when you operate it in a HIPAA-aligned environment with appropriate controls (encryption, audit, access reviews). We provide an implementation guide.

GDPR / UK-GDPR

OpenClaw Cloud EU and UK regions are designed for GDPR/UK-GDPR fitness:

• Data Processing Agreement (DPA) standard via ECOSIRE.
• EU-only data residency.
• Data subject rights workflows: access, rectification, erasure, portability.
• Sub-processor list published and updated.
• Standard Contractual Clauses (SCC) for any required transfers.

Self-hosted OpenClaw makes you the controller; we provide guidance and templates.

FedRAMP

FedRAMP Moderate authorization is on the 2026 roadmap (target Q4). Until then, US Federal customers with FedRAMP requirements should self-host on FedRAMP-authorized infrastructure (GovCloud, Azure Government).

Other frameworks

OpenClaw maps to:

• NIST CSF 2.0
• NIST AI Risk Management Framework
• DORA (financial sector EU regulation) — particularly the resilience and audit requirements.
• EU AI Act — risk classification, technical documentation, conformity assessment.

We publish a control mapping document for each framework available under NDA.

Skill Security

Skills from the Marketplace run in YOUR runtime with YOUR credentials. Treat them like any third-party code:

• Pin versions in openclaw.lock. Never auto-upgrade in production.
• Prefer Verified tier for production. Community Skills require code review.
• Sandbox risky skills. The runtime supports syscall-level sandboxing for Skills marked sandbox: true (network-restricted, filesystem-restricted, syscall-filtered).
• Audit dependencies. Skills' Python dependencies are scanned with pip-audit on publish. Re-scan on install.
• Restrict permissions. Skills declare permissions; runtime enforces. A Skill that declares only tool:salesforce cannot reach tool:database.

For Marketplace publishers:

• Code review by the OpenClaw team is required for Verified tier.
• Bandit + Semgrep static analysis runs on every publish.
• Dependency vulnerability scan against CVE databases.
• Signature verification on install.

Prompt Injection and Output Safety

Prompt injection is the hardest open problem. OpenClaw provides:

• PII redaction (built-in Skill compliance.pii-redact) — strip PII from prompts and outputs before sending/logging.
• Output content filters — pluggable classifiers that flag dangerous outputs.
• Tool call validation — every Skill call is validated against its declared schema; the Skill cannot do something not declared in its manifest.
• Allowlists — restrict skills/tools an agent can call to a closed set.

Mitigation, not elimination. Application teams must still review their prompt design for injection-resistant patterns. We document our hardening guide for high-stakes agents (financial transactions, customer data updates, etc.).

LLM Provider Data Retention

Different providers have different policies:

For sensitive workloads, route through Bedrock or Azure OpenAI to inherit zero-retention by default. OpenClaw routes per agent or per tenant.

Comparison Table: Compliance Posture

Frequently Asked Questions

Is OpenClaw Cloud or self-hosted better for compliance?

For straightforward SOC 2 / ISO 27001 alignment, Cloud is faster — you inherit our certifications. For sovereignty, on-prem, or air-gapped requirements, self-hosted is the right answer. Many regulated clients run a hybrid: Cloud for non-sensitive workloads, self-hosted for sensitive data.

Can OpenClaw send data to third-party LLM providers?

Yes — Anthropic, OpenAI, Bedrock, Azure OpenAI, etc. Configure per tenant or per agent. For zero-retention guarantees, Bedrock or Azure OpenAI with appropriate contracts is the answer.

How do you handle data subject deletion requests?

For Cloud customers, our deletion workflow purges audit logs, memory, and secrets within 30 days. For self-hosted, we provide a openclaw tenant offboard --delete-all CLI command and document the manual steps for any storage backends you've configured.

Where can I get a SOC 2 report or HIPAA BAA?

Contact the ECOSIRE security team via our OpenClaw service page. Reports are NDA-gated; BAAs are issued on Cloud Plus tier or as part of self-hosted advisory engagements.

Where can I get help meeting our specific compliance requirements?

ECOSIRE delivers compliance-aligned OpenClaw deployments as part of our implementation service. We have shipped HIPAA, GDPR, SOC 2, and DORA-aligned setups. For multi-tenant security patterns specifically, see our multi-tenant deployment architecture guide. Browse OpenClaw products for compliance-ready agent templates including PII redaction and audit packs.

---

Security and compliance are how AI projects either stay or get cancelled in regulated environments. OpenClaw's architecture — clear data/control plane split, hash-chained audit, per-tenant encryption, multiple deployment models, and a documented compliance posture — gives security teams the answers they need on the first review. Bring this article and the linked control mapping to your next CISO meeting; it is designed for that conversation.