What Hushgate protects

Your upstream keys

A connector credential is stored encrypted under a key that only exists inside the confidential VM. The database holds ciphertext. A copy of the database is not enough to read a credential.

Your request contents

The gateway reads a request body only when a rule needs it. It never writes a body, a header value, or a credential to a log. An approval email carries the digest of a body and never the body.

What you can check

The gateway answers a challenge with signed AMD SEV-SNP evidence. The evidence binds three values: the challenge you chose, the TLS key you are talking to, and the exact release that is running.

Run the verifier yourself. It picks its own challenge and repeats every check against the pinned AMD root key.

What Hushgate does not protect against

A policy you wrote that allows the wrong call. Hushgate enforces what you wrote, so a rule that allows more than you meant will allow it.

A service that behaves differently from its documentation. Hushgate checks the request, not what the service does with it.

Loss of both passkeys and the recovery kit. Nobody can recover the workspace key, so the stored data stays unreadable.

What we do not claim

Hushgate holds no third-party security certification. Owned prose follows a documented project profile based on ASD-STE100, and the project is not certified against that standard.

The beta is best effort. There is no availability promise and no recovery time promise.