Security
Last updated: August 27, 2026
This page says what we actually do to protect your account and the access you hand to your agents — and what we do not have yet. If you found a hole, section 7 says where to send it.
1. Sign-in and sessions
Your session lives in an HttpOnly cookie bound to neolit.store, so no page script can read it. Requests that change something are checked against the origin they came from, which is what stops another site from acting as you. Passwords are stored as bcrypt hashes — we cannot read yours, and neither can anyone who reads the database.
2. The keys and logins you give an agent
Connected-account credentials and API keys are encrypted with AES-256-GCM before they are stored, and the encryption key lives in the server environment, not in the database next to them.
When an agent has to type a password into a site, the browser layer substitutes the value itself. The model never receives it, and it is not written to the run log — what the log shows is that a field was filled.
3. Isolation between accounts
Agents, conversations, notes, scheduled tasks and your tables sit behind row-level security enforced by the database itself, not only by application code. Every request runs under your identity, so a query that forgets a filter returns nothing rather than someone else’s rows.
4. What agents are stopped from doing
- An agent that fetches a URL cannot reach our internal network: private, loopback and link-local addresses are refused before the request is made.
- A site an agent publishes is scanned for vendor tokens first, so an API key that ended up in a page does not go public with it.
- Secrets are stripped from what an agent writes into its memory, so a password typed once does not survive as a note.
- The browser an agent drives runs in our own container, and its profile is bound to one workspace — it does not carry your logins into someone else’s session.
5. Payments
Card numbers never reach Neolit. Checkout happens on our payment provider’s own page; we keep only which plan was bought, the provider’s transaction id and your wallet balance.
6. Transport and browser hardening
Everything is served over HTTPS with HSTS. Pages are sent with nosniff, framing denied and a strict-origin referrer policy. A Content-Security-Policy is deployed in report-only mode while we finish enumerating the origins the app genuinely needs — it reports violations today, it does not block them yet.
7. Reporting a vulnerability
Write to support@neolit.store with “security” in the subject. Tell us what you found, how to reproduce it and what you were able to reach. We acknowledge within 3 business days and keep you posted until it is closed. The machine-readable version of this is at /.well-known/security.txt.
Please test against your own account only, do not run denial-of-service or heavy automated scans against production, do not read or change other people’s data, and give us reasonable time to fix before you publish. We will not pursue researchers who stay inside those lines.
8. What we do not have yet
We would rather say “not yet” than tick a box: there is no SOC 2 or ISO 27001 certificate, no paid bug bounty, no 24/7 on-call security team, and the content-security policy is not enforcing. Neolit is run by a small team, and production access is limited to it. If your procurement needs more than this, tell us what is missing and we will tell you honestly whether and when it will exist.
9. Contact
Security questions, or a report that does not fit the form above: support@neolit.store. What we do with personal data is in the Privacy Policy.