Security
What the system actually does.
This page is not a badge wall. Ahel is an early product, and the honest version of a security page is a description of the mechanisms that exist in the shipped code, followed by a plain list of what does not exist yet. Here is both.
Where your credentials live
Every credential in ahel is yours — we never supply a key. 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 credential’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 credentials page show you which key is stored without decrypting anything.
There is no endpoint that reads a credential 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 credential.
What travels over the link
The gateway is an OAuth-authenticated MCP endpoint: every call answers as the account that signed in, and only for that account’s own gateway. There is no path from one tenant’s link to another tenant’s anything.
Credential 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 sandboxed pod — and the response that returns to your agent carries the tool’s answer, never the key. The link’s own tools can search the catalog and change what your gateway serves; not one of them can read, write, or reveal a stored credential.
Sandboxed servers
Community MCP servers that only run as local processes are served from single-use pods on our infrastructure, and the pod is the security boundary:
- Each pod runs one server for one account, as a non-root user, with no cluster credentials mounted — it cannot see or speak to the platform it runs on.
- Its network egress reaches the public internet only; our databases and internal services are unreachable by network policy.
- Your keys enter it as environment variables of your pod alone, and the pod is destroyed after roughly thirty minutes idle.
- The set of servers eligible for this is a hand-curated allowlist, chosen by publisher trust — never scraped from the catalog.
Receipts, not stories
Two append-only ledgers record what actually happened: every gateway call from your agents, and every touch of a stored credential — 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.
What does not exist yet
Honesty cuts both ways, so here is the current list of things we do not have:
- No SSO. Sign-in is a magic link or Google. There is no SAML or enterprise single sign-on for teams.
- No audit export. The ledgers are permanent and visible in the product, but you cannot yet export them as a file or stream them into your own tooling.
- Account deletion goes through email. You can remove items and delete credentials yourself — a deleted credential is gone immediately — but full account deletion is a mail to karl@ahel.ai rather than a button.
When one of these ships, this page is updated to say so. Until then it stays on the list above.
Where the data sits
Application data is hosted on infrastructure in the European Union (Germany). How we handle personal data is in the privacy policy and terms; who we are is on the about page.
Questions about anything on this page? A person answers.
Ask on the contact page