Legal
Security
How this site is secured, how we handle the code and accounts we build for clients, and how to tell us if you find something wrong. Everything below describes what is in place today — not what we intend to do.
This website
Served over HTTPS only. HTTP requests are redirected, and the site sends HSTS with preload — once a browser has seen it, it will refuse to connect over plain HTTP at all.
It also sets X-Content-Type-Options, X-Frame-Options, a strict Referrer-Policy, and a Permissions-Policy that denies camera and location by default.
The REST API does not return user accounts to anonymous requests, and author archives are disabled — neither will hand out a username to someone probing for one.
What we build for you
Accounts are yours from the first day. Hosting, domains, payment gateways, cloud and model providers are registered in your name, not ours, and billed to you directly. We are never the account holder for something you depend on.
Where we need access to work, we take the narrowest role that does the job, and you can revoke it at any time without anything breaking. On handover we hand over — code, credentials, infrastructure — and remove our own access when you ask.
Credentials and keys
We do not ask for your passwords. Where a system supports delegated access — an invite, a scoped token, a service account — we use that instead.
API keys and secrets we hold for a live project are stored in the project’s own secret store or environment configuration, never in the codebase and never in a shared document.
Your data in a project
We work with the least data that answers the question. Where a build needs real records to test against, we prefer a sample or anonymised set, and we say so before anything is copied.
Client data stays in the client’s own infrastructure. We do not aggregate it, and we do not use one client’s data to build something for another.
Models and third parties
Where a build uses a model provider, we tell you which one and what goes to it before it is wired in. Model choice is a setting rather than a dependency, so a provider can be changed without rebuilding the work.
The same applies to any partner platform: you are told who is involved, and the relationship is in your name.
Keeping things current
Sites on our deploy-and-maintain service get their platform and dependencies updated as part of that service, and we watch for failures rather than waiting to be told.
A site we built and handed over is yours to maintain unless you have asked us to keep doing it. If you are unsure which applies to you, ask — it should never be ambiguous.
Reporting something
If you find a vulnerability in this site or in something we built, email connect@abata.tech with enough detail to reproduce it. We will confirm we have it, and we will tell you what we did about it.
We will not pursue you for reporting something in good faith. Please do not access data that is not yours, degrade the service for anyone else, or hold a finding back for leverage.
What we do not claim
We are a small studio, not a certified security vendor. We hold no ISO or SOC attestation and we will not pretend otherwise on a procurement form.
What we can tell you is exactly how a given system is set up, who has access, and where the data sits — and put it in writing for your review.
Contact
ABATA AI Private Limited, Bengaluru, Karnataka, India. Security questions and reports: connect@abata.tech.