Trust Center

How MeowPass handles your secrets.

The reference for how we store, encrypt, and serve your secrets, and how we authenticate every request. Written for the engineer deciding whether to trust us with production credentials.

Encryption Authentication Audit logs Infrastructure Reliability
Overview

Read the internals, then decide.

MeowPass is a CLI-first secret manager and AI credential gateway. This page documents how it works today: the mechanisms, the trade-offs, and what is still on the roadmap. Where we haven't built something, we say so on this page rather than implying otherwise.

AES-256-GCMTLS 1.3OAuth 2.0 + PKCEPasskeysAudit logsVersion historyApprovalsLeast privilege
Security

How access to a secret is controlled.

A secret is encrypted before it reaches the database. Every request that reads one is authenticated, checked against the caller's scopes, and written to the audit log. Some actions can also wait on a human to approve them before they run.

  • Encrypted at rest with envelope encryption (AES-256-GCM)
  • Transport over TLS 1.3
  • Version history on every change
  • Immutable audit logs (actor, action, resource, IP, time)
  • Scoped permissions checked on every request
  • Approvals for sensitive tools, gated on a human
ClientCLI · Web · AgentTLS 1.3in transitMeowPass APIAWS Lambda (Go)AES-256-GCMat restNeon Postgresencrypted rows
Authentication

We don't store passwords.

Identity is handled by WorkOS AuthKit, so sign-in, MFA, and passkeys live with a dedicated identity provider instead of in our database. MeowPass validates the tokens it issues and maps them to your account; it never sees a password.

WorkOS AuthKit
Hosted identity provider
OAuth 2.0 + PKCE
Web: hosted authorization code
Loopback auth-code
CLI: mp login via local callback
Passkeys, MFA
Phishing-resistant sign-in
Sessions, devices
Review recent activity
Scoped API keys
SHA-256 hashed, for CI and agents
  • The dashboard signs in through AuthKit's hosted UI (OAuth 2.0 authorization code with PKCE)
  • The CLI catches the code on a local loopback; tokens live in your OS keyring and refresh on their own
  • Passkeys, TOTP MFA, and social sign-in (GitHub, Google) come from WorkOS
  • Password reset and MFA recovery are handled by WorkOS
  • Active sessions and recent devices are visible in your account settings
  • CI pipelines and AI agents use scoped, revocable API keys
Rendering diagram…
CLI sign-in over a browser loopback, using OAuth 2.0 auth-code with PKCE against WorkOS AuthKit.
Encryption

Two layers: transport and storage.

In transit, everything is TLS 1.3. At rest, each secret gets its own data key (a DEK), and that DEK is encrypted by a key-encryption key (the KEK) held by the server. This is textbook envelope encryption. The practical benefit is rotation: rotating the KEK re-wraps every DEK without ever touching the ciphertext of a secret.

DATA PATHSecret valueplaintextAES-256-GCMencrypt with DEKCiphertextstored in PostgresKEY PATHDEKper-secret data keyAES-256-GCMwrap with KEKWrapped DEKstored in Postgressame DEKserver-managed KEKKMS-bound in production

How it works

  • DEK: a per-secret data key that encrypts the value with AES-256-GCM
  • KEK: a server-held key that wraps each DEK. KMS-bound in production
  • Postgres stores ciphertext next to the wrapped DEK, never plaintext

What this is not

MeowPass is not zero-knowledge. It is not end-to-end encrypted, and it does not encrypt on the client. On an authorized request, the server decrypts the secret to serve or inject it, which means we hold the KEK. We put that here plainly so you can decide with the real picture.

Secret Lifecycle

What happens to a secret, from write to runtime.

You write a secret. It's encrypted before storage and a new version is recorded. When your app or CLI asks for it, we authorize the request, decrypt server-side, and inject the value into the process environment. Every read lands in the audit log.

Rendering diagram…
A secret's path from write to runtime.

In your workflow

The same three commands you'd run anyway.

$ mp login # sign in through WorkOS
$ mp pull # sync this project's secrets
$ mp run -- npm run dev # inject them into the process at runtime

Values are passed to the child process as environment variables. They aren't written to disk.

Infrastructure

A small stack, on purpose.

Fewer moving parts means a smaller attack surface and a system we can actually reason about end to end. The Go API runs on AWS Lambda behind API Gateway, backed by Neon Postgres. The dashboard and this site are static.

Rendering diagram…
The components that actually run in production today.
AWS Lambda
Go API (arm64), API Gateway, us-west-2
Neon Postgres
Encrypted secret storage
CDN
Static dashboard and site
WorkOS
Identity and JWKS validation
Audit trail
Every secret and broker action
Dodo Payments
Billing. We don't store card data
Availability

Current status.

A component-level view of system health. These states are static today. A public status page with historical uptime and a live API is on the roadmap, and these cards are wired to read from it once it ships.

APIOperational
DashboardOperational
CLIOperational
AuthenticationOperational
WebsiteOperational
Privacy

What we collect, and what we don't.

We keep the minimum needed to run the product and maintain an audit trail. We don't sell your data, and we don't read your secret values for analytics.

Collected

  • Account email and name (via WorkOS)
  • The secrets you store, encrypted at rest
  • Audit logs: actor, action, resource, IP, timestamp
  • Product analytics to improve the app

Not collected

  • Your account password (it lives with WorkOS)
  • Your secret values, for analytics or training
  • Payment card data (it goes to our payments provider)
  • Anything we sell to third parties

Retention and deletion

  • Deleting a secret removes it from the database
  • Audit logs are kept for the life of the account
  • Deleting your account removes your vaults and audit records. Email support@meowpass.dev
  • Export your data any time from the CLI
AI Credential Brokering

Agents get access, not the key.

When an agent needs a provider credential, it asks MeowPass instead of holding the key itself. Sensitive tools can require a human to approve first. The real key is injected into the upstream request server-side, so the agent works through a scoped, short-lived credential and never sees the raw one. Every brokered call is logged.

Rendering diagram…
Brokered access: optional approval, a scoped short-lived credential, and an audit entry per call.
Brokered
Raw keys never reach the agent
Approvals
Optional gate on sensitive tools
Short-lived
Scoped, revocable credentials
Audited
Every brokered call is logged
Incident Response

What we do when something breaks.

If something goes wrong, the order of operations is: contain it, tell the people affected, and write up what happened. This is the process we follow.

  1. Detect and triage

    target: ack within 24h

    We triage reports and alerts and assign a severity.

  2. Contain

    Limit blast radius by rotating or revoking affected credentials and cutting off access paths.

  3. Investigate and fix

    Find the root cause and ship a fix. Keep the evidence for the postmortem.

  4. Notify

    Tell affected users what we know, without over- or under-stating the scope.

  5. Postmortem

    Publish the root cause and the specific changes we made so it doesn't recur.

Responsible Disclosure

Found a bug? Tell us first.

We welcome good-faith security research. If you think you've found a vulnerability, report it before you disclose it publicly and give us a reasonable window to fix it.

Security contact

security@meowpass.dev

Send steps to reproduce, the affected endpoints, and a proof-of-concept if you have one. A PGP key for encrypted reports is available on request.

Safe harbor

We won't pursue or support legal action for good-faith research that respects user privacy, avoids service disruption and data destruction, and gives us a reasonable window to fix the issue before it goes public.

Roadmap

Not built yet.

None of these exist today. They're on the roadmap, and they stay marked Planned here until they're real and independently verified. We don't list a certification we don't hold.

Planned
SOC 2 Type I
Point-in-time controls report
Planned
SOC 2 Type II
Controls effectiveness over time
Planned
ISO 27001
Information security management
Planned
Penetration testing
Independent third-party testing
Planned
Hardware security modules
HSM-backed key protection
Planned
Customer-managed keys
Bring your own encryption keys
FAQ

Straight answers.

Honest answer: in principle, yes. MeowPass isn't zero-knowledge. Secrets are encrypted at rest, but the server holds the key-encryption key and decrypts on an authorized request to serve or inject the value, so an engineer with production access could reach data. We keep that surface small with least-privilege access, scoped credentials, and an audit trail on every secret and broker action. We never read your secret values for analytics.