Built secure by architecture,
not by policy.

Per-user Firecracker microVMs. Every Mr.Chief user is allocated a dedicated OpenClaw instance running inside a Firecracker microVM on Fly.io. Firecracker is the same VMM technology used by AWS Lambda and Fargate. Each VM has:

• Its own isolated Linux kernel
• Its own filesystem and memory space
• Its own process namespace — no shared process table with other users
• Its own network interface on Fly's private 6PN network

No shared containers. Unlike multi-tenant SaaS platforms that run multiple user workloads inside the same container or serverless function, Mr.Chief provisions a separate VM per user. A vulnerability in one user's workload cannot affect another user's VM.

Network segmentation. Communication between the coordinator (Django backend) and a user's VM travels exclusively over Fly.io's private 6PN (IPv6 private network). VMs are not exposed on the public internet. Each VM-to-coordinator callback is authenticated with a per-machine token that is rotated on each VM start.

Fly.io infrastructure. Fly.io operates data centres in the European Union (Amsterdam, Frankfurt, Warsaw). All Mr.Chief VMs are deployed exclusively in EU regions. Fly.io's physical security, hardware lifecycle, and hypervisor-level isolation are governed by their SOC 2 Type II programme.

Credentials at rest — Fernet (AES-256-CBC + HMAC-SHA256).

All user-supplied API keys, OAuth tokens, and secrets (collectively "credentials") are encrypted before being written to the database using the Fernet symmetric encryption scheme. Fernet provides:

• AES-256 in CBC mode for confidentiality
• HMAC-SHA256 for authenticated encryption (integrity + tamper detection)
• A random 128-bit IV per message
• A timestamp to support key rotation and token expiry

The encryption key is stored as an environment secret on Fly.io, separate from the application database. Plaintext credentials are never written to logs, never stored in application state beyond the scope of the encrypting function call, and never returned to the frontend after initial submission.

Data in transit — TLS 1.2+.

All data in transit between clients and Mr.Chief infrastructure is encrypted using TLS 1.2 or higher. Fly.io terminates TLS at the edge. Internal VM-to-coordinator traffic travels over Fly's encrypted 6PN private network.

Database encryption.

PostgreSQL storage volumes on Fly.io are encrypted at rest using AES-256 (managed by Fly.io at the storage layer). This is in addition to the application-layer Fernet encryption applied to credential fields.

Key management.

Encryption keys are stored as Fly.io secrets (encrypted in Fly's secret store, injected as environment variables at runtime). Key rotation procedures are documented internally and can be initiated without service downtime via key rotation tooling.

Tenant isolation at the query level.

The Mr.Chief coordinator enforces tenant isolation at the database query layer via a custom Django manager (TenantManager). Any query that attempts to access data without first scoping to a specific user identity raises a TenantIsolationError at evaluation time. This prevents accidental cross-tenant data leakage at the application level.

Session management.

User sessions are activity-based and stored in Redis with a 24-hour TTL that is refreshed on every authenticated request. Sessions are invalidated on explicit logout. Session tokens are HTTP-only cookies (not accessible to JavaScript) and are flagged Secure (HTTPS-only) and SameSite=Lax.

Authentication.

Users authenticate via email and password. Passwords are hashed using Django's default PBKDF2-SHA256 algorithm (100,000+ iterations). Mr.Chief supports SSO via OAuth 2.0 where configured. All authentication events are logged.

Staff access.

Pyratz Labs staff have access to the infrastructure layer (Fly.io, database) for operational purposes. All staff access to production infrastructure is logged. Staff do not have routine access to user credentials (which are encrypted and require the per-user encryption key to decrypt). Access to user data for support purposes requires explicit user consent or a lawful basis.

VM authentication.

Each OpenClaw VM is issued a per-machine token at provisioning time. This token is used to authenticate callbacks from the VM to the coordinator. Tokens are stored in the coordinator database (hashed) and in the VM's environment. Tokens are rotated on VM restart.

Every action taken by an AI agent on behalf of a user is logged with:

• Timestamp (UTC, millisecond precision)
• Agent identity (name, role, version)
• Tool or action invoked
• Input parameters (sanitised — credentials are never logged)
• Outcome (success, failure, error code)
• User identity

Audit logs are stored in the coordinator database and are visible to the account holder via Mission Control. Logs are retained for the duration of the account plus 30 days following account deletion, after which they are purged.

Infrastructure-level logs (Fly.io application logs, HTTP access logs) are retained for 7 days. These logs do not contain user credential values.

Logs cannot be deleted or modified by users. Pyratz Labs staff access to logs is itself logged for accountability.

Data controller. Pyratz Labs SAS is the data controller for all personal data processed through Mr.Chief. We are subject to the General Data Protection Regulation (EU) 2016/679 and the French Data Protection Act (Loi Informatique et Libertés).

EU-only processing. All Mr.Chief infrastructure (application servers, databases, VMs, object storage) is located in EU Fly.io regions (Amsterdam, Frankfurt, Warsaw). We do not transfer personal data to third countries outside the EEA except where Standard Contractual Clauses (SCCs) are in place with specific sub-processors (see our Privacy Policy for the full sub-processor list).

Your AI models, your keys. Mr.Chief operates a Bring-Your-Own-Key (BYOK) model. When you provide your own API keys for AI models (Anthropic, OpenAI, Mistral, xAI), your requests are sent directly from your dedicated VM to those providers. Mr.Chief does not proxy or store AI model responses. When you use Mr.Chief's built-in model access, requests are processed under our agreements with those providers, which include appropriate data protection terms.

Data subject rights. You can exercise your GDPR rights (access, rectification, erasure, portability, restriction, objection) at any time by contacting privacy@misterchief.ai. Account deletion triggers an irreversible purge of your data within 30 days. See our privacy@misterchief.ai. Account deletion triggers an irreversible purge of your data within 30 days. See our Privacy Policy for complete GDPR information.

We engage the following infrastructure and service sub-processors. Each has been assessed for security and data protection compliance:

AI model sub-processors (Mistral, Anthropic, OpenAI, xAI) only process data when you have explicitly configured them as your model provider. If you use BYOK, requests flow directly from your VM to the provider under your own agreement.

Dependency scanning.

Backend Python dependencies are scanned for known CVEs using automated tooling integrated into our CI/CD pipeline. Frontend JavaScript dependencies are scanned with pnpm audit. Critical and high-severity vulnerabilities are remediated within 72 hours of disclosure.

Static analysis.

Code is analysed with Ruff (Python linting including security rules) and TypeScript strict mode on every pull request. Security-relevant patterns (SQL injection vectors, unescaped outputs, insecure deserialization) are reviewed as part of the standard code review process.

Penetration testing.

Mr.Chief undergoes periodic third-party penetration testing. Results are addressed under our vulnerability remediation SLAs. Material findings are disclosed to affected users where applicable.

Patch management.

OS-level patches for Firecracker microVMs are applied by Fly.io as part of their managed infrastructure. Application-layer patches are deployed via our CI/CD pipeline with zero-downtime rolling deployments.

We welcome security research and responsible disclosure. If you have discovered a potential vulnerability in Mr.Chief, please contact us at:

Scope. In-scope: mrchief.ai, api.mrchief.ai, and associated sub-domains. Out of scope: denial-of-service attacks, social engineering, physical security, third-party sub-processors.

Safe harbour. We will not pursue legal action against researchers who discover and report security issues in good faith, provided they do not access or modify other users' data, do not perform denial-of-service attacks, and disclose privately before public disclosure.

Detection and triage. Security events are detected via application logs, infrastructure alerts, and anomaly detection. The on-call engineer is notified immediately for P0/P1 incidents.

GDPR notification obligations. In the event of a personal data breach that is likely to result in a risk to the rights and freedoms of natural persons, we will:

• Notify the CNIL (French supervisory authority) within 72 hours of becoming aware (Art. 33 GDPR)
• Notify affected data subjects without undue delay where the breach is likely to result in a high risk (Art. 34 GDPR)
• Document the breach, its effects, and the remedial action taken

Post-incident review. All P0/P1 incidents are subject to a written post-mortem with root cause analysis and preventive action items, published internally and summarised on our status page where material.

Staff training. All Pyratz Labs employees and contractors with access to production systems receive security awareness training at onboarding and annually thereafter.

Access management. Access to production systems follows the principle of least privilege. Access is granted on a need-to-know basis, reviewed quarterly, and revoked immediately on offboarding. Multi-factor authentication is required for all production access.

Physical security. Pyratz Labs does not operate its own data centres. Physical security for server hardware is managed by Fly.io under their SOC 2 programme.

Supplier assessment. Third-party suppliers with access to personal data are assessed for security and data protection compliance before engagement and periodically reviewed thereafter. Data Processing Agreements (DPAs) are in place with all sub-processors.

Mr.Chief is currently in its early commercial phase. We are committed to the following compliance roadmap: