Privacy

The short version

We keep the minimum needed to run a bring-your-own-key proxy: who you are according to Google, the vendor keys you connected (encrypted), the hashes of the bearer tokens you issued, encrypted MCP OAuth registration and grant state, and a log of which tools you called. We do not keep the arguments you sent, and we do not keep the data your vendors returned beyond a short cache in memory.

Signing in with Google

Google is the only sign-in method. When you sign in we receive your Google user id, your email address, and, when Google provides them, your display name and profile photo URL. We do not receive your Google password, and we do not ask Google for access to your mail, files, calendar or contacts.

What we store

Your account. One row holding:

• the sign-in provider (always google) and Google's stable user id for you,
• your email address,
• your display name and profile photo URL, when Google supplied them,
• account status and plan tier,
• when the account was created and when you last signed in.

Your vendor credentials, encrypted. Each connected vendor key is stored as ciphertext, never as plaintext. Each credential gets its own randomly generated data key, that data key is itself encrypted under a master key held only in the running service's environment, and both layers use AES-256-GCM. The ciphertext is cryptographically bound to your account id and the vendor slug, so a row copied onto another account simply fails to decrypt. Alongside the ciphertext we keep the vendor slug, the health status of the key, what tier and capabilities the last probe measured, and the timestamps of the last check and the last rotation.

Your bearer tokens, hashed. A token is shown to you once, at the moment you create it. What we keep is a SHA-256 hash of it, a short non-secret prefix so you can tell two tokens apart in a list, the name and description you gave it, and its created, last used, expiry and revoked timestamps. We cannot show you a token again, because we do not have it.

MCP OAuth client registrations, encrypted. A registered client record can contain its client id and secret, redirect addresses and optional client metadata. It is not linked to your Google account and does not contain your Google identity or Google tokens. It has no automatic expiry because the same client registration must keep working across service restarts, and deleting your account does not remove it.

Subject-linked OAuth authorization state, encrypted. When an MCP client uses browser authorization, the grant record includes the Google ID token and Google access and refresh tokens; encrypted local token-reference metadata points to it. These records are keyed by random references rather than your account, so deletion cannot safely select only your rows. New or refreshed records get no more than 365 days of storage lifetime and become unusable immediately when deletion commits. After expiry, the storage layer treats them as absent and deletes them if that reference is presented again. Expired ciphertext that is never referenced can remain in the primary database or a routine backup, so there is no fixed physical erasure date. While a record remains, the authorization server uses it only to identify and reject a replay. We also keep a one-way hash of the provider identity, the deletion time and a deletion generation. Every earlier local access or refresh grant is rejected, which stops an old credential from recreating the deleted account. The marker cannot be used to recover your Google identifier.

Your IP allowlist, if you set one. This is optional and off by default. If you choose to restrict access, we store the IP addresses or ranges you enter, and we use them only to accept or refuse your own MCP requests. Leaving it empty means any address may use your tokens.

A call log. One row per MCP tool call, holding: your account id, the token id that made the call, the tool name, the capabilities resolved, the vendor slugs that answered, the latency in milliseconds, the status (ok, error, or refused), the size of the response in bytes, the request id printed in that response, an error message if there was one, and the time of the call. Error messages are scrubbed of any credential value used on that call before they are written, and truncated.

Sign-in rate limiting. To stop somebody creating accounts in bulk, we record a row per sign-in attempt containing a bucket label. For a new sign-up that label contains the requesting IP address; for a returning account it contains the account id instead. These rows are not deleted automatically today.

What we do not store

• Plaintext vendor keys. Anywhere. Not in the database, not in logs, and not in error messages: every message that could carry a key is scrubbed against the values decrypted for that call before it is written or returned.
• Tool arguments. The call log records that you called a tool, not what you asked it. The symbols you are researching are not written down.
• Vendor responses. They are not persisted. The only copy that outlives a request is a short-lived cache entry held in the memory of the running service.
• Google product data. We do not ask for or store mail, files, calendar, contacts or other Google product content. The identity fields and encrypted OAuth credentials listed above are the only Google values we retain.

The cache, and why it never crosses accounts

A vendor answer may be reused for a short time to avoid spending your quota twice on the same question. How long depends on the kind of data: 15 seconds for quotes and options chains, 5 minutes for price history, volatility state, crowd attention, borrow figures and news, 1 hour for macro series, filings, fundamentals and official short interest. Brokerage positions are never cached at all.

The cache lives in the memory of the running service and is lost on restart. It is partitioned per account by construction rather than by a filter: your entries live in a dict that only your account's handle can reach, and there is no function anywhere that takes both an account id and a cache key. Two accounts asking the identical question get two separate entries. A read that somehow found an entry belonging to another account raises an error instead of returning it.

Health checks are real vendor calls

To keep your tool list honest, the proxy periodically makes a small real request to each vendor using your key: when you save the key, when a live tool call reveals something about it, and on a background schedule (by default about every 15 minutes per key, longer where the vendor meters by the day, and about two minutes after a key was last seen failing because the vendor itself was down). These requests go to your vendor under your key and appear in your vendor's own logs and quota.

Who else sees your data

• Your vendors. They see the requests we make with your key, which is the point of the service.
• Google. They see that you signed in.
• Our hosting provider. The service and its database run on Railway.
• Nobody else. We do not sell data, we do not share it with advertisers, and we do not pool one account's vendor data to serve another.

Deleting your data

Revoking a bearer token cuts off the agent holding it right away. You can delete your account and the account-owned dashboard data linked to it yourself, from Account settings, under "Account data". You will be asked to type the address on the account to confirm. Deleting the account immediately and permanently deletes its stored credentials, its tokens, its call log and its IP allowlist, and signs you out. There is no undo. Routine database backups can hold deleted rows for a while before they age out (no fixed window is guaranteed), and operational logs reference the account by number only. If you would rather we do it, or you can no longer sign in, email [email protected] from the address on the account.

You can remove a vendor key from Sources, or revoke a token from Account settings, and both take effect at once. Deleting a single vendor credential removes its ciphertext and its wrapped key from the database. The call log rows recording that the vendor was used remain, because they hold no vendor data: only the slug, timings and status.

Security

Credentials are encrypted at rest as described above. Tokens are stored only as hashes. The MCP endpoint requires a bearer token on every request, and the browser session cookie cannot be used to reach it. Every request is resolved to exactly one account before any data is fetched, and the account is never something a tool argument can name.

No service is perfectly secure. If you find a problem, email [email protected] and tell us before you tell anyone else.

Changes

If this notice changes in a way that matters, the effective date above changes with it.

Contact

Questions, access requests, or deletion: [email protected].