How Qaldy keeps things locked down

Five promises that hold for every app, the parts that keep them, and where to read the proof. Plain words first, details one page deeper.

Anyone can describe a tool and have it running in minutes. The question for a company is what that tool can do once it is running, and who answers for it. Qaldy is built around one claim you can test:

Every app runs in a sandbox that can't reach the internet or read its own secrets unless the owner allowed it. The tests that check it are published, with the date and place they last ran.

The five promises#

App code never sees a secret. Keys are sealed on the way in and opened only by the gate, for one call at a time. See The gate and write-only secrets.
An app can't reach anything its permissions don't name. Outbound traffic is closed by default and opened one address at a time. See The sandbox.
Only people the share graph allows can open an app. Sharing is a graph, checked at the gate on every request. See Permissions and roles.
Every action lands in a tamper-evident log. A hash chain you can verify yourself. See The audit log.
The company owns it. The workspace, its apps and its keys belong to the company, with access that can end on a date. See Approvals and the Trust Score, Your team and Plans and the spending cap.

One request, start to finish#

A request goes from a person's browser to the gate, then to the sandbox where the app runs. Anything the app sends out comes back through the gate, which checks it against the app's permissions and adds the key. — A person opens an app: the gate checks, the sandbox runs, and anything leaving goes back through the gate.

A person opens an app's address. The gate asks the sharing graph whether this person may open this app. If not, they get a 403 and no app code runs.
If yes, the gate passes the request to the runtime host with a signed note of who is asking, for which app version.
The runtime host loads the app into an isolate: a sandbox with no network of its own and no secrets in it.
When the app wants to send a message or call an API, its only way out is back through the gate. The gate looks up the app's permissions, refuses anything not on the list, adds the key for the one allowed call, and scrubs the key from the reply.
Every allow and every refusal is an audit row, and the City draws a parcel or a barrier.

What this does not claim#

Honest limits are part of the design. The threat model lists each one with its status:

A channel an app is allowed to use can still carry data: an app allowed to post to a Telegram chat can post anything to that chat. That is why each permission names its destination in a sentence a person reads before approving.
The audit chain proves that rows were not edited quietly. Signed daily checkpoints narrow what someone with full access to the database could rewrite, but events after the newest checkpoint are covered only if you stream the log out, and the locked copy of each checkpoint is not on the pilot yet. See The audit log.
The recorded proofs ran on a development machine. A job that runs read-only checks against the live cell exists, and no result of it is published yet. See Proofs.
When the API is down, apps people already opened keep working for a while and the spending cap never loosens, but webhooks and first visits do not. See When the control plane is down.
Billing is Mock, the spending cap has not been timed on the live pilot, and data residency cells are Planned. See Plans and the spending cap and Kazakhstan.