Built on Zero-Trust, Backed by Google Cloud
AimCEO is engineered so your browser, iPhone, or Android device never holds the keys to the kingdom. Every request to every protected endpoint is independently authenticated and authorized on the server. AI provider keys, database admin credentials, and gateway tokens live only in our backend and are never bundled into the client. When combined with Google Cloud's managed encryption and identity platform, the result is a platform that is secure by architecture, not by promise.
Our Four Security Principles
Zero-Trust by Default
No client is implicitly trusted. Every request to every protected endpoint is independently authenticated and authorized on the server — regardless of whether it comes from a browser, a mobile app, or an internal service. Sessions cannot be forged, and stale tokens are rejected immediately.
Secrets Never Touch the Client
AI provider keys, service-account credentials, database admin tokens, and gateway authorization tokens live only in the backend and are injected via environment variables — never bundled into web or mobile code. The client cannot leak what it does not hold.
Least-Privilege Data Access
Databases and object storage default to deny-all at the infrastructure layer. Access is mediated exclusively through the authenticated backend, which enforces per-tenant scoping on every read and write. A user from one organization cannot address data in another, even by guessing or enumerating IDs.
Defense in Depth
Multiple independent layers — transport encryption, authentication, authorization, input validation, rate limiting, and signed cryptographic device identity — must each fail before data is exposed. Assume-breach thinking is built into the architecture from day one.
How Data Flows Through AimCEO
Customer data never flows directly from a browser or mobile device to the database, file storage, or any AI model. Every read, write, AI prompt, and file upload is mediated by our NestJS API, which re-authenticates the caller and enforces tenant scoping on each operation.
1. Client Request
The Angular web client or Capacitor-wrapped iOS/Android app obtains a fresh, short-lived Firebase ID token and attaches it as a Bearer credential to every HTTPS request. An HTTP interceptor checks token expiry and triggers silent rotation before each call.
2. Server-Side Verification
Our NestJS API cryptographically verifies every token against Google's published keys, validates issuer, audience, expiry, and revocation state, then resolves the tenant from the token's custom claims — not from client-supplied parameters.
3. Scoped Execution
DTO schemas strip unknown fields and reject malformed inputs. Backend services apply tenant and role checks on every database query and storage operation. AI prompts are forwarded to the OpenClaw gateway under the backend's signed identity — the client is never exposed to model credentials.
Identity and Authentication
AimCEO delegates user identity to Google Firebase Authentication — an enterprise OIDC-compliant identity platform. Credentials are validated by Google's infrastructure. Our servers never receive or store raw passwords.
Short-Lived, Rotating Tokens
Firebase issues ID tokens (JWTs) with a one-hour expiry. Refresh tokens are held inside the Firebase SDK's secure storage and rotated transparently. If a token is ever leaked, the blast radius is measured in minutes, not days.
Cryptographic Token Verification
Every request is gated by a global auth guard that verifies the JWT signature against Google's JWKS keys using the Firebase Admin SDK. Unsigned, expired, tampered, or revoked tokens are rejected with HTTP 401 before any business logic runs.
Role-Based Access Control
Every user is assigned one or more roles — OWNER, ADMIN, MEMBER, or VIEWER — stored as Firebase custom claims and therefore tamper-evident. Access rights are enforced on the server, not advertised by the client.
Instant Session Revocation
Administrators can terminate every session for a compromised account in a single call — all outstanding ID tokens begin failing at the next refresh. Stale clients are automatically kicked to the sign-in screen when the server returns 401.
AI Gateway Security
The OpenClaw gateway is the single chokepoint through which AimCEO invokes large-language-model providers. Its security model is engineered specifically to keep AI credentials out of reach of end users and to authenticate the backend to the gateway with cryptographic evidence.
No Direct Client Access
Your browser or mobile app never connects to OpenClaw and never holds an LLM API key. AI responses stream through our backend via Server-Sent Events, authenticated on every call with your Firebase token.
Signed Device Identity
Our backend authenticates to OpenClaw with a persistent asymmetric keypair. Every handshake is signed with a fresh nonce, timestamp, and scope set — stolen tokens alone cannot be replayed from an unauthorized host.
Scope-Bounded Tokens
Gateway access tokens carry explicit scope claims. Our backend can only invoke the subset of RPCs required for your workload, limiting the blast radius of any single credential.
Encryption at Rest and In Transit
Your data is encrypted everywhere it lives and everywhere it travels — by Google Cloud's managed infrastructure, not by homegrown cryptography.
TLS 1.2+ Everywhere
All public traffic uses TLS 1.2 or higher. HSTS headers prevent downgrade attacks. WebSocket connections to the AI gateway automatically upgrade to WSS in any non-localhost deployment.
AES-256 at Rest
Cloud Firestore and Cloud Storage encrypt all data at rest with Google-managed AES-256 keys by default. Customer-managed encryption keys (CMEK) are available for customers with key-sovereignty requirements.
Signed Upload URLs
File uploads use short-lived V4 signed URLs — 15 minutes for uploads, 60 minutes for downloads. Storage credentials never reach the client, and expired URLs are permanently useless.
Security on iOS and Android
When AimCEO is packaged as a native iOS or Android app via Capacitor, the same backend, the same token verification, and the same AI gateway are reused verbatim. Mobile builds add several layers of platform-specific hardening.
OS-Backed Secure Storage
Session data is held in the iOS Keychain and Android EncryptedSharedPreferences / Keystore — hardware-isolated on modern devices and inaccessible to other applications.
Forced HTTPS
Android uses the HTTPS scheme for all webview navigation. iOS App Transport Security blocks non-TLS connections at the OS level. Cleartext traffic is disabled in release builds.
Code Signing
APKs are signed with a customer-specific keystore and distributed through Google Play. IPAs are signed with Apple-issued developer certificates and distributed through the App Store.
Biometric Unlock
The Firebase session can be gated behind Face ID, Touch ID, or Android BiometricPrompt, so a stolen unlocked device still cannot access AimCEO without a biometric match.
Platform Hardening
Strict Input Validation
Every API endpoint declares a typed DTO schema. A global validation pipe strips unknown fields, rejects malformed payloads, and coerces inputs to declared types — neutralizing prototype-pollution and injection-style attacks.
Rate Limiting
A global throttler enforces 100 requests per minute per IP by default, preventing brute-force, enumeration, and denial-of-service attacks. Per-endpoint limits can be tightened for sensitive operations.
Secure HTTP Headers
Helmet middleware applies HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and baseline Content-Security-Policy directives to every response — closing off clickjacking, MIME-sniffing, and mixed-content attack vectors.
Strict CORS Allow-List
Only origins explicitly listed in our deployment configuration can call the API. Combined with Bearer-token authentication (no cookies), the classical CSRF attack surface is eliminated entirely.
Default-Deny Storage Rules
Firestore and Cloud Storage are configured to refuse all direct client access. Our authenticated backend is the sole principal with database privileges, and it applies tenant and role checks on every single operation.
Sanitized Error Responses
Stack traces and internal error details are logged server-side only. Clients receive a generic, timestamped error envelope — preventing internal structure from leaking through unexpected failures.
Compliance Alignment
The architecture is designed to align with the controls expected under the compliance frameworks our customers operate under.
SOC 2
Logical access control via Firebase Auth, structured audit logging, TLS in transit, and AES-256 at rest satisfy the Trust Services Criteria for Security, Availability, and Confidentiality.
GDPR / CCPA
Tenant-scoped data model supports per-customer data export and deletion. Data residency follows the Firebase project's configured region — US, EU, and multi-region options available.
HIPAA
For covered customers, AimCEO can be deployed against Firebase's HIPAA-eligible configurations with a signed Google Cloud BAA. Our application-layer controls satisfy the technical safeguards required for ePHI.
OWASP Top 10
Parameterized DTOs, server-side JWT verification, signed storage URLs, Helmet, CORS, tenant-scoped queries, and default-deny rules directly address the top injection, authentication, and access-control risks.