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, ORM-enforced tenant scoping, infrastructure encryption, and rate limiting all operate independently.
Every request is authenticated and authorized independently. Authentication middleware resolves your identity on every API call. Database queries are scoped to your organization by the server, not by request parameters you control.
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 require separate API key authentication.
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+. HSTS headers enforce HTTPS. No data travels in cleartext between your browser, our servers, or our databases.
Session-based authentication built on Wasp with httpOnly cookies, Secure and SameSite flags, and automatic session management. 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.
Every database query is scoped to the authenticated user and organization through Prisma ORM. Queries are structurally incapable of returning another tenant's data because the organization ID is injected by the auth middleware, not by the request.
API calls are restricted to authorized origins. Helmet.js enforces Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy headers. Cross-origin requests from unauthorized domains are rejected.
Authentication, chat, and data endpoints have per-IP rate limits. Brute force attempts are throttled before they can be effective.
All customer-facing database operations use Prisma ORM with parameterized queries. No string concatenation in SQL. User input never touches raw query strings. The small number of raw SQL queries that remain are limited to admin-only internal tooling behind separate API key authentication.
All content processed by AI models passes through a sanitization layer that strips prompt injection patterns, role-override attempts, instruction-tag markers, and truncates oversized inputs. This runs on every user message and every imported document before it reaches a language model.
You set the autonomy level during onboarding. Your operator can be configured to ask before every action, handle routine tasks independently, or operate with broader autonomy. You can change this at any time. Every action is logged.
GPU pools are shared in small groups among Dry Ground AI clients. Enterprise clients receive a dedicated GPU. Each operator runs separately on its own VPS, and every client has a dedicated managed database.
Every operator response is scanned before delivery. The gate catches leaked API keys, internal file paths, credential patterns, database connection strings, and data exfiltration attempts hidden in markdown or URLs. Findings are redacted automatically and logged for review.
A rules engine evaluates every tool call before execution. Each action is categorized by risk and mapped against the operator's autonomy level. Destructive and administrative actions always require explicit user approval regardless of autonomy setting.
AES-256-GCM encryption for sensitive fields including contact details, OAuth tokens, and company data at the application layer before database writes. Encrypted fields are unreadable without a separate encryption key stored outside the database.
Native Microsoft Entra ID (Azure AD) authentication for organizations on Microsoft 365. Supports multitenant and personal Microsoft accounts with PKCE flow and automatic account linking for users who signed up through other providers.
All stored authentication tokens and API keys are hashed with SHA-256 before persistence. Tokens are verified by hash comparison, never stored or compared in plaintext.
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.
All user input and imported content is sanitized before it reaches any language model. Role-override patterns (system:/assistant:/user:), instruction tags, and known injection techniques are stripped or neutralized. Oversized inputs are truncated. This runs on every message, every knowledge import, and every onboarding form submission.
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 every action, handle routine tasks independently, or operate with broader autonomy. You can change this at any time. Every action is logged with timestamps, context, and outcome.
Your operator can use cloud-hosted models or private inference.
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.