Security

How access, keys and data are handled. Updated 6 September 2026.

LLM Hangar creates GPU infrastructure in your cloud account and provides an endpoint protected by a key. This page explains the access you grant, where requests travel and how you can check the actions taken in your account.

Where your prompts go

With the default node-local gateway, requests travel directly between your client and your instance over HTTPS. The private edge runs in your own account. The optional hosted edge terminates TLS and proxies requests on infrastructure we operate in Germany, so prompts and responses pass through it.

Optional audit capture writes request records to a bucket you own. Metadata capture records digests and usage details; full capture also includes prompt and response content, subject to its size limit. Choose gateway placement and capture settings to match your data policy. See keys and audit capture and sub-processors.

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.

On AWS, a CloudFormation stack in your account creates one cross-account IAM role that trusts the platform account, bound with a single-use external ID minted per link attempt. We assume the role for an hour at a time, scoped to resources we tagged ourselves; delete the stack to remove the role. Sessions already issued can remain valid until they expire. No access keys are ever pasted.
On Nebius, a service account with an authorized key is scoped to a single project that you create for LLM Hangar workloads. Scope is the project, never the tenant.
On RunPod, an API key is verified against your account before it is stored.
On Verda, OAuth client credentials are verified by exchanging a token before they are stored; access tokens are short-lived and refreshed centrally.

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

A deployment supports named keys with individual request and token limits. Key material is shown once when created and is not returned by the key-list API. The access guide explains storage and enforcement.

Changes reach an edge gateway within seconds. On the default node-local gateway, the key collection is applied at the deployment's next start. Plan revocation around that behavior; do not assume that changing a key immediately updates a running node.

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. This is an infrastructure activity record. Whether your application needs additional records depends on its use and the obligations that apply to it.

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; gateway placement determines whether requests also pass through infrastructure we operate.

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 hello@llmhangar.com. We acknowledge reports promptly and will keep you informed while we fix the issue. The same contact is published at /.well-known/security.txt.