Security

The security model

For readers who want the technical background. With KiLocker, one party — and only one — is trusted with your key. Everyone you allow can use it; none of them ever holds it.

Who holds what

Party	Holds the key	Sees prompts and responses
Key owner	Until it is stored. It is never shown again.	No — a record of each use, never its content.
Pass holder	No, in no form they can read.	Their own, as always.
KiLocker	Yes, encrypted at rest.	No. They never pass through it.
Provider	It issued the key.	An ordinary request.

Party

Holds the key

Sees prompts and responses

Key owner

Until it is stored. It is never shown again.

No — a record of each use, never its content.

Pass holder

No, in no form they can read.

Their own, as always.

KiLocker

Yes, encrypted at rest.

No. They never pass through it.

Provider

It issued the key.

An ordinary request.

What we guarantee, and how we check

Guarantee	How it is enforced or checked
The key is never readable outside KiLocker	Stored with AES-256-GCM under its own data key; data keys are wrapped by AWS KMS and bound to the key they protect. No API, console page or log line returns it — owners see only a short hint and a fingerprint.
Nothing the pass holder receives reveals the key	On every change, a test records everything the client receives during a real request and searches it for the key. The same check runs against the live providers.
The key only goes to the real provider	The server’s identity is checked against Mozilla’s set of public root authorities, pinned to a version we choose — not the machine’s trust store. An intercepting proxy on the pass holder’s network gets nothing.
A leaked pass is useless on its own	A pass works only together with the credentials of the app it was issued to.
Only the calls you would expect	Each provider has an allowlist of hosts, methods, paths and headers. Anything else is refused, or dropped and reported back to the caller.
Limits hold at the moment of use	Checked every time the key is used, and every use counts — retries included. Revoking also stops a request that is still uploading.
It fails closed	If any check fails, or KiLocker can’t be reached, no key is added and the caller gets a clear error — never a fallback.
Every use is on record	Time, pass, host, method, path and size — never content. Notifications to platforms are signed with HMAC-SHA256 and time-stamped.
Standard cryptography only	Built from standard, widely reviewed algorithms — the same ones HTTPS already relies on. Nothing home-made.

Guarantee

How it is enforced or checked

The key is never readable outside KiLocker

Stored with AES-256-GCM under its own data key; data keys are wrapped by AWS KMS and bound to the key they protect. No API, console page or log line returns it — owners see only a short hint and a fingerprint.

Nothing the pass holder receives reveals the key

On every change, a test records everything the client receives during a real request and searches it for the key. The same check runs against the live providers.

The key only goes to the real provider

The server’s identity is checked against Mozilla’s set of public root authorities, pinned to a version we choose — not the machine’s trust store. An intercepting proxy on the pass holder’s network gets nothing.

A leaked pass is useless on its own

A pass works only together with the credentials of the app it was issued to.

Only the calls you would expect

Each provider has an allowlist of hosts, methods, paths and headers. Anything else is refused, or dropped and reported back to the caller.

Limits hold at the moment of use

Checked every time the key is used, and every use counts — retries included. Revoking also stops a request that is still uploading.

It fails closed

If any check fails, or KiLocker can’t be reached, no key is added and the caller gets a clear error — never a fallback.

Every use is on record

Time, pass, host, method, path and size — never content. Notifications to platforms are signed with HMAC-SHA256 and time-stamped.

Standard cryptography only

Built from standard, widely reviewed algorithms — the same ones HTTPS already relies on. Nothing home-made.

What you trust us with

KiLocker holds your key and could, in principle, use it. That is the one trust you place in us instead of in everyone who needs the key. We only ever send it to its provider, every use is on a record you can see and export, and we don’t buy or sell API capacity.

Known limits

Only keys sent in a request header are supported, not keys inside the request body.
A pass holder sees their own requests and responses, as with any API call — just never the key.
Calls through KiLocker depend on KiLocker being up; if it isn’t, they fail with a clear error.

Reporting a vulnerability

If you think you have found a security problem in KiLocker or this site, email contact@kilocker.com with “Security” in the subject, and tell us what you found and how to reproduce it.

We reply within seven working days and keep you updated until it is fixed.
Test only with your own accounts and keys. Don’t access other people’s data, and don’t disrupt the service.
Give us reasonable time to fix it before you publish. We will credit you if you wish.
We won’t take legal action over research done in good faith within these rules.

Machine-readable: /.well-known/security.txt

Questions or ideas

If you have any thoughts on this, we’d love to hear them — contact us.

The method is patent pending.