AutoPass Privacy Policy
Effective date: October 7, 2026. Version: 2026-10-07.
AutoPass is a password manager made of four parts: a Chrome extension, a desktop app for macOS and Windows, a web vault that runs in any browser, and a sync server. This policy explains what data each part handles, where it goes, and how to delete it. Mobile applications and new integrations may be in development; the disclosures for an optional feature apply when that feature is actually available and you choose to use it.
The short version: vault contents are encrypted on your device before they are synced. The sync server stores encrypted vault data it cannot read, plus the account information needed to sign you in, keep your devices in sync, share with people you choose, and (if you turn it on) check a second sign-in factor. AutoPass has no analytics, no telemetry and no advertising, and we never sell your data. The services the server runs on are listed under "Service providers".
Who runs the server
Syncing is optional. An account created in the extension or the desktop app stays on your
device and sends nothing anywhere until you turn on sync (at signup or later in Settings).
When you do, AutoPass syncs through the server you choose. Release builds suggest the
server at getautopass.com (the existing autopass-sync.fly.dev address also works); you can enter another one.
- If you run your own AutoPass server, you are the operator and decide how its data and logs are handled. We receive nothing.
- If you use the server we operate at
getautopass.comorautopass-sync.fly.dev, Endo Powersports LLC ("we") is the operator for that data, as described below.
Either way, the server only ever receives what is listed under "What the sync server receives". It cannot decrypt your vault.
Information you choose to store
Vault items can contain authentication information, names and contact details, payment and financial information, identity documents, medical records, secure notes and files, API credentials, private or secret keys, recovery codes, multiple identities and automation notes about your accounts. AutoPass handles these categories only as part of the vault features you use. Their contents are encrypted before syncing; the account and operational metadata the server can read are listed below.
What stays on your device
The extension, the desktop app and the web vault keep the following on your device:
- Your Secret Key, email address, server address and a device label (for example "Mac · extension"), so the device can unlock with just your master password. The device label is also sent to the sync server when you sign in, so you can recognise your devices in Settings > Devices (see below).
- If two-step verification is on and you trust the device, a random device token that lets this device skip the code step.
- An encrypted copy of your vault (the same ciphertext the server holds) and any changes waiting to sync, so you can use AutoPass offline.
- Your settings (auto-lock time, clipboard clearing, theme, and whether the optional Vault health checks below are on).
- Optional device unlock, if you turn it on: a platform-authenticator credential identifier, PRF salt and encrypted unlock bundle in browser storage for the web vault and extension; on macOS desktop, a per-account Keychain item and its seal time. These records contain password-equivalent unlock material protected by the device mechanism. Device unlock is limited to 14 days after master-password entry; see the Security page for revocation and offline limits. This is separate from storing the password itself.
- While unlocked, the decrypted keys needed to read your vault. In the extension these are held in browser session memory that is cleared when you lock, when auto-lock runs, or when the browser closes. In the web vault they are held in the page's memory and are cleared when you lock, reload or close the tab.
Your master password is never stored or sent anywhere. It is used on your device to derive keys and is then discarded.
What the extension reads in your browser
To fill and save logins, the extension's content script runs on web pages (http and
https) in the top-level frame only. It:
- Reads the address of the page you are on to find logins saved for that exact site.
- Detects login forms and, when you submit one, reads the username and password you entered so it can offer to save or update them. These values go only to the extension's own background process on your device. By default, saving or updating requires your confirmation. You can preapprove automatic saving of a generated password for a new account on an exact HTTPS origin, or for all HTTPS origins, in Settings. That approval applies only to new-account submissions using the password AutoPass generated; it does not silently approve updates to existing passwords. You can remove approvals. Unsaved capture candidates expire within two minutes or when the tab closes.
- Detects visible API-key, secret-key and recovery-code fields on the current site and can offer to save them into the encrypted vault. You choose the account and confirm saving. It does not harvest hidden secrets, crawl other pages or upload raw page content. Saved secret fields and automation notes are encrypted like other vault data.
- Reads relevant form structure, field labels and the page title to identify fields and name a login you choose to save. It also detects one-time-code, card and address fields for the corresponding filling features.
- Writes credentials or other saved fields into a form only after your fill action. Sign in and Open and fill can also submit a recognized sign-in form when automatic sign-in is enabled. Open and fill opens a saved website with a short-lived, one-use request; a redirect to another origin cancels that request.
- For passkeys, passes a site's passkey request (the site's domain, the account name the site suggests, and a one-time challenge) to the extension, which asks for your approval before creating or using a passkey. A small hook runs in the page itself to handle browser credential requests, with a separate extension bridge for approvals. Passkeys you save are stored as encrypted vault items.
- May check whether your computer is idle or the screen is locked, on your device only, to lock the vault automatically.
The extension processes the current page address and the form-related website content above on your device. It does not maintain a browsing-history log or upload general page content. Saved website addresses, login titles and fields sync only as part of encrypted items you choose to save.
When you copy a password or code, AutoPass writes it to your clipboard and, by default, clears the clipboard 90 seconds later.
If the AutoPass desktop app is installed, the extension also connects to it on your computer (Chrome native messaging). The desktop app can then send it a login to fill into the active tab; the extension fills it only if that tab's website is one the login is saved for. This connection never leaves your computer.
What the desktop app does on your computer
The desktop app runs the same vault as the web vault, plus:
- Quick Access (a keyboard shortcut) reads the name, identifier (macOS bundle ID or Windows program name) and, where the system allows, window title of the app in front, to suggest logins saved for that app. It types a login into that app only when you pick one. On macOS this needs the Accessibility permission, which you grant in System Settings. This information stays on your computer.
- AI agent sign-ins (off unless you turn them on in Settings > AI agents): an AI agent on your computer can request access to a selected site or app. You can allow one fill within five minutes, or repeated fills for 15 minutes. Grants are held in memory, bound to the requesting connection and verified browser link where applicable, and end on expiry, release, disconnect or disabling agent access. Allowed fills can include a one-time code and form submission. They do not return the username, password or code through the agent API. The agent can receive the selected login title, target, grant details, vault lock/browser connection status and the fill result; errors may reveal that a required field is missing. An agent with separately granted screen access may observe information visible in the destination app or site.
- The desktop app keeps your agent on/off choice in its data folder. It keeps up to 200 activity entries (time, the name the agent reports, login title, site/app and result) in memory until it quits. That self-reported name is not a verified identity. Browser account-creation saving approvals are separate from desktop agent permissions. Neither grants permission to accept contracts or incur charges at another service. Desktop identity/notes/signup/capture tools remain development work until released.
- It keeps a random token in its data folder so that only programs running as you on this computer (the AI-agent helper and the browser link) can talk to it, and it registers the browser link with Chrome and supported Chromium browsers. On macOS the Chrome registration folder is created even if Chrome is not installed.
Nothing in this section is sent to the sync server.
What the sync server receives
| Data | Why | Readable by the server? |
|---|---|---|
| Email address | Your sign-in name | Yes |
| Terms version, server-recorded acceptance time and whether accepted at signup or in Settings | Record the agreement you explicitly accepted; existing accounts are not backfilled as accepted | Yes |
| Encrypted vaults and items (titles, websites, usernames, passwords, notes, one-time-code secrets, passkeys, everything you store) | Sync between your devices | No, end-to-end encrypted |
| Encrypted keyset and wrapped vault keys | Unlock on a new device | No |
| SRP verifier and salt | Verify your sign-in without ever receiving your password | It cannot recover your password or keys from it |
| Key-derivation parameters (algorithm, iteration count, salt) and a Secret Key version tag | Let a new device derive your keys | Yes (not secret) |
| Your public key | Lets people you share with seal vault keys to you; anyone signed in to the server can look up the public key for an email address | Yes (not secret) |
| Item metadata: number of items and vaults, encrypted sizes, version numbers, when items were changed or moved to Trash | Sync and conflict detection | Yes |
| Encrypted attachments, with their exact sizes and how many each item has | Sync your files | Contents and names: No. Sizes and counts: Yes |
| Sharing: who is a member of which shared vault and their role, pending invitations (with the invited email address and the sealed vault key), share links (encrypted item copy, expiry, view count), and whether travel safety is on | Vault sharing and share links | Membership, roles, emails and dates: Yes. Vault keys and shared items: No |
| Account recovery, if you set it up: a second SRP verifier and your keyset and Secret Key encrypted under a key derived from your recovery code | Let you reset your master password with the recovery code | Cannot recover your code, password or keys from it |
| Device labels you sign in from, session tokens (stored only as one-way hashes), and when each session was created and last used | Keep you signed in; Settings > Devices | Labels and dates: Yes. Tokens: hashes only |
| Two-step verification, if you turn it on: your authenticator secret (encrypted with a key the server holds), the last code step used, your phone number (for text-message codes), backup codes (one-way hashes only), and trusted devices (token hash, device label, created / last used / expiry dates) | A second factor at sign-in | The authenticator secret can be decrypted by the server's operator; the phone number is readable; backup codes and device tokens are hashes only |
| IP address of each request | Rate limiting, sign-in lockouts and abuse prevention | Yes |
Rate-limit counters, failed sign-in history, sign-ins in progress and two-step sign-ins waiting for a code are short-lived. They are kept in the server's memory, or, where the operator uses Redis, in Redis: there the keys are one-way hashes of the email address and IP address, counters and timestamps are plain numbers, and every other stored value is encrypted with the server's secret. They expire on their own within minutes (failed sign-ins and code attempts count for 15 minutes).
The server's own request log records only the time, method, path, response status and duration of each request (share-link tokens are removed from paths). It never logs request bodies, tokens, phone numbers, codes or vault data. Where the log goes depends on the deployment: in the Docker Compose setup it rotates automatically (up to about 50 MB per service) together with the reverse proxy's access log, which also records client IP addresses; on Fly.io it goes to Fly's logging service.
Service providers (the server we operate)
The server we operate at getautopass.com or autopass-sync.fly.dev uses these providers. Their own privacy
policies apply to what they receive.
- Fly.io hosts the server and its database. Fly's network terminates HTTPS and passes requests on to the server over Fly's private network, so, as with any hosting provider, everything sent to the server passes through Fly's infrastructure (vault data stays end-to-end encrypted). The database is on an encrypted Fly volume.
- Upstash (through Fly.io) runs the Redis database that holds the short-lived counters and sign-in state described above: hashed keys, plain counters and timestamps, and encrypted values.
- Twilio sends text-message codes, only if you set up text-message two-step verification. Twilio receives your phone number and generates, sends and checks the code; it does not receive your email address or any vault data.
If you run your own server, you choose its providers; it uses Redis or Twilio only if you configure them.
Optional Vault health checks (off unless you turn them on)
Vault health always checks for weak, reused and http:// logins, and for logins on sites
that offer one-time codes, entirely on your device (the list of those sites ships inside
AutoPass). Two further checks use public data from Have I Been Pwned, a third-party
service. Both are off by default; you can turn each one on or off in
Settings > Vault health checks. They run only while you have Vault health open.
| Check | What is sent, and where | What is never sent |
|---|---|---|
| Exposed passwords | For each distinct password, the first 5 characters of its SHA-1 hash (for example 5BAA6) to api.pwnedpasswords.com. The service returns every known hash that starts with those characters, and AutoPass compares them on your device. |
Your passwords, their full hashes, usernames, websites, email address or anything else from your vault |
| Breached sites | A request to download the public list of breached sites from haveibeenpwned.com. AutoPass compares that list with your saved websites on your device. |
Anything about your vault |
As with any web request, Have I Been Pwned (and the network providers it uses) can see your IP address and your browser's standard request headers, and learns that you use these checks. AutoPass sends no cookies or referrer with these requests. The answers are kept only in the memory of the open AutoPass page for at most 24 hours; they are not saved to disk, synced or sent to the AutoPass server. Have I Been Pwned's own privacy policy applies to the requests it receives.
Optional Google sign-in
On the web vault and desktop app, choosing Continue with Google sends you to Google
(the desktop app opens your default browser) to confirm your
account. We request only your email address and stable Google account identifier
(openid email). Google receives the ordinary connection information associated with
visiting its sign-in page. This identity sign-in does not request access to Gmail, Drive, contacts or other
Google content. The optional Gmail feature below uses a separate permission request. Google's privacy policy applies to that sign-in.
AutoPass verifies Google's signed identity response and retains the stable identifier as a link to your AutoPass account until you delete that account. Temporary sign-in state and confirmation proofs expire after ten minutes. Google access and refresh tokens are not retained for identity sign-in. The desktop return uses a short-lived server handoff and an app-held random secret; the begin window is two minutes. Your master password and Secret Key still unlock your vault on your device; neither is sent to Google. Linking an existing vault requires its normal authentication, including its configured second factor.
Optional Gmail sign-in code retrieval
Availability: this feature is being prepared for a separate extension release. It is not enabled by simply using Google sign-in. Google verification, extension review and each mailbox's authorization are separate requirements.
When available, choosing Add Gmail account opens Google's account chooser and asks
for Gmail read-only access (gmail.readonly). You can connect multiple Gmail accounts,
up to eight in a browser session, choosing and authorizing each one individually.
Google's permission technically allows reading mail across the authorized mailbox; it
is broader than a permission for just verification codes. AutoPass limits its use to
the requested code feature below. It does not send, modify or delete your messages.
- AutoPass first requests the mailbox profile to identify the email account you connected.
- Only after you choose Find Gmail sign-in code, following a recent fill of the matching saved login on the active site, it queries that login's mailbox for recent inbox messages matching its username email and the exact code-sender address you configured. No periodic inbox polling or whole-inbox download is performed.
- It fetches at most five matching messages, including message identifiers, receipt time, headers and message bodies, directly from Google to the extension. It looks for one recent sign-in code and checks sender, recipient and available authentication information. Reset, payment, ambiguous and unsupported messages may yield no result.
- Message bodies and candidate codes are processed locally in extension memory, not sent to the AutoPass server, stored in your vault or included in logs. A found code requires a separate fill action on the same active page; the offer expires after 30 seconds. The destination site receives the code you choose to fill.
- Named mailbox addresses, short-lived Google access tokens, expiry times and up to 100 used-message identifiers per connected mailbox are kept in Chrome's extension session storage, restricted to trusted extension contexts. This allows the browser's extension worker to restart without losing its current connection. They are not saved to disk by AutoPass, synchronized, exported or put into a long-lived vault. Google tokens expire within one hour; locking, signing out, account changes or closing the browser clears the local connection. No refresh token or Google password is stored. An in-progress request may briefly retain data until it completes or aborts.
- Disconnecting one mailbox removes that local connection. You can also revoke the granted permission in your Google Account. Removing local access does not erase Google's own consent records or promise that a previously granted permission has been revoked at Google.
Google receives your authorization choices and direct API requests, including the query and ordinary connection metadata. Its own privacy policy applies to its service. AutoPass's server and its operator do not receive or read your inbox through this feature.
AutoPass's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including its Limited Use requirements. Google-derived mail data is used only for this visible user-requested feature. It is not sold, used for advertising or credit decisions, provided to data brokers or surveillance services, or used to train AI models. AutoPass does not transmit your messages or codes to AI agents or human operators.
Chrome Web Store Limited Use
Information accessed through extension permissions is used to provide the visible password-manager features described here. We do not sell permission-derived information, use it for personalized advertising, or provide it for unrelated profiling or AI-model training. Transfers are limited to the features you request (such as filling a selected site and syncing encrypted data), security needs or legal requirements allowed by the applicable policy. Our operators do not read encrypted vault contents they cannot decrypt. We do not expose Gmail contents to them. This disclosure describes our intended and implemented data use; it is not a claim of Google approval or independent certification.
Mobile applications in development
Before a mobile release, its store listing must disclose its actual permissions and version-specific behavior. The current unreleased implementation includes:
- iOS: an encrypted store shared between the app and its AutoFill extension using an App Group, a device-unlock key in Keychain, and site/account/passkey identifiers and one-time-code labels supplied to Apple's credential identity store for AutoFill suggestions. Passwords, private passkey keys and authenticator setup secrets are not put into that suggestion index.
- Android: an encrypted local vault and a device-unlock key protected by Keystore.
If you select AutoPass as an autofill service, Android supplies form structure, field
hints, web domains and app package names for requested fills. App/site verification
can request
https://<site>/.well-known/assetlinks.jsondirectly from the site's server; that server sees ordinary connection information, but no vault secret is sent there. - Credential Exchange import: only information you explicitly choose to transfer from another credential provider through the system flow is imported. Android's flow uses Google Play services. Provider and OS availability can prevent a transfer.
- One-time codes: generated from saved authenticator setup keys. These mobile versions do not read the Mail, Gmail, SMS, Messages, notification or clipboard inboxes. They require a sync account and do not currently offer local-only account creation.
These statements describe development versions, not availability on a public app store, physical-phone validation or support for arbitrary third-party apps.
What we don't do
- No analytics, telemetry, crash reporting or tracking of any kind, in the extension, the web vault or the server. Infrastructure providers may produce operational logs as described above; this statement does not mean there are no service logs anywhere.
- No advertising, and no third-party scripts or fonts are loaded. The extension, desktop app and web vault contact no third-party service except the optional Vault health checks, Google sign-in and the separately authorized Gmail connection above; the server we operate uses only the providers listed under "Service providers".
- We do not sell or rent your data, and we do not use it for any purpose other than signing you in, syncing your encrypted vault, sharing it with people you choose, and checking your second sign-in factor, retrieving a sign-in code you request locally, and handling support or privacy requests you send us.
- We do not use your data to determine creditworthiness or for lending.
- The sync service cannot decrypt your vault contents without your keys. People you choose to share items with can read those shared items. We cannot recover your master password or Secret Key; account recovery requires the recovery options you configured.
Retention and deletion
- Your account and encrypted vault are kept until you delete them.
- Items you move to Trash stay (encrypted) until you restore them or delete your account.
- Sessions expire after 30 days without use, and after 180 days at most.
- Trusted devices (two-step verification) stop being trusted after 30 days without use, or when you remove them in Settings > Devices or turn two-step verification off.
- A two-step setup you don't finish is forgotten after 10 minutes, and a sign-in waiting for a code after 5 minutes.
- Share links stop working at their expiry or view limit. Their stored copy is cleared once the view limit is reached; links that expired more than a week earlier are deleted the next time anyone creates a share link on that server.
- To delete your account: open AutoPass, go to Settings > Delete account, enter
your master password and type "delete". This permanently removes your account, all
vaults you own and every item in them from the server's database immediately, along
with your sessions, share links, invitations, account recovery data, two-step
verification data, Google identity links, agreement acceptance records and trusted devices, and wipes AutoPass's data from that device. You
are removed from vaults other people shared with you.
- Other devices you were signed in to keep their local encrypted copy until you sign out on them or remove the extension (they can no longer sync).
- If the operator keeps database backups, your data remains in them until they are rotated out: the Docker Compose setup keeps the most recent 14 daily backups by default, and the Fly.io deployment currently has daily volume snapshots kept for 5 days, plus any backups the operator takes by hand. Those manual backups currently do not have a published, enforced maximum retention period. Do not assume that deleting an account immediately removes all backup copies. Vault data in backups is ciphertext and cannot be read without your keys; account information (such as your email address and phone number) is in them as described above.
- Twilio keeps its own records of text-message codes it sent, under its own policy.
- To remove AutoPass from one device only: Settings > Sign out (or "Sign out of this device" on the unlock screen). Your vault stays on the server.
- Uninstalling the extension deletes everything it stored on that device. Uninstalling the desktop app may leave its data folder in place; docs/DESKTOP.md explains how to remove it.
Support messages and privacy requests
If you email sales@endopowersports.com, our operator and email provider receive your address, message, attachments you choose to send and ordinary mail-delivery information. We use them to answer your request, maintain necessary correspondence and meet legal obligations. Do not send passwords, private keys, recovery codes, unencrypted exports or unredacted sensitive screenshots. Support mail is not protected by vault encryption. Support correspondence currently has no fixed published deletion schedule; ask us about a specific request. Provider mail records follow the provider's own retention rules.
You can view and correct your vault information in the application, export it, disconnect optional integrations, remove devices and delete your account. Depending on your location and applicable law, you may also have rights to request access, correction, deletion, portability, restriction or objection concerning information we can read. Contact the address above. We may need proportionate identity verification and may retain information where law requires it. Never provide a master password or Secret Key as verification. We cannot decrypt a vault to satisfy a request. We will handle requests under the laws that apply and will not penalize you for exercising an applicable privacy right. This policy does not assert that every jurisdiction's privacy law applies to every user.
Our hosted service and providers may process information in the United States and other locations used by those providers. We have not claimed an EU/UK adequacy certification, data-transfer framework membership or a signed transfer agreement here.
Cookies, browser storage and tracking choices
AutoPass uses device and browser storage for essential vault, session, device-trust and settings functions explained above. Optional Google features use Google's own sign-in and authorization pages. AutoPass does not use advertising cookies or cross-site behavioral tracking and does not sell or share information for targeted advertising. It does not change its core operation in response to a browser Do Not Track signal. The absence of tracking is not a promise that Google's or another destination's site has the same practices. If we add a new non-essential tracking purpose, it must be separately disclosed and authorized where required before being enabled.
Security
How AutoPass encrypts your data, and its known limitations, are documented in SECURITY.md.
Children
AutoPass is not directed at children under 13 and we do not knowingly collect their data.
Changes to this policy
If this policy changes, we will update the effective date above and describe the change in the release notes.
Contact
AutoPass is operated by Endo Powersports LLC. Questions or requests about privacy: sales@endopowersports.com