Security by design.

Security is not a feature we bolted on. It is how the platform is built, deployed, and operated. This page explains the controls we run today. It is written for the people who have to trust us with real data: customers, prospects evaluating us, and their security teams. If you need more detail than is published here, reach out and we will walk you through it.

Encryption

In transit. Every connection to our applications and this site is encrypted with TLS. Plain HTTP is redirected to HTTPS or refused, and our storage is configured to reject any request that is not made over an encrypted connection.

At rest. Customer data is encrypted at rest using AWS Key Management Service (KMS). This covers our primary databases, the disks behind our compute, object storage, and our message queues. Application secrets and credentials are held in a dedicated secrets manager, encrypted with KMS, and are never committed to source code or baked into distributed artifacts.

Infrastructure security

Cap20AI runs on Amazon Web Services. Our workloads live inside an isolated virtual private cloud, with databases and internal services placed on private networks that are not reachable from the public internet. A web application firewall sits in front of public endpoints, and network traffic is logged for analysis.

We do not expose administrative SSH ports to the internet; operator access to servers is brokered through AWS Systems Manager Session Manager, which is authenticated, authorized, and logged. Continuous threat detection (Amazon GuardDuty) watches for anomalous and malicious activity across the account. Development, testing, and production run as separate, isolated environments so that changes are proven before they reach customer data.

Access control

Access to production systems follows the principle of least privilege: people and services are granted only the permissions their role requires. Multi-factor authentication is enforced for privileged access to our cloud infrastructure. Access is granted through role-based policies rather than shared credentials, and database activity is captured through server-side audit logging.

We review who has access to what on a recurring basis and remove access promptly when someone changes role or leaves.

Secure development

Every change to our code is version-controlled and goes through review before it ships, including an automated adversarial review pass that looks specifically for security and correctness regressions. Our infrastructure is defined as code and changes the same reviewed way.

Container images are scanned for known vulnerabilities when they are built, and every deployment runs a specific, immutable, version-controlled image — so what runs in production always maps back to a known, reviewed build. Third-party dependencies are monitored for known vulnerabilities and patched on an ongoing basis. Secrets are pulled from our secrets manager at runtime, never stored in the codebase.

Monitoring, logging & incident response

Administrative and API activity across our cloud account is captured in a centralized, tamper-evident audit trail with log-file validation and write-once retention, so records cannot be quietly altered or deleted. Operational and security signals feed automated alarms that page our team.

We maintain a documented incident response process that defines how we detect, triage, contain, and communicate about security events, including who is responsible at each step. If an incident were ever to affect customer data, we would notify affected customers in line with our commitments and applicable law.

Data handling & resilience

Customer data is logically segregated and handled only for the purposes our customers engage us for. Databases are backed up automatically, backups are encrypted, and we have exercised our disaster-recovery procedures through planned game-day drills rather than assuming they work on paper.

How we collect and handle personal information from this website is covered separately in our Privacy Policy.

Compliance

We build and operate our controls against the SOC 2 Trust Services Criteria, and we are actively pursuing a SOC 2 examination. We will publish our report status here as it progresses, and we can share more detail with prospects and their security teams under a mutual non-disclosure agreement.

Reporting a vulnerability

If you believe you have found a security vulnerability in our systems, we want to hear from you. Email security@cap20.ai with enough detail to reproduce the issue. We investigate every report we receive and will work with you on it.

We support good-faith security research: if you make a genuine effort to avoid privacy violations, data destruction, and service disruption while investigating, we will not pursue action against you for it. Please give us a reasonable opportunity to remediate before any public disclosure.

Contact