Ciele
Open app
Log in
Get a demo
Open app
Get a demo
Log in
Ciele

Product

  • Features
  • Pricing
  • Download
  • Log in

Enterprise

  • Governance
  • Security
  • Talk to sales

Resources

  • Docs
  • Getting started
  • Self-hosting

Legal

  • Privacy Policy
  • Terms of Service
  • Cookie Notice
© 2026 Ciele. AI you can trust.Rome, , :,

Newsletter

Security

Responsible disclosure

Last updated 5 August 2026

If you have found a vulnerability in Ciele, we want to hear about it and we would rather you did not have to guess at the rules first. This is what is in scope, what we commit to doing, and what we ask of you in return.

On this page

  1. 01How to report
  2. 02What we commit to
  3. 03What we ask of you
  4. 04In scope
  5. 05Out of scope
  6. 06Safe harbour
  7. 07Related pages

01How to report

Email security@ciele.app. The mailbox is monitored, and a report reaches a person who can act on it rather than a ticket queue.

A useful report includes:

  • What the issue is, and what an attacker could do with it.
  • Where it is: the URL, endpoint or component, and the affected version or commit if you know it.
  • Reproduction steps precise enough for us to see it ourselves.
  • Any proof-of-concept request, payload or screenshot.
  • Whether you accessed any data that was not yours, and how much.

Write in English or Italian. If encryption matters for what you are sending, say so in the first message and we will arrange a channel.

02What we commit to

  • We acknowledge a report within two business days.
  • We give you an initial assessment, including whether we consider it in scope, within five business days.
  • We keep you updated while we work on it, and we tell you when it is fixed.
  • We will not pursue legal action against you, or ask anyone else to, for research carried out in good faith under this policy.
  • We credit you publicly if you would like us to, and stay quiet about your involvement if you would rather we did.

We do not run a paid bug bounty. We would rather say that plainly than let a report arrive with the wrong expectation.

03What we ask of you

  • Give us reasonable time to fix an issue before disclosing it. Ninety days is the default, and we are usually much faster.
  • Use only accounts and organizations you own, or ones you have written permission to test.
  • Stop as soon as you have confirmed an issue: do not enumerate further records, escalate laterally or persist access.
  • Do not exfiltrate, retain or share data belonging to anyone else, and delete anything you incidentally accessed once you have reported it.
  • Do not degrade the service: no denial of service, no load testing, no spam through platform email or escalation channels.
  • Do not social-engineer our staff, customers or their students, and do not attack physical premises.

04In scope

  • Everything we serve on ciele.app: the marketing site, the admin console and its server actions.
  • The published widget runtime and the public API endpoints it calls.
  • The open-source code in our public repository, including the self-host stack.

Classes of issue we especially want to hear about: anything that crosses a tenant boundary or defeats row-level security, authentication or session flaws, privilege escalation between roles, exposure of sealed credentials, server-side request forgery through the crawler or the API-integration egress path, and prompt injection that causes an assistant to leak another organization's knowledge or to reach a host it was never configured to reach.

05Out of scope

  • Findings from automated scanners with no demonstrated impact.
  • Missing security headers, cookie flags or TLS configuration nits with no exploitable consequence.
  • Denial of service, volumetric or resource-exhaustion testing, and rate-limit absence without further impact.
  • Social engineering, phishing of staff or customers, and physical attacks.
  • Self-XSS, and issues that require a compromised device, a rooted browser or a malicious extension.
  • Vulnerabilities in third-party services we do not control. Report those to the provider, and tell us if the exposure is ours.
  • Content an assistant generates that is merely wrong, off-topic or unhelpful. That is a quality issue, not a vulnerability, and the product has an Improvements tracker for it.

06Safe harbour

Research conducted in accordance with this policy is authorised, and we will treat it as such. We will not initiate or support a claim against you under computer-misuse law, contract or the DMCA for that work, and if a third party brings one we will make clear that your testing was authorised.

This does not extend to testing that goes beyond what is described here, and we cannot authorise testing against a customer's own self-hosted deployment or against a third-party system they have connected. Ask that customer, not us.

07Related pages

  • Security overview. The practices and compliance status behind this policy.
  • GDPR. Our processor role and the measures protecting personal data.
  • Data Processing Addendum. Including the breach-notification commitment.

The fine print

Even our cloud nods off here

Short where it can be, precise where it must be. If anything in these pages is unclear, write to us and a human will answer.

Contact us