Enterprise
The Ciao enterprise security model
Isolated workloads, continuously tested changes and security findings confirmed against the live application — documented in a security pack your reviewers can read under NDA.
Ciao's enterprise security model combines isolated per-project infrastructure with continuous security testing: static scanning, dependency checks, access-control probes and vulnerabilities confirmed against the live application before they are flagged. Unlike AI coding tools that stop at generating code, Ciao treats security as part of the delivery loop — with SOC 2 Type II reports available under NDA and a security pack available on request.
Published 2026-07-03 · Last updated 2026-07-03
Why the security model matters more with AI in the loop
AI-assisted development changes the questions a security review has to answer. Code volume goes up, change frequency goes up, and a new class of supplier — the model vendor — enters your data-flow diagram. A platform that generates production software has to show you three things clearly: where workloads run and how they are isolated, how changes are tested before and after they ship, and what happens to the code and data that pass through the system.
Most tools in this category answer with a feature list. A CISO needs evidence: an independent audit, a document set the team can review under NDA, and controls you can watch operating during an evaluation. Ciao's security model is built to be inspected, not just described.
This page summarizes the model — isolation, encryption, continuous testing and live security probes — and states exactly how to verify each part. Nothing here should be taken on trust; every claim maps to a document you can request or a control you can watch run.
What Ciao provides
Every item below traces to a control you can verify during review.
- Isolated infrastructure — Projects run on Kubernetes in isolated pods, with hibernation and wake and multi-region support — infrastructure designed to scale without blurring workload boundaries between customers or projects.
- Static and dependency scanning — Ciao's Security engineer runs static scanning and dependency checks as part of the delivery loop, so generated and human-written code alike are checked before publish.
- Access-control probes — Security probes access rules against the running application rather than only reading the code, testing what an attacker would actually reach.
- Live-confirmed findings — Vulnerabilities are confirmed against the live app before they are flagged, so your team reviews real exposure instead of scanner noise.
- Safe-to-publish visibility — A safe-to-publish dashboard shows whether a project is clear to ship, fed by scanning, probes and confirmed findings.
- Identity and access — SSO via SAML and OIDC, optional MFA and role-based access control across workspaces and projects.
- Auditability — An append-only audit trail records prompts, merges, deploys and admin actions.
- Model data handling — Customer code is not used to train models, and inference runs under zero-retention model contracts.
How security testing runs in practice
1. Build in isolation
Each project builds and runs in its own isolated pod, so a change in one project cannot reach another project's runtime.
2. Scan
Static scanning and dependency checks run against the codebase, catching known vulnerability patterns and vulnerable packages before they ship.
3. Probe
Access-control probes exercise the running application — endpoints, roles, data access — the way an outside party would.
4. Confirm
Findings are confirmed against the live app before they are flagged, which keeps the queue short and credible for the humans who triage it.
5. Gate
QA smoke gates run before publish, and Guardrails applies plain-English policies with recorded human review for risky changes.
6. Monitor
After publish, QA production checks keep running, and Doctor — a read-only AI SRE — probes the live app, DNS and CDN to diagnose issues early.
Isolation and encryption
Workload isolation is structural: Kubernetes with isolated pods per project, not a shared runtime with logical separation bolted on. Encryption in transit and at rest is standard practice on the platform, and the specifics that matter to a reviewer — protocols, key management, scope — are documented in the security pack rather than compressed into a marketing sentence here. If your review needs the details, request the pack and read the real answer.
Teams that need a harder boundary can deploy to their own AWS, Azure or GCP account or a private VPC; on-prem is available under separate terms. In those postures the application and its data run inside infrastructure you already control and monitor.
Verification: how to check every claim on this page
SOC 2 Type II reports are available under NDA — the independent, audited account of how these controls operate over time. The security pack, available on request via the contact page, covers architecture, isolation, encryption and data handling in reviewer-grade detail. And because the security controls are part of the product, you can watch them run: ask for a live walkthrough of scanning, access-control probes and the safe-to-publish view during your evaluation. Serious production programs start at USD 10,000 per year; scope and posture are agreed with the enterprise team.
Control by control: what Ciao provides and how to verify it
| Control | What Ciao provides | How to verify |
|---|---|---|
| Workload isolation | Kubernetes with isolated pods per project | Architecture detail in the security pack |
| Vulnerability detection | Static scanning, dependency checks, access-control probes | Live walkthrough of the Security dashboard |
| Finding quality | Vulnerabilities confirmed against the live app before flagging | Review a finding end-to-end in a demo |
| Identity and access | SSO via SAML and OIDC, optional MFA, RBAC | Configuration walkthrough with your IdP |
| Model data handling | No training on customer code; zero-retention model contracts | Contract terms during procurement |
| Independent audit | SOC 2 Type II | Report under NDA, requested via /contact |
Frequently asked questions
Do you run penetration tests?
Testing-program specifics belong in the security pack, which is available on request under NDA rather than summarized in marketing copy. Independent of any point-in-time exercise, the platform continuously scans code and dependencies and probes access controls against the live application.
Is our code or data used to train models?
No. Customer code is not used to train models, and inference runs under zero-retention model contracts. The contractual language is part of the document set your legal team reviews during procurement.
Can we run Ciao inside our own security boundary?
Yes. You can deploy to your own AWS, Azure or GCP account or a private VPC, and on-prem is available under separate terms. Talk to the enterprise team about which posture fits your review.
How do you keep AI-generated changes from introducing vulnerabilities?
Every change passes the same loop: static scanning, dependency checks and access-control probes, with findings confirmed against the live app before they are flagged. Guardrails applies plain-English policies and records human review, so risky changes are reviewed by people and the audit trail shows who approved what.
What is your dependency on a single model vendor?
Ciao runs a multi-provider model ladder with fallback, which reduces dependency on any single model vendor. Model vendor terms, including zero retention, are part of the contractual review during procurement.