Cyril Trust Centre
We are committed to the security, privacy and reliability of your data. This page summarises Cyril's security posture, compliance commitments and operational practices.
Security practices
Encryption in transit
All traffic to Cyril is encrypted with TLS 1.2 or higher. HTTPS is enforced on every endpoint; HTTP requests are redirected.
Encryption at rest
Per-org integration secrets, OAuth tokens and TOTP seeds are encrypted at the application layer with a master key stored outside the database. Encrypted backups are written via age before upload to object storage. The primary database relies on the hosting provider’s volume encryption — provider-managed AES-256.
Access controls
Role-based access control with least-privilege defaults. Multi-factor authentication is enforced for platform administrators and can be required organisation-wide by customer admins.
Vulnerability management
Automated dependency scanning (Dependabot + pnpm audit), static analysis (CodeQL) and container scanning (Trivy) gate every production deploy. Coordinated disclosure runs through our bug-bounty programme.
Incident response
Documented incident-response runbook with severity levels and named SLAs. Personal data breaches are notified to affected customers within 72 hours of confirmation, in line with GDPR Article 33.
Tenant isolation
A shared database with org_id row isolation enforced at the service layer. Cross-tenant isolation tests are required for every entity type per our Definition of Done. There is no cross-tenant data sharing.
AI and your data
Cyril has an AI layer built into the product. Because that layer reads your business records to be useful, we hold it to the same access rules as the rest of the platform and are explicit about what leaves our infrastructure.
The AI can only see what you can see
Cyril’s AI answers as the individual user, not as the organisation. Retrieval is filtered by the same record ownership, role and workspace permissions that govern the interface, so it can never surface a record you would be denied in the UI. This is enforced in code — it is not an instruction given to the model, which could be argued around.
Enforcement is tested, not asserted
Automated cross-role isolation tests run on every change and block the release if a lower-privileged role can retrieve another user’s records through the AI. AI retrieval is also recorded to an access log for audit.
Identifiers are stripped before they leave
Before any prompt reaches a model provider, structured direct identifiers — email addresses, phone numbers, IP addresses, national insurance and social-security numbers, IBANs and card numbers — are replaced with reversible tokens, then restored in the response you see. Identifiers embedded in free-form prose, such as a person’s name written mid-sentence, have no reliable pattern and are not tokenised.
You can turn external AI off
An organisation admin can disable external-LLM processing for their tenant entirely. The switch is enforced at the single point every AI call passes through, and refuses the call before any request body is built — not at the interface layer.
A no-egress option exists
Organisations that cannot send data to a third-party model at all can be routed to self-hosted inference operated within our infrastructure or their own. That route carries no public-provider fallback: a request either reaches the private endpoint or fails.
Tenant isolation applies to AI too
Every AI and retrieval query is scoped to a single organisation. Two organisations never share retrieval results, and never share a cached prompt prefix with a model provider.
Model training. We use Anthropic and OpenAI through their commercial API tiers, which under those providers' published terms are not used to train their models. The consumer-chat training behaviour people are usually thinking of does not apply to API traffic.
What is still in progress. We would rather tell you this than let you assume it. Two commitments are not yet in force: countersigned data-processing agreements with each model provider under our operating entity, and Zero Data Retention terms that remove the short abuse-monitoring window during which a provider may hold a request. Until both are in place, providers are used under their standard published terms, our customer DPA is offered as a draft rather than a counsel-approved agreement, and we make no contractual retention claim beyond what those published terms give us. Organisations that need a guarantee sooner can use the tenant AI switch or the no-egress option above. We will update this section, with dates, as each item completes.
The engineering controls described above come from an internal AI trust posture audit, including the gaps we found and what we did about each one. It is available on request — email security@getcyril.com.
Compliance and certifications
SOC 2 Type 1
Preparing for first audit
SOC 2 Type 1 is a general-availability gate for Cyril. Type 2 follows six months after Type 1 attestation. We hold no certification today and no audit report is available.
GDPR
Compliant
We process personal data in accordance with the GDPR. Data-subject rights — access, erasure, rectification and portability — are supported through the platform.
Data Processing Agreement
Draft — pending counsel review
Our DPA is available to read now, but it has not yet completed legal-counsel review and is published as a draft for evaluation rather than as a final agreement. Customers needing an executed DPA should contact us and we will confirm timing.
Uptime and status
Cyril is pre-launch software under active development, and our Terms of Service say plainly that there is no uptime commitment and no service level agreement. We publish no availability percentages here, and there are no service credits. In practice the service may be interrupted for maintenance, features may be briefly unavailable during a deployment, and defects will be found in production because the product is young.
Service levels and support response times exist only where an Enterprise Order agrees them. Those apply to that customer and prevail over the general position; none apply by default. If you need a committed service level before you can adopt Cyril, that is a conversation to have during the Order, not an assumption to make from this page.
Real-time service status — current incidents, scheduled maintenance and historical uptime — lives on status.getcyril.com. The status surface is being stood up as part of our pre-GA hardening; until it is live, customers can subscribe to incident notices through their organisation email contact.
Sub-processors
Some third parties are part of how Cyril runs — hosting, email delivery, the model providers behind the AI layer. Every organisation on the platform uses those, and there is no setting to turn them off. Others are optional: they are engaged only when somebody at your organisation switches an integration on from Settings → Integrations. If the integration is never configured, no data flows to that party.
Rather than keep a second copy here, the canonical disclosure — each provider, what is sent to it, the processing region, and the data terms it is held under — is published in full at /legal/sub-processors/.
Notification of changes. That page is where a change appears first: when a sub-processor is added, removed or replaced, we update it along with the date it carries. Section 3.2 of the Data Processing Agreement commits to 60 days’ written notice before any always-on provider changes, with a right to object during that window. The DPA is still a draft pending legal review, so that commitment is as firm as a draft can be — but it is in the document you can download today, and we would rather be held to it than have it sit unread. To be told when the list changes, email legal@getcyril.com.
Bug bounty
We run a coordinated vulnerability disclosure programme and welcome reports from security researchers acting in good faith. Eligible reports are publicly credited, and we commit to never pursuing legal action against researchers who follow the policy.
Be one of the first to use Cyril.
Join the waitlist for early access. We'll only email you when there's something real to share.