Security

Every key you store in Ahel is yours. What you store is encrypted before it reaches the database. It is sealed under a data key minted fresh for that single write, and that data key is itself sealed under a master key held outside the database. Both layers are bound to your tenant and the key’s type, so a ciphertext moved into another row does not open. We store a four-character preview and a one-way fingerprint alongside it, which is what lets the keys page show you which key is stored without decrypting anything.

There is no endpoint that reads a key back out: you can store, replace, or delete, and the response carries a status, never a value. Every decrypt is written to an access log that records who asked and whether it opened, and never the value.

What is not true yet: the master key is an environment secret held in the cluster, not a key in a cloud KMS that our servers reach by federated identity. That is the next step, and until it ships, anyone who can read the cluster’s secrets can unwrap a stored key.

The Ahel connector is an OAuth-authenticated MCP endpoint: every call answers as the account that signed in, and only for that account’s own workspace. There is no path from one tenant’s link to another tenant’s anything.

Key values never cross the link, in either direction. When a served tool needs a key, Ahel attaches it server-side: a bearer or declared header for a hosted server, an environment variable inside a single-use pod. The response that returns to your AI carries the tool’s answer, never the key. The link’s own tools can search the catalog and change what your workspace serves; not one of them can read, write, or reveal a stored key.

Scripts in a pipeline you build run in single-use pods with no cluster access, and so do MCP servers that only run as local processes. The pod is the security boundary:

Two append-only ledgers record what actually happened: every call from your AI through the connector, and every touch of a stored key: who asked, whether it opened, never the value. Both are yours to read on the Activity page.

Failed calls are recorded the same way as successful ones. A call that errors leaves the same permanent receipt. It is not hidden.

Honesty cuts both ways, so here is the current list of things we do not have:

Your whole connector is one URL, so when it cannot be reached every tool in every AI client you use goes quiet at the same moment, and the first thing worth knowing is whether it is you or us.

There is no uptime number on this page, because nothing here measures or promises one. What there is: /api/health/live, public, which says whether the app is answering and which commit it is serving. It is the same endpoint our release job polls until it reports the commit it released, so a deploy that never landed turns a build red instead of staying invisible.