Security model

This page describes what MyAPIKeys actually does, including the parts that are trade-offs rather than wins. A credential store that is vague about its own limits is not one you should put credentials in.

How a secret is stored

master key (KMS, never in the database)
        │
        ▼  wraps
random data key, one per credential version
        │
        ▼  AES-256-GCM, with authenticated data
ciphertext  ──  bound to "myapikeys:secret:<credential id>:v<version>"

Controls

Envelope encryption: Each credential version gets its own random AES-256-GCM data key. That key is wrapped by a master key held outside the database. Compromising one stored data key exposes exactly one version of one credential.
Record binding: Each ciphertext is authenticated against the credential id and version that produced it. A ciphertext copied from one credential into another, or rolled back to a superseded version, fails to decrypt.
Tenant isolation: Row level security on every table, enforced by the database rather than the application. A conformance suite runs the cross-tenant attacks explicitly and fails the build if any of them succeeds.
Append-only audit: The audit table has no UPDATE or DELETE policy for any user role. The account owner cannot rewrite their own history either.
Step-up authentication: Revealing, exporting, revoking, deleting, or rotating production requires re-entering your password. Grants are single-use and expire in five minutes, so a stolen session can browse metadata but cannot extract a secret.
Opaque failures: Every decryption failure returns the same error. Distinguishing a wrong key from tampered data would be an oracle.
Secret redaction: Structured logging redacts known credential shapes and sensitive field names. Secrets are not supposed to reach a logger at all; this is the backstop for the day one does.
Service-role confinement: The key that bypasses row level security is used in exactly one flow: the scheduled health sweep, which has no user session to act under.

What is not claimed

SOC 2

MyAPIKeys is not SOC 2 certified. The architecture is built with that audit in mind, but no audit has been performed and none is claimed.

Zero-knowledge

The server can decrypt your credentials. That is a deliberate trade: a server that cannot read a secret cannot rotate it at the provider or push it into your deployment targets, which are the two things that make this more than a password manager. If you want a vault the server cannot read, you want a different product, and that is a reasonable thing to want.

Last four characters

The final four characters of each secret are stored unencrypted so a list of credentials is legible to a human. Everything else is ciphertext.

Automated rotation everywhere

Most providers do not expose an API for creating keys. Where one does not exist, MyAPIKeys says so and guides you through doing it by hand rather than pretending.

Reporting a vulnerability

Email security@myapikeys.com. Please include enough detail to reproduce. We will acknowledge within two business days and will not pursue legal action against good-faith research.