Incident response
What happens when something goes wrong, who does it, and when you hear from us. Written to be checked against, not to reassure.
What counts as an incident
Two kinds, handled by the same process at different speeds. A security incident is unauthorised access to customer data, a credential exposure, or a defect that allowed one workspace to read another's. An availability incident is the service being unable to answer visitors, take a message, or accept a sign in.
A degraded dependency that the product routes around — vector search falling back to keyword retrieval, for instance — is not an incident. It is reported on the status page and watched.
How we find out
- Readiness probes check the database, rate limiting, vector search and object storage on every request to the health endpoint.
- The public status page reports the same probes plus whether scheduled background jobs have run when they should have.
- Application errors are collected when error monitoring is configured by the operator.
- Audit log entries record every API key change, webhook change, public API write and rejected single sign on assertion.
- A report from a customer or a security researcher, at the address below.
What happens, in order
- Contain first. Revoke the credential, disable the endpoint, or roll back the deploy. Preserving evidence comes second to stopping the bleeding, and rolling back is preferred over patching forward.
- Assess scope. Which workspaces, which data, and over what window. The audit log and the runtime event record are the source, not recollection.
- Notify. Affected customers are told what happened, what data was involved, what has been done, and what they should do. Within 72 hours of confirming a personal data breach, and sooner where the answer is already known.
- Fix, with a test. A fix that ships without a test that would have caught the defect is not finished.
- Write it up. What happened, why it was possible, and what changed so it is not possible again.
What we will not do
- Wait for a complete picture before telling you something happened. A first notice that says what is not yet known is more useful than a late one that is complete.
- Describe an outage as planned maintenance.
- Close an incident without the fix that prevents a repeat, or without recording why no fix was possible.
Reporting something
Email links@orhanai.com with what you found and how to reproduce it. Reports are acknowledged within one business day.
Security researchers acting in good faith — no data exfiltration beyond what is needed to demonstrate a finding, no service degradation, no access to another customer's data once the defect is proven — will not be pursued.