Privacy Policy

1. Who we are

Agent Vault is a product of Self.xyz, operated by [LEGAL ENTITY NAME], registered at [REGISTERED ADDRESS] (“we”, “us”). For data you store in Agent Vault we are the controller: we decide what is collected and why.

Privacy enquiries: [privacy@…]. Data protection contact: [DATA PROTECTION CONTACT]. Representative for EU/UK data subjects, where one is required: [EU/UK REPRESENTATIVE, IF REQUIRED].

This policy covers the Agent Vault web app and dashboard, the checkout proxy that fills forms on your behalf, and the backend that stores your vault. It does not cover the merchant sites and login sites your agent visits — those are independent controllers with their own policies.

2. What we collect

Almost everything below is data you deliberately put in, because the product cannot fill a checkout form with data it does not have. We do not buy data, and we run no advertising and no third-party tracking. We do run product analytics on our own website — pageviews and a few product events, with no profile of you attached to them (see §13). We also keep our own operational telemetry about agent sessions — see below.

3. Why we use it, and our lawful basis

Where the GDPR or a comparable law applies, these are the purposes we process your data for and the legal grounds we rely on.

You can withdraw consent for browser push notifications at any time from your browser or the dashboard; that does not affect processing carried out beforehand.

4. How agents and the proxy use your data

This is the part of the product that most affects your privacy, so it is worth stating precisely.

• Your agent is issued mock tokens — placeholder strings such as SAPu7x2kc1000000. It types those into forms. The agent, its model context, its logs, and anything it sends to its own model provider contain the mock token and never your real card number, security code, or password. The catalog it fetches carries more than the tokens, though, and that travels the same path: your internal account id, the labels you gave your addresses and logins, each login’s site reduced to a bare host and whether it has 2FA, and for each card its brand, last four digits and full expiry month and year. Where a card is governed by an agent card in allow-list mode, the catalog also carries that allow-list’s merchant hostnames — the sites you decided that agent may spend at, which says something about you that the other fields do not. All of it is what a human needs to tell one saved item from another, and your agent needs the same; but it reaches the agent’s context and its model provider alongside the tokens.
• The real values are substituted by our checkout proxy, which drives a browser that runs on our infrastructure. To be clear about what your agent can do with that browser: it does drive it — it navigates, clicks, and types through our SDK, and it can take screenshots, which we redact before returning them. What it cannot do is read the page’s contents directly (script evaluation is refused) or read back any real value the proxy substituted. So your agent controls the session and sees a redacted view of it, and no interface hands it a stored value. One gap we would rather state than gloss, and how it closed: because your agent drives a real keyboard, it could once send editing chords — select-all, copy, paste — to a field the proxy had already filled and carry that value elsewhere without ever reading it back through our API. Once a session has had a real value substituted into it, the proxy refuses every modifier chord that could reach the clipboard, with a stable “clipboard blocked” error. Ordinary typing, Tab, Enter, Escape and the arrow keys are unaffected, and three navigation shortcuts stay allowed by name — Shift+Tab, Alt+Left and Alt+Right — because they cannot copy anything. The rule is deliberately broad rather than a list of blocked shortcuts, because every list we wrote had another spelling past it (issue #252). So we keep your secrets out of your agent’s view and out of its clipboard — in a session it otherwise fully controls. The proxy resolves a mock token to a real value only after our backend has authorised that specific fill. Every kind of value is checked against a live, non-revoked API key that belongs to your account — with one exception, a challenge-handoff page already open when the key is revoked (§12, issue #212). A security-code prompt is not an exception: the card is re-authorised after the code arrives, so revocation stops it. Login fills are additionally locked to the site the credential was saved for. A card-number fill is additionally checked against merchant policy, spending limits, and any approval you require — but only when an agent card governs that card; a card filled directly, with no agent card linked to it, is subject only to your plan’s account-wide cap on the NUMBER of payments in a rolling 30-day window (2, 10 or 30 depending on tier) — a count, not an amount, so it bounds how often such a card can be used and never how much it spends. If you want a card governed, put it behind an agent card.
• A security code on its own is checked, but not counted. When a saved-card checkout asks only for the security code and never for the number, that fill still runs the key, account, pause and merchant checks, and it can still pause for your approval — the code is as sensitive as the number, so it is gated the same way. What it does not do is consume your spending limits or record a transaction: those happen on the card-number fill, so that a card and its code together count once rather than twice. The practical consequence is that a code-only checkout can be stopped by a pause, an allowlist, or an approval, but it is not bounded by your spending limits.
• The merchant or login site receives the real value, because that is the point: a real purchase needs a real card number, and a real sign-in needs a real password. Once submitted, that data is governed by the receiving site’s own privacy policy, not this one.
• Often the merchant’s payment processor receives the card, not the merchant. Many checkouts embed card fields hosted by a payment provider — Stripe, Adyen, or similar — in a frame belonging to that provider, and our proxy fills those frames directly. Your card number, its expiry, and the security code you enter for that purchase then go to that provider under their privacy policy and the merchant’s agreement with them. We have no relationship with them and do not choose them; the merchant does. (This is separate from the Stripe entry in §8, which covers only our own subscription billing.)
• The proxy browses whichever sites your agent directs it to, and those sites see whatever your agent submits.
• By default they also see your own IP address, not ours. When an agent runs through our SDK, the proxy relays the browser’s network traffic back to the machine running your agent and dials the merchant from there — so the merchant sees your network, typically a residential IP. This is deliberate: a datacenter IP is a strong bot signal that blocks many checkouts. It does mean your IP address is disclosed to every site your agent visits. One path is an exception. A default session prefers the relay rather than requiring it, and an attested checkout runs the merchant page in a separate hardened browser that cannot use the relay the way your own agent’s browser does — so on that path the merchant sees our datacenter address, not yours, even with default settings. Only a session that requires the relay (tunnel: true) is refused rather than allowed to proceed that way. That path is not in service today and is refused before it runs (§5); it is described here so the disclosure is already right if we do turn it on. The hosts it reached are recorded and disclosed to you (§2). We have since built a relay that carries the hardened browser’s traffic back through your machine too, which would remove this exception — but it is not enabled in any environment, so the datacenter address above is what would happen today. Pass tunnel: true if you need the relay to be mandatory rather than preferred. For an https:// site — which is every real checkout — the relayed bytes are TLS-encrypted and your machine cannot read them. On a plain http:// page we now refuse the fill: no card number, security code, password or identity value is substituted into a page that is not TLS-protected, and the agent is told the page is insecure. Such a page is also no longer relayed through your machine — plaintext traffic leaves from our datacenter instead — so it cannot put anything of yours on your own network in the clear. You can turn the relay off (tunnel: false or SELF_AGENT_PAY_TUNNEL=0), in which case sites see our proxy’s datacenter IP instead; the same happens automatically if the relay cannot be established.

5. Card data specifically

Card numbers are held by Basis Theory, a PCI-DSS Level 1 certified tokenization vault, and not in our own database. When you add a card, the number is typed into an input hosted by Basis Theory inside your browser and sent directly to them; we receive back an opaque token reference and store that. The write path rejects anything that is not a vault token identifier, so no card number added today can land in our database.

If adding a card fails after that step — a validation error, or a network failure while saving the rest of the record — the card is already in the vault and we end up with no reference to it. Nothing in our system then points at it, which also means our own deletion tooling cannot find it. Tell us if a card save failed and you want it removed; until then it sits in the vault unreferenced. Cleaning those up automatically is tracked as issue #214.

For completeness: our database schema still defines columns that held encrypted card numbers, and one that held encrypted security codes, under the design that preceded the vault. No code writes any of them any more, and scheduled jobs purge the remaining pre-vault rows so the columns can be dropped altogether. Until that finishes, we would rather tell you the columns exist than claim a schema that cannot hold a card number.

Where the number is revealed. To type your card into a merchant’s checkout form, something has to turn the token back into digits. Today, wherever card filling works at all, that happens inside our checkout proxy process — there is no configuration in which some other component reveals it: the proxy calls the vault, holds the number in memory, and types it into the merchant page. It is not written to our database, our logs, or the session audit trail. A deployment that is not configured to fill cards refuses the fill outright, before any number is retrieved; that is the only other outcome.

Our software also contains a second path — the attested checkout of §4 — which hands the vault token to an isolated, attested enclave that reveals the number and types it in its own browser, so that not even we can see it. We are describing code, not a service you can use. On this hosted service no such enclave is deployed, so an attested checkout here is refused before any card is handed over. (The path can be exercised elsewhere — a developer running our software can point it at an enclave of their own — but that is someone else’s deployment, not this one, and this policy describes only this one.) So the paragraph above is what happens to your card, and it will stay that way until we say otherwise here. We do not claim the enclave protection today.

How long it stays in memory. Not just the moment of typing: once a value has been filled, the proxy keeps a copy in that session’s memory until the session ends, so it can recognise and blank out the value if it would otherwise appear in a screenshot or an error message returned to your agent. The retention is what makes the redaction possible — the proxy cannot scrub a value it no longer holds — but it does mean the plaintext lives in proxy memory for the session, not for a single fill. It is never persisted anywhere. The same applies to a password or security code the proxy fills.

That in-proxy reveal is switched on only where the vault’s private key has been provisioned for the deployment. Without it, the proxy refuses every card fill outright rather than falling back to anything weaker, so your card number is never revealed anywhere — and your agent cannot complete a card checkout at all. The two are deliberately tied together, so a half-configured deployment cannot exist.

Vault status. Our vault account with Basis Theory is currently an evaluation tenant, not a production plan. Basis Theory’s PCI-DSS Level 1 certification is theirs, and describes their vault; it is not a certification of Agent Vault, and we make no PCI, SOC 2, or ISO claim about ourselves. Treat this deployment as a preview and do not store a card you rely on.

6. Site credentials specifically

We store the passwords and one-time-code seeds for the sites you connect. There is no way for an agent to sign in on your behalf otherwise, and we would rather say so plainly than bury it.

• Passwords and TOTP seeds are encrypted at rest with AES-256-GCM. Records written under the current scheme use a per-record data encryption key, itself encrypted (wrapped) by a key-encryption key, and their ciphertext is cryptographically bound to your account so it cannot be decrypted in the context of another user.
• Older records may not have both of those properties. Credentials saved before the per-record-key and account-binding changes are still readable under the previous shared-key scheme, and ciphertext written before account-binding decrypts without that binding check. A record is re-keyed only when the secret itself is re-entered — editing a login’s site, username or note leaves the existing ciphertext exactly as it was. So retyping the password (and the one-time-code seed, if you use one) is the way to move an old login onto the current scheme; changing anything else will not do it.
• The key-encryption key is held by us, as an environment secret in our backend. It is not in a hardware security module or a third-party key-management service today. Our deployment prefers a dedicated key-encryption key, but where one has not been provisioned it falls back to the same secret used for legacy data — so the separation between the two is a deployment property, not something this page can promise. A sufficiently deep compromise of our backend environment could reach stored credentials, and we are not going to describe that risk as eliminated.
• Usernames, site URLs, and your notes are stored in readable form so the dashboard can list your connected sites.
• Decryption happens only in our backend, and only for a fill your agent is authorised to perform. What leaves the backend depends on the field. A password is passed to the proxy as plaintext for that fill. A two-factor seed is not: it is decrypted inside the backend, used there to derive the current six-digit code, and only that short-lived code is sent on — the seed itself never reaches the proxy, so a proxy session can never generate a future code from it. As with a card number (§5), whatever value does arrive is kept in that session’s memory until the session ends so it can be redacted out of screenshots and error text; it is never persisted. Neither is returned to the agent or written to the audit trail.

Many sites’ terms restrict credential sharing and automated access. Connecting a site is your decision and your responsibility — see the Terms of Service.

7. Session records and the live screencast

Every agent session produces an audit trail so you can see what was done in your name. It records the merchant host, the API key used, timings, which token kinds were filled, denials and their reasons, and the outcome — never a substituted value.

When a site raises a challenge the agent cannot pass (a CAPTCHA, a two-factor prompt), the session can be handed off to you. We email you a link; opening it streams a live video of the proxy’s browser to that page and relays your clicks and keystrokes back, so you can finish the step yourself.

• The link is the credential. The handoff page is deliberately outside the signed-in area, because you are usually on a phone where you are not logged in — so it authenticates on the token in the link alone, and does not additionally check that you are signed in. The token is not spent by being used once: it stays valid until the handoff expires or settles, so that a dropped mobile connection can reconnect to the same session. For that whole window, anyone holding the link can attach and take over the live checkout. Treat a handoff email like a password reset email.
• Those frames are unredacted pixels of the page in front of you. They are sent only to the one attached viewer socket, drawn to a canvas, and replaced by the next frame.
• No frame is stored. Screencast frames never reach our database, the audit trail, a receipt, our logs, or anything the agent can read.
• The token is issued for one specific session belonging to your account, expires, and admits only one viewer at a time. The proxy re-checks the session, page, and owning account before it attaches.

8. Sub-processors and other recipients

We do not sell your personal information and we do not share it for advertising. We use the following providers to run the service. Our own infrastructure runs in the United States; several of these providers operate globally distributed networks, so the precise processing location for each is [PROCESSING LOCATIONS PER PROVIDER], to be confirmed against each signed data processing agreement.

We also fetch daily currency reference rates from a public exchange-rate API in order to check foreign-currency totals against your limits. That request is made by our server and contains no personal data.

We may disclose data where we are legally required to, or to establish or defend legal claims. If we are ever involved in a merger or acquisition, your data may transfer as part of that transaction; we would tell you before it became subject to a different policy.

9. International transfers

Our infrastructure runs in the United States, and the providers in §8 are US-headquartered, though several operate globally distributed networks. If you are in the European Economic Area, the United Kingdom, or Switzerland, using Agent Vault means your data is transferred to the United States.

The transfer mechanism we rely on for each provider — Standard Contractual Clauses, the EU – US Data Privacy Framework, or another lawful basis — is [TRANSFER MECHANISM PER PROVIDER], to be confirmed against each signed data processing agreement. Ask us at [privacy@…] for a copy of the relevant safeguards.

10. Retention — and what deletion does not reach

This section describes what our system does today, including where it falls short of what a reader would reasonably expect. Each shortfall names its tracking issue.

11. Your rights and how to exercise them

Depending on where you live you may have the right to access your data, receive a portable copy, correct it, delete it, restrict or object to processing, and complain to a supervisory authority. We do not discriminate against you for exercising any of them.

12. Security measures

What follows is what our system actually does. We hold no security certification, and we do not claim one.

• Your secrets are never returned to the agent. It works with mock tokens; the substitution happens in a browser process your agent drives but cannot read out of — script evaluation is refused, and its screenshots are redacted. That is a narrower statement than “the agent never has them”, and deliberately so: the agent controls the session. The keyboard route out is closed, though — once a real value has been substituted, every clipboard-capable chord is refused (only Shift+Tab and Alt+Left/Right survive, which move focus and copy nothing), so a value it cannot read cannot be copied out with a shortcut either. §4 describes the path and the guard (issue #252).
• Card numbers are held in a PCI-DSS Level 1 vault (Basis Theory’s certification, not ours), tokenized directly from your browser. A card added today cannot land in our database — the write path takes a vault token id, never a number, though it does store the non-secret metadata in §2 alongside it. Encrypted numbers from the pre-vault design may still sit in legacy rows until the purge job clears them (§5).
• Security codes are not stored — they are entered by you per purchase and held only in the proxy’s memory, for that session, on the same redaction-driven terms as a card number (§5). As with card numbers, a legacy column is still being purged (§5).
• Credentials are encrypted at rest. Records written under the current scheme use a per-record key wrapped by a key-encryption key and are bound to your account, so they cannot be decrypted for someone else. Older records may have neither property until they are re-keyed (§6).
• Every fill is authorised server-side and fails closed. Every value — card, security code, password, one-time code, identity field, address — is released only to a live, non-revoked API key bound to your account, so revoking a key stops resolution immediately.
• One exception to that, worth knowing: a challenge handoff page that was already open when you revoke the key is not cancelled by the revocation — it is authorised by its own short-lived link rather than re-checked against the key, so completing the bank prompt on it can still land on the paused checkout until the link is used or expires, minutes at most. If you revoke a key to stop something in progress, do not then complete an outstanding handoff. Making revocation settle open prompts is tracked as issue #212.
• A security-code prompt is not an exception. Entering the code after you revoke the key does not get it to the checkout: the card is re-authorised once the code arrives and before it is released, so a revoked key, a paused card, or a changed merchant policy stops it there. We previously listed this alongside the handoff, which overstated how weak revocation is.
• The spending controls do not cover everything, and we would rather say so. An agent card’s merchant allowlist, pause, and approval threshold govern card and security-code fills. Its spending limits are narrower still: they bind card-number fills only, so a checkout asking for the security code alone is never counted against them (§4). Pausing an agent card does not stop that agent from resolving a saved password, a one-time code, an identity field, or an address — those are governed by key scope, account binding, and (for logins) the site lock, but not by pause. To stop everything at once, revoke the API key. Extending the pause control to the other secret types is tracked as issue #181.
• API keys are stored hashed and can be revoked instantly. Scoping is optional: you may restrict a key to chosen cards and logins, but a key created with the scope controls left on “All” has access to all of them. Identity fields and addresses are not per-key scopable at all — any live key on your account can resolve them. Scope your keys deliberately; the default is not the narrow one.
• The audit trail is built from token kinds, not values, and the storage boundary rejects card-shaped strings and unknown token kinds. It is not, however, structurally incapable of holding a secret: the host, field, reason and detail slots accept free text, so the guarantee rests on what our own service writes into them rather than on a rule the database enforces.
• No advertising or third-party tracking anywhere, and no analytics on our website. Our own aggregate telemetry about merchant-site breakage is described in §2 and carries no identifier for you.
• Traffic between you, our services, and our providers is encrypted in transit with TLS. Traffic to a site your agent visits is encrypted when that site is https:// — which is every real checkout — and a plain http:// page is refused rather than filled, so a real value is never typed into a document that is not TLS-protected (§4).

What we are not claiming. The card number is currently revealed inside our proxy process during a fill (§5); the isolated, attested enclave described in our marketing FAQ is not deployed. The key-encryption key protecting your credentials is held by us. Our vault account is an evaluation tenant. This is a preview environment, and no method of storage or transmission is perfectly secure. Do not put data you cannot afford to lose into it.

13. Cookies and local storage

We set two kinds of cookie: one to sign you in, one to count visits. For signing in, our authentication provider sets an encrypted session cookie, and during sign-in and token refresh a short-lived workos-access-token cookie may also be set, which the app reads once and then immediately clears. Both are strictly necessary for the service to work. The second kind is the analytics cookie described in the next paragraph.

We set no advertising or cross-site tracking cookies, and nothing we set follows you to another website. Our product analytics does set one first-party cookie holding a random device identifier, so that two pageviews in the same visit are not counted as two visitors. It is not shared across sub-domains, it is not tied to a profile, and it is described in full below.

No third party sets a cookie through our site, with one exception you have to visit deliberately: our Stripe demonstration page (/stripe-demo) loads Stripe’s own script from js.stripe.com and mounts a card field that Stripe, not we, renders. Stripe sets its own cookies there for fraud and device recognition, governed by Stripe’s privacy policy rather than this one. The card details you type there go to Stripe, never to us; what comes back to the page is Stripe’s token metadata — a token id, the card brand and the last four digits — which the demo simply displays. We do not send it anywhere or store it: it lives in the page until you navigate away. No other page on this site loads that script, so if you never open the demo, no third-party cookie is ever set.

Your browser’s local storage holds up to five values. Three are display preferences with no personal content: your light/dark mode (av_mode), your visual style (av_aesthetic), and your accent colour (av_accent). If you used this site before those keys were renamed you may still be carrying their predecessors — sap_mode, sap_aesthetic and sap_accent. We read them so your theme survives the rename, but we never write them again, and clearing your site data removes them.

The fourth is the desktop-notification opt-in, and it does contain personal data: the key is sap.desktopNotifications.<your account id>, so your account identifier is written into your browser’s storage and stays there. It is scoped that way deliberately, so that on a shared browser a later sign-in does not inherit someone else’s opt-in. Turning the notification off removes the entry.

The fifth belongs to our product analytics (ph_…_posthog), and mirrors the cookie described above: a random device identifier and the state the SDK needs between pageviews. It is not your account id and it is not linked to one.

All five stay on your device except as described in the analytics paragraphs below — nothing else reads them back to us — and clearing your browser’s site data removes all of them. Your API keys are deliberately never written to browser storage of any kind.

What the analytics actually collects. Pageviews and a small number of product events. It is configured against its own defaults, deliberately: no session recording, no autocapture of clicks or form fields, no heatmaps, no scroll or performance properties, no error capture, no surveys or experiments, and no feature flags. URLs are reduced to a route template before they are sent, so a path carrying an identifier is reported as its shape rather than its contents, and query strings and fragments are dropped. It creates no person profile and we never associate the device identifier with your account. On the token-gated pages — the ones you reach through a token-bearing link, including the live card-code page — it never starts at all.

Because we load web fonts from Google Fonts, Google receives your IP address and user agent whenever a page loads. See §8.

14. Children

Agent Vault is not directed at children and is not for anyone under 18. We do not knowingly collect personal data from children. If you believe a child has given us personal data, contact [privacy@…] and we will delete it.

15. Changes to this policy

We will update this page as the product changes — in particular as the gaps flagged in §5 and §10 are closed. When we make a material change we will update the effective date at the top and, for changes that affect how we handle data you have already given us, notify account holders by email before the change takes effect.

This document is a draft pending legal review and is not yet in force.

16. Contact

Privacy and data protection: [privacy@…]
General support: [support@…]
Postal: [LEGAL ENTITY NAME], [REGISTERED ADDRESS]

See also the Terms of Service.