Skip to main content
Tuteliq operates a hosted child-safety detection API. We welcome reports from security researchers, and we would rather hear about a weakness from you than from an incident.

​
Reporting a vulnerability

Email security@tuteliq.ai. Please do not open a public issue or post. If you need to send something sensitive, say so in your first message and we will arrange an encrypted channel. Include whatever you have. The most useful reports contain:
  • what an attacker can do, stated as impact rather than as a scanner category
  • the steps to reproduce it, including the request and the response you saw
  • the endpoint, timestamp and approximate source IP of your test traffic, so we can separate it from real activity in our logs
  • any test account or key you used

​
What happens next

We will tell you what we decided and why. If we decline a report we will explain the reasoning rather than closing it silently, and you are welcome to push back. If a fix will take longer than the target, we will say so and give you a date rather than going quiet. Where a vulnerability affects customer data, our regulatory notification obligations run in parallel and are not contingent on any disclosure timeline agreed with you.

​
Supported versions

The API is hosted. There is a single production version, it is the current one, and a security fix reaches every customer on deployment. There are no older API versions still running that you could be left on, and no back-porting. Published client packages are supported at their latest minor release. Where a fix requires a new version of @tuteliq/sdk or @tuteliq/mcp, we publish it and note the minimum safe version in the changelog. Older majors do not receive security fixes.

​
Scope

In scope

  • api.tuteliq.ai and the endpoints it serves
  • tuteliq.ai and docs.tuteliq.ai
  • the @tuteliq/sdk and @tuteliq/mcp packages as published
  • authentication, authorisation, tenant isolation and billing integrity, including any path that lets one account reach another account’s data or consume another account’s quota

Out of scope

  • our customers’ own applications and integrations
  • third-party services we consume, which belong to that vendor
  • social engineering of our staff, customers or suppliers
  • physical attacks, and anything targeting personal accounts or devices
  • volumetric denial of service, load testing and traffic flooding
  • reports with no demonstrated impact, such as a missing hardening header or raw scanner output with no working path to exploitation

​
Rules for testing

These exist because of what this API is for. Please read them before you test.
Never use real child sexual abuse material. Not to test a detection endpoint, not to demonstrate a bypass, and not as an attachment to a report. It is illegal to possess or transmit in every jurisdiction we operate in, we cannot lawfully accept or review it, and sending it to us creates a criminal matter rather than a security report.Use synthetic or clearly benign fixtures. If you believe you have found such material in the wild, do not send it to us. Report it to the Internet Watch Foundation or your national hotline.
Do not use real people’s data. No real identity documents, no real biometrics, no images of real children, and no production personal data belonging to anyone other than yourself. Our verification endpoints accept documents and selfies, so this matters more here than on a typical API. Synthetic test data only. Do not touch other tenants. Test against your own account. If you find a path to another account’s data, stop at the point of proof, record enough to show it works, and report it. Do not enumerate, download or retain what you can reach. Ask for a sandbox. Email us and we will issue a test key rather than have you probe production. It is faster for you and quieter for us.

​
Detection bypasses are in scope

If you find an input that carries genuine harm past a detection endpoint, whether through an encoding, an obfuscation, a language, or a message structure that causes a harmful conversation to come back clean, that is a security report and we want it.
Report a bypass privately and do not publish a working payload. A published evasion technique against a child-safety filter is directly usable against children on our customers’ platforms, and the window between publication and a deployed fix is the window in which that happens.We will work with you on timing, and on what can safely be described afterwards.
The same applies to a reliable way to force false positives at scale, since a detector that can be made to cry wolf can be used to bury real reports.

​
Safe harbour

If you make a good-faith effort to follow this policy, we will treat your research as authorised. We will not pursue or support legal action against you, and if a third party does, we will make clear that your testing was authorised. Good faith means staying in scope, following the testing rules above, stopping at proof rather than extraction, avoiding degradation of service for our customers, and giving us a reasonable chance to fix the issue before discussing it publicly. This is not a waiver of anyone else’s rights. If your testing reaches a system or data belonging to a customer or a third party, we cannot authorise that on their behalf.

​
Disclosure

We work to coordinated disclosure and ask for 90 days from your report before publication, or less by agreement once a fix is deployed. For a detection bypass we may ask you to describe the class of weakness rather than a working payload. We are happy to credit you by name or handle in the changelog and in any advisory, or to keep you anonymous. Tell us which you prefer. We do not currently run a paid bug bounty, so please do not expect a payment. The absence of a bounty does not change the safe harbour above, and it does not make your report less welcome.