Security Model
How Ocalt separates your credentials, isolates your namespace, keeps connected machines outbound only, and limits what any single mistake can reach.
Only use your own Ocalt credentials
Never enter an API key, a Client key or a password at another person's request. A common scam is to persuade someone to install the OcaltQL Client and sign it in, either with their own credentials so the scammer can use their machine, or with credentials the scammer supplies so they can reach a namespace that is not theirs.
Connect a machine only with credentials that belong to you, and never share your API key or your Client key with anyone. If you think a key has been seen by someone else, rotate it from your account.
Principles
One credential, one job
Signing in, running scripts and connecting devices each use their own credential, so replacing one never breaks the others.
Separate, not filtered
Every namespace is its own space with its own network. Other namespaces are not blocked from yours; they are not attached to it at all.
Outbound only
A connected machine dials out to Ocalt. Nothing on it listens on a public interface.
Checked where it counts
Input is validated by the runtime itself, whatever a browser or client has already checked.
Your credentials
An Ocalt account holds three kinds of credential. Each is meant for one purpose and is replaced independently of the others.
| Credential | What it is for | How it is protected |
|---|---|---|
| Account password | Signing in to Ocalt Accounts and the apps you use through it. | Stored as a one-way bcrypt hash when you register, reset or change it. Changing it needs a code sent to your account email as well as your current password. |
| OcaltQL API key | Scripts and programs calling the OcaltQL API. | Carries no sign-in rights. Rotating it requires your account password and takes effect immediately; your devices are not affected. |
| Ocalt Client key | Your machines and the OcaltQL Client. | Rotated on its own, behind your account password. Rotating it never affects your scripts, and rotating your API key never affects your machines. |
Members of a business act through a key that belongs to their membership alone. It cannot be used as a personal credential, and it stops working the moment the membership is revoked. Credentials are compared in constant time, so they cannot be discovered by measuring how long a comparison takes.
Signing in
- Progressive lockout. After three consecutive failed sign-ins the account is paused for five minutes. Continued failures lengthen the pause to fifteen minutes, thirty minutes and an hour. After eight, the account stays locked until its password is reset, and a reset link is sent to the account email automatically.
- Password reset. A reset link is valid for thirty minutes and can be used once. Asking for one never reveals whether an email address has an Ocalt account. Completing a reset lifts any lock.
- Password change. A six-digit code is sent to the account email and is valid for ten minutes. Five wrong codes cancel it. When the change completes, every other signed-in device is signed out.
- Sessions. A session is held in a cookie that page scripts cannot read and that is only ever sent over HTTPS. It ends when you sign out and expires after 42 days. Your account lists every signed-in device, and any of them can be signed out from there.
Scripts and the API
- API failures cannot lock you out. Wrong or outdated API and Client keys are limited on their own, separately from sign-in. A machine still holding a key you have since rotated is refused, but it can never lock your account, the pause never lasts longer than an hour, and a valid key is never held back by it.
- Bounded execution. Every script runs within limits on execution time, loop iterations, nesting depth, outbound fetches and memory, set by your plan and adjustable within it from Control & Config.
- Your own endpoints. A Site Mode endpoint is anonymous until your script decides otherwise. OcaltQL gives you the tools to decide: account sessions for your own users, a constant-time comparison for shared secrets, and signed outbound webhooks, so the system receiving your request can verify it came from your namespace.
- Input you collect. Constraints declared on GATHER are enforced in the browser for immediate feedback and checked again by the runtime, so a value that bypasses the browser is still refused.
Namespace isolation
Every Ocalt account has its own private namespace. Nothing inside it is visible to any other account, and nothing outside it is visible from within it.
Sandboxed code does not get the real network. It gets a network of its own: its own loopback, its own address range and its own name resolution, containing only your things. This is not a blocklist. Another namespace is not blocked from yours; it is not attached to yours at any point, so there is no route to block. 127.0.0.1 inside your namespace is your own loopback, and nothing of Ocalt's is listening on it.
Connected machines
- The connection is outbound. The OcaltQL Client dials out to Ocalt and holds the connection itself. Nothing listens on a public interface, and the Client's own settings page is reachable only from the machine it runs on.
- A machine belongs to one account. It is bound to the account whose credentials it holds, and it acts only for that account.
- Use a Client key. Sign machines in with your Ocalt Client key rather than your password, so changing your password or rotating your API key never disconnects them, and a lost machine can be cut off by rotating one key.
Sharing
Nothing in your namespace is public unless you share it. A shared link is created explicitly for one file, and you can stop sharing it at any time.
Reporting a security issue
If you believe you have found a vulnerability, or that your account has been accessed by someone else, contact us through Support. Change your password and rotate your keys straight away if you suspect your account is compromised.