Responsible Disclosure Policy

1. Purpose

Crelis builds runtime authorization for AI agents, so the security of our own systems matters to our customers as much as it does to us. This policy explains how to report a suspected vulnerability, what you can test, what we commit to in return, and how we protect researchers who act in good faith.

It applies to anyone who finds a security issue in a Crelis system or product, whether through deliberate research or by accident.

2. In scope

The following assets are in scope:

Our console and APIs require an account. Please do not test against another organisation’s tenant. If you need a test environment, email us before you start and we will discuss what we can provide.

3. Out of scope

The following are out of scope. Reports about them are unlikely to be accepted unless you can show a concrete security impact:

• Denial-of-service or volumetric testing, load testing, and anything that degrades service for others.
• Social engineering, phishing or physical attacks against Crelis staff, offices or partners.
• Raw output from automated scanners without a verified, exploitable finding.
• Missing security headers, cookie flags, or email authentication (SPF, DKIM, DMARC) settings, without demonstrated impact.
• Clickjacking on pages with no sensitive actions, self-XSS, and logout or login CSRF.
• Software version disclosure, banner grabbing, or descriptive error messages without sensitive data.
• Rate-limit or brute-force findings on non-authentication endpoints.
• Issues that require a compromised device, a rooted or jailbroken phone, or physical access to a user’s machine.
• Vulnerabilities in third-party services we use, such as our cloud, hosting, email or identity providers. Please report those to the provider directly. If the issue arises from how we have configured that service, it is in scope.
• Vulnerabilities publicly disclosed less than 30 days ago, where we are still within a reasonable patch window.

4. Rules of engagement

When you research a Crelis system, please:

• Only test against accounts, tenants and data that you own or are explicitly authorised to use.
• Stop as soon as you reach data that is not yours, such as another customer’s decisions, audit records or personal data. Do not view, copy, change or keep it beyond what is needed to show the issue. Report it to us immediately, and securely delete any copies once we confirm the report.
• Do not use an issue to get further access, move to other systems, or keep a foothold.
• Do not change, delete or disrupt data, policies, approvals or audit records, and do not trigger real-world actions through a connected agent.
• Keep testing proportionate. Use the minimum number of requests and accounts needed to show the issue.
• Do not share the issue with anyone else until we have resolved it, or until the coordinated disclosure date described below.
• Comply with all applicable laws.

5. How to report

Email support@crelis.ai with the subject line “Security disclosure”. Our machine-readable contact details are published at /.well-known/security.txt (RFC 9116).

A good report includes:

• The affected asset, URL, endpoint or package and version.
• A description of the issue and its type, for example broken access control or injection.
• Step-by-step reproduction instructions, with requests and responses, screenshots or a short proof of concept.
• The impact you believe it has, and your view of its severity (a CVSS vector is welcome but not required).
• Whether, and how, you would like to be credited.

If the details are sensitive, say so in your first email and we will arrange an encrypted channel before you send them. You may report anonymously, although we will then be unable to send you updates or credit you. Reports in English are preferred.

6. What we commit to

When you report in line with this policy, we aim to:

These are targets, not guarantees. Complex issues can take longer, and we will tell you if that happens. We will let you know when the issue is resolved.

7. Safe harbour

If you make a good-faith effort to follow this policy, we will treat your research as authorised. In particular:

• We consider such research to be authorised access for the purposes of the Singapore Computer Misuse Act 1993 and similar laws, and we will not initiate or support legal action or a complaint against you for it.
• We will not bring a claim against you for circumventing technical measures solely to test the security of a system in scope.
• We waive any restriction in our Terms of Service that would otherwise prevent research conducted under this policy, to the extent needed for that research.
• If a third party brings legal action against you for activity that followed this policy, we will make it known that your activity was authorised by us.

This safe harbour covers only Crelis systems. We cannot authorise testing of our customers’ or providers’ systems. If you are unsure whether something you plan to do is covered, ask us first.

8. Coordinated disclosure

We ask that you do not disclose an issue publicly until we have released a fix, or until 90 days after your report, whichever comes first. If we need more time, we will explain why and agree a new date with you. If an issue is being actively exploited, we may agree a shorter timeline.

We will tell affected customers about confirmed issues where that is warranted, under the terms of our agreements with them.

9. Recognition and rewards

We do not run a paid bug bounty programme at this time, and we do not make payments for reports. With your permission, we are glad to credit you publicly once a valid issue is fixed.

Please do not make a report conditional on payment. Demands for payment in exchange for not disclosing an issue fall outside this policy and outside its safe harbour.

10. Customers and incidents

If you are a Crelis customer and believe your tenant is affected by a security incident, contact us through your usual support channel as well as by email, so that we can respond under your agreement.

Changes to this policy

We may update this policy from time to time. The date at the top shows when it was last changed. Reports are handled under the version in force when they are received.