What guards your memory.

ODSR (On-Device Secret Redaction) checks every vault write before storage and embedding. A recognized secret is replaced with a marker showing its kind and last four characters. The surrounding memory remains usable without keeping the secret.

It recognizes API keys and secrets from major providers (OpenAI/Codex, Stripe, AWS, GitHub, Slack, Supabase, Fly.io), JWTs, private keys, labeled Social Security numbers, and payment-card numbers. Card checks use the Luhn algorithm to help avoid mistaking ordinary IDs for card numbers. Unknown-shape high-entropy tokens are flagged, not redacted. New formats are not guaranteed to be caught.

The check runs in the TypeScript ingestion code and in PL/pgSQL inside the database, including direct table writes. Release checks compare their outputs against the same fixtures. A mismatch stops the release.

ODIT (On-Device Identity Tokenization) applies to covered memory paths where enabled. It does not discover every identity by scanning arbitrary text, or protect every prompt, capture or audio upload. Applicable writes can be held in a sealed quarantine lane pending the required controls. Stored queue encryption does not establish that plaintext never reached the service or that later processing never uses a provider.

A signed-in account owner controls device approval. Which controls apply depends on the account policy, client and operation. Tokenization, signing and passing content unchanged are different outcomes. These controls are not universal anonymization or end-to-end encryption for synced content.

PostgreSQL row-level security scopes vault rows to your account. Access checks run in the database, rather than relying only on the app to filter results.

User-scoped database functions are not executable by client roles. Clients reach them only through an authenticated proxy that binds every call to the identity of the token that made it.

Team and Enterprise plans are coming soon. Their planned sharing controls are distinct from personal vault access. See Pricing for availability.

Becki clients use scoped tokens, not a master credential:

Install tokens authorize ingestion from one machine. Becki stores their SHA-256 hashes, not their raw values. They expire after 90 days with sliding renewal. You can revoke one from your account page; rotating it immediately invalidates the previous token.

OAuth access tokens for hosted connections expire after roughly one hour and renew through refresh tokens. Sign-in happens in your browser against your own account; Becki clients never see your password.

Credential handling depends on the client and provider setup. Native Keychain-backed storage, external CLI account stores and credentials you configure have different boundaries. Keep credentials out of work prompts and memory, protect local account files, and grant tools only the access they need.

Vault content passed to an AI model is fenced and labeled as untrusted data. Instructions found in a stored memory are data, not commands for the model reading it. This is a defense against prompt injection, not a claim that every attack is impossible.

Recognized secrets are redacted before storage, as described above. Unknown formats may be flagged rather than redacted. Install tokens are stored as hashes only; OAuth credentials are not stored in plaintext.

Vault content is not used for cross-tenant analytics. Administrative access is limited to providing or supporting the service or complying with the law, as described in the Privacy Policy. Deleting a memory removes it from retrieval. Revoking a device cuts its access at the next request.

Every release runs a security preflight. It checks edge-function authentication, access to user-scoped database functions, hardcoded secrets, and agreement between the two redaction implementations. A HIGH finding stops the release.

Questions, or something you think we missed? support@becki.io.