LLM Hangar / Security

Security

How access, keys and data are handled. Updated .

LLM Hangar provisions GPU infrastructure inside your own cloud account and hands you a private endpoint. That shape decides most of the security model: the model, the disk, the network and the endpoint are yours, and the platform's job is to act in your account with the least access that gets the job done, and to prove what it did.

Where your prompts go

Requests travel directly between your client and the endpoint on your instance, over HTTPS with a valid certificate. They do not pass through LLM Hangar's servers. We do not proxy, store, log or train on prompt or response content, and the architecture means we could not read it if we wanted to. There are no sub-processors for prompt data: the only party that handles it is your own cloud provider, under the agreement you already have with them.

Access to your cloud account

Each provider is linked with its own delegated-access mechanism, and every link is verified live against your account before anything is stored.

Stored credentials are envelope-encrypted: each record has its own data key, wrapped by a KMS root key. Plaintext exists only transiently inside the worker that talks to your provider and is never written to logs, API responses or the database in the clear. Unlinking crypto-shreds the credential. The full linking procedure is in connect your cloud account.

Endpoint keys

Each deployment has one endpoint key. It is shown once, stored only as a hash, and checked by the gateway on your instance. Rotate it, or delete the deployment, and the old key stops working immediately.

Audit log

Every action we take in your account is written to a timestamped log: the plan of what will be created before it exists, each resource as it is created, and the sweep after a destroy. The log is exportable as JSON and kept after teardown for the period your plan includes, so you can show exactly what ran, where and when. The same record is what the EU AI Act's record-keeping duties for deployers ask for when you self-host a model.

Verified teardown

Deleting a deployment, whether you asked for it, a budget cap fired or a self-destruct timer expired, does not stop at a delete call. The teardown checks with your provider that the resources are actually gone before the deployment is reported destroyed, and keeps re-checking until that is confirmed. Budget caps and timers are described in budget caps and auto-destroy.

Data residency

Deployments run in the region you choose. The EU-only option pins every resource of a deployment to EU member-state regions and keeps it there. The platform itself (accounts, deployment metadata, the audit log) is hosted in Germany. What we hold, and with whom, is listed in the privacy policy and on the dated sub-processors page; a data processing agreement is available on request. How this compares with EU-hosted LLM APIs is laid out in EU-hosted LLM API providers compared. We do not claim that an EU region of a US cloud provider is outside the reach of that provider's home jurisdiction; what we can say is that no additional party handles your prompts because you use LLM Hangar.

What we do not claim

LLM Hangar does not currently hold a SOC 2 or ISO 27001 certification. The controls above are described so that you can evaluate them directly; the audit log and your own cloud console let you verify them.

Reporting a vulnerability

If you believe you have found a security issue, email [email protected]. We acknowledge reports promptly and will keep you informed while we fix the issue. The same contact is published at /.well-known/security.txt.