AI that works for you,
without holding your keys.
2025–26 saw a wave of breaches in AI-generated apps: leaked credentials, exposed databases, thousands of critical vulnerabilities. Claritty was architected so those failure modes can’t happen by construction, your credentials never reach app code, and apps are composed from a vetted catalog instead of improvised codegen.
Where your keys actually live
Apps ask the broker to act; the broker holds the encrypted credential and talks to your tools. Only results reach the app, the credential's path is architecturally closed, not policy-closed.
The controls, one by one
Credentials are encrypted and brokered server-side
Connected-integration tokens (Gmail, Slack, LinkedIn, …) are AES-256-GCM envelope-encrypted with AWS KMS, brokered through our server-side integration layer, decrypted transiently in memory only at the point of use, and never written to logs. Credentials are never persisted inside an app’s own storage.
No freeform AI codegen against your data
Apps are composed from a closed, vetted capability catalog, not improvised code with database access. Every capability an app can use went through review before it ever existed in the catalog. Submitted code is additionally run through a multi-layer security scanner before deployment.
Authenticated, fail-closed edge
Every request to a customer app passes an authentication function at the CloudFront edge that verifies identity before anything reaches the app, strips client-supplied identity headers, and stamps a verified server-issued identity. If verification cannot complete, access is denied, not allowed.
Per-app runtime isolation
Each app runs in its own isolated serverless runtime with its own database schema and connection credentials. Apps are deployed and executed independently, and each request carries a server-verified identity so an app only ever acts for the authenticated user in front of it.
Private-by-default network
Databases, caches, and file systems run in private subnets with no public IPs, reachable only from the application tier. There is no public SSH; administrative access goes through AWS Systems Manager. Traffic is TLS 1.2+ everywhere, and the API sits behind AWS WAF with platform-wide rate limiting.
Encryption at rest, everywhere it matters
The primary database (Amazon RDS) and object storage are encrypted at rest. Bring-your-own LLM keys are KMS-encrypted and used only for your workloads. Platform secrets are managed in AWS Secrets Manager and injected into services at runtime.
Identity done by professionals
Authentication is handled by Auth0, we store no passwords. API access uses RS256-signed JWTs validated against rotating public keys with strict audience and issuer checks, and account status is re-checked on every request.
Compliance status
Claritty is actively pursuing SOC 2 Type II (Security). We are not yet certified; everything on this page describes technical and operational controls already in production. We are transparent about what’s in progress: expanded audit logging and retention, centralized alerting and incident response, and automatic secret rotation.
For our current status, a detailed sub-processor list, or help with a vendor security questionnaire, email security@claritty.ai.
Sub-processors
Responsible disclosure
We welcome reports of security issues at security@claritty.ai. We’ll acknowledge your report and work with you on remediation, please give us the chance to fix before public disclosure.
Have a security questionnaire?
Send it over, we answer vendor security reviews quickly, with specifics.
Contact us