Vulnerability Disclosure Policy

If you make a good-faith effort to comply with this policy, we will not initiate or support legal action against you for your research. We consider such research authorised, we will not report you to law enforcement for it, and if a third party brings action against you for activity conducted in accordance with this policy, we will make it known that your actions were authorised.

If you are unsure whether something is in scope or whether a particular test is acceptable, ask us before you do it. We would much rather answer a question than have you guess.

Email [email protected]. Please include enough detail for us to reproduce the issue: the URL or component affected, the steps you took, what you expected, and what actually happened. A proof of concept, a screenshot, or a short recording all help. Write in English if you can; if that is difficult, send it in your own language and we will translate.

Please report even if you are not certain it is exploitable. A partial finding we can investigate is more useful than a perfect report that never arrives.

These are targets we hold ourselves to, not contractual guarantees. We are a small team; if something takes longer we will tell you why rather than going quiet.

We are glad to credit you publicly by name or handle when the issue is resolved, if you want that. Tell us how you would like to be named, or tell us you would rather stay anonymous. We do not currently run a paid bug bounty and cannot offer a monetary reward — we would rather say that up front than let you spend a weekend expecting one.

The websites and services we operate, including eyesinai.com and its subdomains, the client portal, the embeddable assistant widget, and our public API endpoints.

Some things are either not ours to authorise or not useful to receive. Please do not test or report:

• Our clients' own websites and systems.An assistant embedded on a client's site does not make their infrastructure ours to authorise testing on.
• Third-party providers. Our model providers, hosting, and database vendors run their own disclosure programmes. Report to them directly.
• Denial of service, load testing, or resource exhaustion. Never test these. They cause real harm to a live service and are explicitly unauthorised.
• Social engineering of our staff, clients, or vendors, including phishing and pretexting.
• Physical attacks against any premises or equipment.
• Findings from automated scanners with no demonstrated impact, missing hardening headers that do not lead to an exploit, and reports that a model produced an incorrect or undesirable answer — that last one is a quality matter, covered by the AI Use Policy.

To stay within the safe harbour above, please:

• Stop as soon as you have proved the point. Confirm the vulnerability exists, then stop. Do not enumerate further.
• Do not access, modify, or delete data that is not yours. If you accidentally reach someone else's data, stop immediately, do not save a copy, and tell us what happened — we will not hold the accident against you.
• Use your own test accounts wherever possible.
• Give us reasonable time to fix it before publishing. We suggest 90 days, and we are happy to agree a different timeline with you. We will not use a disclosure deadline as a reason to threaten you.
• Do not degrade the service for other people while testing.

A machine-readable pointer to this policy is served at /.well-known/security.txt, following the standard convention so automated tooling and researchers can find the right contact without guessing.