Privacy Policy

1. Who we are

Agent Vault is a product of Self.xyz, operated by SocialConnect Labs, Inc. dba Self Labs, a Delaware corporation (“we”, “us”). For data you store in Agent Vault we are the controller: we decide what is collected and why.

Privacy enquiries and data-protection correspondence both reach us at legal@self.xyz. We have not appointed a separate data protection officer, and we have not appointed an EU or UK representative under Article 27 of the GDPR. If you are in the EEA or the UK and need to reach us about your data, use the address above.

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.

Product analytics runs on our legitimate interest rather than on consent, and we would rather say that plainly than bury it. It is limited deliberately: no profile is built, the identifiers are random rather than derived from your account, and every event name is declared in advance from a fixed list, an undeclared one is dropped whole. The properties are not all declared, though, and we will not pretend otherwise: alongside the declared ones the analytics library attaches its own, the page URL, a coarse device type, screen size, library version and similar, and those are kept, because they are what makes an event interpretable. Each is reduced by what kind of thing it is, and the sensitive-key rules apply to them too. Not anonymous, though, and the word matters here: the identifier is random and never linked to your account, but it is kept in a cookie and in local storage so that repeat visits from the same browser can be counted as one, and §8 discloses the IP address and user agent that travel with it. That is pseudonymous device-level personal data. We should be straight about what the design costs: because the identifier is not tied to an account, we have no way to exclude a particular person from it, there is no account-level opt-out we could honour, and we will not offer one we cannot enforce. Blocking the analytics domain in your browser, or a content blocker, is what actually works today.

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 av_card_1_number_u7x2k. 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, not your real card number, security code, or password. There is one caveat we would rather state than imply. The agent can ask how many elements match a selector it chooses, and a page that echoes a filled value back into visible text or an attribute turns that count into an answer about the value, asked enough times. A hostile agent working against such a page is therefore not fully shut out; closing that is tracked as issue #348. The catalog it fetches carries more than the tokens, though, and that travels the same path: your internal account id, which each token also ends with, the labels you gave your addresses and logins, each login’s site reduced to a bare host — and every additional sign-in site you authorised for that login, on the same terms — 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. Where a card is not narrowed to a list of sites, the catalog says that instead, as a flag: it names no host, and it is the answer to a question the absent hostnames cannot settle, since a card whose agent cards are all paused also has no sites. 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 whose viewer is already CONNECTED 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.
• An agent can also cause data to be written, not just read. If you grant its key the power to create a login in your vault, which is off by default and switched on one key at a time, the agent can sign you up for an account on a site and save the result. It does not choose the password and never receives it. We generate the password in our backend, encrypt it, and hand the agent only a mock token, so the value exists in our storage and in the site’s, and in no model context anywhere. It is not displayed in the dashboard either, because nothing in the product reads it back out. The agent supplies the site and the username, which are stored readable as above; it cannot add extra sign-in hosts, that stays something only you can do. A key you scoped to specific logins can still sign you up, and the login it creates is added to that key’s own list — otherwise it would have made a credential it could never use. Only that one: signing you up never puts anything else on that list, and what else is on it stays yours to set from your dashboard. The list stops at fifty entries, after which its signups are refused. Every such write is capped per day per account, emailed to you, and written to your activity feed.
• Two-factor setup is the one place a secret travels the other way. If an agent is completing a site’s authenticator setup, the site has already printed the seed on a page our proxy is rendering. The agent tells the proxy which element holds it, never the value; the proxy reads it, sends it to our backend to be encrypted, and returns a mock token. So on this one path the seed does pass through the proxy, in that direction only, and only for a seed the site is showing on screen at that moment. It is not read back to the agent, and it is not sent back out to the proxy afterwards (§6). From the moment it is captured, that session is treated as having handled a real value: screenshots are blacked out for the rest of it, and the agent can no longer list the page’s frames or read their addresses. The selector-counting the agent needs to work a page at all still answers, as §4 describes.
• 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 see the agent machine’s 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 that machine’s public address. If you run the agent on your own computer that is your home network, typically a residential IP, which is deliberate: a datacenter IP is a strong bot signal that blocks many checkouts. If you run it on a cloud VM, a CI runner, or a hosted agent platform, the merchant sees that provider’s address instead, and it may well be a datacenter one. In either case the address of whichever machine runs your agent is disclosed to every site it 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.
• Unrelayed traffic may go out through a commercial proxy provider. A datacenter address is itself a bot signal, so the proxy can be configured to route egress that is not going through your machine via a third-party upstream proxy instead. Where a deployment is set up that way, that provider carries the browser’s traffic, sees every host it dials, and is the address the merchant sees rather than ours. It is a per-deployment setting rather than something every installation does, which is how §8 lists it. The hosts reached are recorded and disclosed to you either way (§2), and the same TLS reasoning applies: on an https:// checkout the provider carries encrypted bytes, and a plain http:// page has its fill refused before anything of yours is typed into it.

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 checks that the reference is a vault token identifier and that the last four digits are four digits, so a card added through the normal flow cannot put its number in the token field.

That is a statement about the normal flow, and we will not overstate it into a guarantee the database enforces. The record also carries free-text fields, the cardholder name and the brand, and those accept any string. A caller who invokes our card-creation API directly, or a client that maps its fields wrongly, could therefore put a card number in one of them and we would store it. Nothing in the product does that, and the fields are not treated as card data anywhere; but the protection is the shape of the normal flow rather than a rule enforced on every field, and you should know which of the two it is.

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.

Where that happens matters. The proxy runs on Confidential GKE nodes, which keep a machine’s memory encrypted while it is in use by the processor. So for the seconds your card number is in the proxy’s memory, an attacker with access to the host, or to the physical RAM, reads ciphertext rather than your card number. That is hardware doing the work, not a promise about our code.

Our software also carries a separate attested checkout path, described in §4, whose isolated enclave is not deployed. Were it deployed, it would take the vault token inside, reveal the number there and type it from within, so that not even we can see it. As things stand every attested checkout is refused before any card changes hands, and the paragraph above is still what happens to your card. When that changes we will say so on this page.

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, so a card added here is stored in their test tenant. Use test cards only.

Whose certification is whose. Basis Theory holds PCI-DSS Level 1 certification. That certification is theirs and it describes their vault. It is not a certification of Agent Vault, and we make no PCI, SOC 2 or ISO claim about ourselves.

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, so we never send a stored seed back out to the proxy and a proxy session can never generate a future code from one we hold. There is one path in the other direction, and it is the only one. When an agent completes a site’s authenticator setup for you (§4), the site itself prints the seed on the page the proxy is already rendering; the proxy reads it there and passes it to us to encrypt. So a seed can travel proxy → backend at the moment it is created, and never backend → proxy afterwards. We would rather draw that arrow than let the shorter sentence stand. 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.

A password we generated, we cannot show you. Where an agent created the login (§4), the password was produced in the backend and written into encrypted storage without ever being rendered, so no screen in the product displays it and no support request can produce it. A data export gives you the same fields as any other login, telling you the account exists and that its password is one nobody has read. If you want a password you can type yourself, reset it on the site and save the new one.

Many sites’ terms restrict credential sharing and automated access. Connecting a site, and letting an agent connect one for you, 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 and may process data at edge locations outside the United States; each provider that acts as our sub-processor is bound to us by a data processing agreement. That is not true of every recipient in the table below, and we will not imply it is: a merchant or login site your agent visits, the merchant’s own payment processor, and a webhook endpoint you configure are not our sub-processors, we have no agreement with them about your data, and their rows say so. We will tell you the processing locations recorded for any provider we do contract with, on request at legal@self.xyz.

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.

Where a provider transfers personal data out of the EEA, the UK or Switzerland, we rely on the Standard Contractual Clauses adopted by the European Commission, together with the UK Addendum where the transfer is from the UK, except where that provider is certified under the EU – US Data Privacy Framework and its UK and Swiss extensions, in which case we rely on that certification. Ask us at legal@self.xyz for the mechanism recorded for a particular provider and a copy of the relevant safeguards.

10. Retention, and how far deletion reaches

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 through the normal flow 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, and as §5 explains those descriptive fields accept any text, so the protection is the shape of that flow rather than a rule enforced on every field. 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. Card numbers, security codes, passwords, one-time codes, identity fields and addresses are all released the same way: only to a live, non-revoked API key bound to your account. So revoking a key stops resolution immediately.
• One narrow exception, worth knowing: a challenge handoff whose viewer was already attached when you revoke the key keeps driving the paused session, because that live connection is not re-checked against the key while it lasts. It is narrower than we used to state: a handoff link that has not been opened yet, and an attached page whose connection drops and tries to reconnect, are both refused, attaching reloads the key and stops on a revoked one. So revocation does close the handoff route, except for a viewer already holding the connection. 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, and no cross-site tracking anywhere. We do not sell your data, we do not share it with advertisers, and nothing here follows you to other sites. We do run product analytics on our own website and in the checkout proxy, through PostHog. §2 and §13 say exactly what is sent, and §8 gives PostHog its place in the provider list.
• 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 revealed inside our proxy process during a fill (§5). That process runs on Confidential Compute hardware, so its memory is encrypted in use, but it is not attested to anyone: nothing proves to you which code was running. The separate enclave of the attested-checkout path is a different thing again and is not deployed. Do not read the FAQ’s mention of an enclave as either of the stronger claims. The key-encryption key protecting your credentials is held by us. Our vault account is an evaluation tenant. No method of storage or transmission is perfectly secure. Do not put data into this that you cannot afford to lose.

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 a handful of values, and we will not put a single number on it because the count depends on your history here. 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 we do not delete them either, so a returning browser can be carrying all six theme entries at once. Clearing your site data removes them.

Next 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, which also means a shared browser accumulates one such key per account that has ever enabled it there. Turning the notification off removes that account’s entry.

Another 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.

Separately from local storage, the analytics code uses your browser’s session storage. If you navigate away before the analytics library has finished loading, the events captured up to that point are parked under av_analytics_pending so they are not lost, up to 50 of them, each holding the event name, its sanitized properties and the time it happened. They are removed once sent, and session storage is discarded when you close the tab, so nothing here outlives the tab that wrote it.

All of them 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 legal@self.xyz 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 in force as of the effective date shown at the top.

16. Contact

Privacy and data protection: legal@self.xyz
General support: legal@self.xyz
Legal notices: SocialConnect Labs, Inc. dba Self Labs, a Delaware corporation, at legal@self.xyz

See also the Terms of Service.