Security architecture
You are handing us access to your company's operations. We take that seriously. Our team has spent decades running enterprise operations for Fortune 100 clients. We know what it means to be trusted with someone else's business. That responsibility shaped how we built CompanyClaw.
We designed the architecture around security from the start. Every decision, from database structure to API design to how your AI operator processes information, was made with the assumption that someone is trying to break in.
Most AI platforms talk about security in vague terms. "Enterprise-grade security." "Bank-level encryption." Those phrases mean nothing without specifics.
We are going to tell you exactly what we do, how we do it, and why. If a competitor publishes a more detailed security page than this one, we have failed.
Our security model has three principles:
Multiple independent layers. If one is bypassed, others still protect your data. Session-based auth, tenant-scoped data paths, infrastructure encryption, and rate limiting all operate independently.
Requests are authenticated and authorized independently. Customer-facing paths derive organization scope on the server after membership checks; system and admin jobs use separately named global access.
Your operator has access to the tools and integrations you configure, nothing more. Permissions are enforced per organization, per operator, and per user role. Admin functions are gated behind a separate authentication path.
Each layer operates independently. Compromising one does not weaken the others.
All databases run on AES-256 encrypted storage volumes managed by our hosting provider. Data is encrypted on disk at the infrastructure level.
Every connection uses TLS 1.2+. HTTPS is enforced, not just offered. No data travels in cleartext between your browser, our servers, or our databases.
Opaque session identifiers are stored in browser storage and sent in the Authorization header over TLS. Chat WebSocket URLs never carry session tokens; browser sockets use short-lived, purpose-bound tickets and recheck active organization membership. We support Google OAuth and email-based magic links. No passwords stored.
Authentication flows through Google or Microsoft, so MFA is handled by your identity provider. Magic links are email-possession-based. We never store or handle passwords.
Selected customer-facing operator, knowledge, integration, chat, account, and organization paths use a server-derived tenant-scoped Prisma client. It injects the organization scope and rejects conflicting organization IDs. Coverage is being expanded; explicitly named system and admin jobs remain separate paths.
API calls are restricted to authorized origins. Responses carry a hardened set of browser security headers. Cross-origin requests from unauthorized domains are rejected.
Authentication, chat, uploads, webhooks, and other key API surfaces use shared, per-IP rate limits. Brute-force and retry storms are throttled across portal tasks.
Customer-facing database operations use Prisma, and user-filtered raw reports use parameterized query fragments. Fixed administrative and migration SQL remains on separately authenticated system paths.
Portal and connected-channel conversations, knowledge imports, research sources, memory imports, and onboarding content pass through a pre-inference policy that normalizes and bounds input, marks untrusted content, and blocks high-risk patterns. This is a risk-reduction layer, not a guarantee that prompt injection is impossible.
You set the autonomy level during onboarding. Portal-originated action proposals are checked against that level, and decisions plus attempted execution are recorded in the durable audit trail.
Provisioned operator gateways are isolated by organization or primary operator. Sub-operators can intentionally share their parent operator's gateway, while tenant access controls keep customer data scoped.
Supported portal and connected-channel operator response paths buffer and scan complete output before delivery. When the gate finds a credential pattern or unsafe internal reference, it redacts the finding and records a redacted audit event before release.
Portal-originated action proposals are stored server-side, categorized by risk, and checked against the operator's autonomy level. Approval identifiers are opaque, tenant-bound, short-lived, and consumed once before execution. OpenClaw-internal tool dispatch remains a separate enforcement boundary.
Recoverable integration tokens and VPS environment values are encrypted with AES-256-GCM before database writes. Searchable identity, contact, and organization fields are not covered by this application-encryption layer; they rely on access controls and encrypted storage.
Native Microsoft Entra ID (Azure AD) authentication uses PKCE, signed ID-token validation, and an explicit tenant allowlist. Existing accounts are never linked from an OAuth email match; a pre-linked provider identity is required.
New short-lived MagicLink and organization-invitation capabilities are stored as SHA-256 digests and verified against those digests. Recoverable gateway and integration credentials use versioned AES-256-GCM because the service must decrypt them for outbound requests.
AI systems have attack surfaces that traditional software does not. Prompt injection, data exfiltration through model outputs, and unauthorized tool execution are real threats. We built specific defenses for each.
Covered portal, channel, knowledge, research, memory-import, and onboarding paths normalize and bound untrusted content before inference. High-risk patterns are blocked, and flagged, blocked, or truncated decisions are durably audited. Clean inputs may be sampled without a separate audit row. Prompt-injection defenses reduce risk but cannot eliminate it.
New skills go through a review process before they are available. Your operator cannot install arbitrary software or integrations. If your operator needs a capability that is not available, our engineering team reviews and provisions it through a controlled deployment pipeline.
You set the autonomy level during onboarding: ask before portal-originated actions, allow routine proposals, or use broader autonomy. Proposal decisions and execution attempts at this portal boundary are logged with timestamps and outcomes.
Your operator can use cloud-hosted models or Private Inference on Dry Ground AI GPUs.
Supported integrations use the authentication method appropriate to each platform, including OAuth 2.0 and secure app credentials. We limit requested permissions to what the connection needs.
We do not ask for your platform passwords. OAuth permissions can be reviewed and revoked through your identity provider. Other integration connections can be disconnected from CompanyClaw.
Integration management is protected by authenticated organization access controls. Supported secrets, including Slack bot tokens, are encrypted before storage, and provisioned infrastructure uses encrypted storage.
We built CompanyClaw with regulated industries in mind. Tenant data isolation, encryption at rest and in transit, audit logging, and role-based access controls are part of the platform architecture.
During onboarding, we ask about your compliance requirements so we can configure your operator's data handling and autonomy boundaries accordingly.
We have not completed SOC 2 or HIPAA audits. We are transparent about that. If we pursue formal certification, the technical controls required by those frameworks are in production or actively being built.
If your business operates under specific regulatory requirements, we are happy to walk through how our architecture maps to your compliance needs before you sign up.
For Enterprise clients, we will work alongside your auditors to help you achieve the certifications you need.
SOC 2
Audit not completed
HIPAA
Audit not completed
GDPR
Assessment required
CCPA
Assessment required
We would rather answer hard questions upfront than lose trust later. If you have specific compliance requirements or need a security review before signing, reach out.