Privacy

Effective 2026-10-11.

Alex Neyman, doing business as Agent Rails operates Rails and is responsible for the personal information covered by this policy (the data controller where that term applies).

This privacy policy covers Agent Rails (Rails), this site, the Rails app, and each app at <app>.rails.so. If you connect a Google Account, the Google user data section says exactly what Rails reads from Google, how it uses, stores and shares that data, and how to revoke access and delete it. Rails runs apps, stores their records, and serves tools that you can use from an agent host. A host such as Muse, claude.ai, Hermes or Grok is a separate service. Its privacy policy covers the conversation it holds. Connecting an app does not give Rails your whole chat history.

What we collect and why

• Account and sign-in. Your email address or phone number, its verification time, your identity provider identifier, your name and picture if you sign in with Google, and sign-in and session details. These identify your account and protect access to it. Clerk handles verification and sign-in. Rails also stores identifiers, expiry, scope and revocation details for access tokens. Handoff token secrets are stored as hashes, not as the original bearer token.
• Installations. Which apps you install, their versions, settings, permissions, owner, and status. These let us run the app you agreed to use and keep its records separate. An app host identifies the app you are using, not a separate account for you.
• App content. Information you enter, upload or ask a host to send to a tool, plus the records and results the app creates from it. The inventory below describes declared app records. In Rails' own chat surfaces, we also store threads, messages, run inputs, outputs and related events to deliver and resume your work. Speech features process audio and transcripts when you use them. Their storage includes processing consent, transcript revisions and temporary audio blobs.
• Google Calendar and Gmail, if you connect them. Google tokens and the limited calendar and mail details described in the Google user data section below.
• Purchases, if any. Whop takes payment for paid apps. Rails stores purchase and payment references, the app, buyer, amount, currency, status and term information. This proves access and supports refunds and accounting. Rails does not receive or store your payment card number from checkout.
• Usage and receipts. Tool names, request digests, outcomes, dates, app and installation identifiers, model and resource usage, and cost entries let us explain calls, enforce limits and investigate errors. Record receipts include record keys and actions. General execution receipts can include details of the work. These entries are not anonymous just because they are not the full record.
• Usage limits. Rails counts tool calls per installation to enforce the limits disclosed in each app's listing. Existing usage and rate-limit counters also support service operation and billing where applicable.
• Support and operations. If you write to support, we receive your email address, message and attachments. Send only what we need to help. Servers process network addresses, request paths and errors to serve requests, limit abuse and diagnose faults. Do not put passwords or access tokens in support messages.

Information comes from you, the host you connect, the app's work, Clerk, Whop if you buy paid access, and Google if you sign in with Google or connect Google Calendar or Gmail. Records can contain information about other people, such as contacts you supply. Only send information you have the right to use. Avoid sensitive personal information unless it is needed for the task and you have the right to provide it.

What each app stores

The following inventory describes the record types declared by the existing apps. A record type does not mean every person has a record of that type. Optional capabilities create records only when available and used.

Poker Trainer (existing app)

• Practice hands and their play history.
• Your choices during hands.
• Drill progress.
• Mistakes recorded for review.
• Learning exercise attempts.
• Learning goals and progress toward them.
• Evidence from practice at the table.
• Recall exercise attempts.
• Material shown during practice.
• Concepts tracked by the coach.
• Coaching sessions.
• Answers to coaching exercises.
• Questions asked during coaching.

Poker Trainer plugin

• Practice spots dealt to you, with the solver data each spot came from.
• The action you chose for each drill and whether it was correct.
• Your standing on each poker concept: attempts, misses and streaks.
• Hands dealt to you, your own cards and the board.
• Each action taken inside a hand, in order.
• What the poker solver said about each of your attempts.

Job Bot

• Facts about your work history that you give or confirm, and their source.
• Sections of your professional profile built from those facts.
• Rules you set for how your story is told.
• Job searches you run and their constraints.
• Roles found by a search and how you reacted to each.
• Applications you track, by company, role and status.
• Each change in the status of an application.
• Documents prepared for an application, such as a cover letter.
• Each draft of those documents and whether you approved it.
• Companies you are targeting and why.
• People at those companies you name, their role and your notes.
• Questions only you can answer, and your answers.
• Your Job Bot settings and search counts.

Rolodex

• People in your messages and what you know about them.
• Records of imported people and row outcomes.
• Sources and identities associated with each person.
• People or identities you asked the app not to contact.
• Email addresses and other identifiers seen for each person.
• Message threads the app has read, with counts and dates.
• Short statements taken from your messages, with where each came from.
• Meetings and calls with each person.
• Facts about people that you confirmed.
• Notes you write about people.
• Things you or someone else said they would do, and when.
• Conversations waiting on you or on someone else.
• Which messages show that a conversation is waiting.
• Your reviews recorded from a Rolodex page.
• Changes the app suggested and whether you accepted them.
• Records of two people you merged or kept apart.
• A summary of each relationship, such as last contact.
• Links between people that you confirmed.
• Signals used to judge how warm a relationship is.
• How warm each relationship is judged or stated to be.
• Which people can help with a goal you named.
• Corrections you made to what the app inferred.
• Fields you locked so the app does not change them.
• Groups of people you chose to share with someone.
• Who you shared a group with, and when it was revoked.
• Which message channels were read and whether reading worked.
• Identifiers that stop the same sync being applied twice.
• Your Rolodex settings and sync history.

Unblock

• Requests your agents send you, with what they need and why.
• Your answers to those requests.
• Project names your requests belong to.
• The agents that send you requests and where to reach them.

Google user data

Agent Rails (Rails) can connect to your Google Account in four ways. Each is optional and starts only when you choose it, while you are signed in to Rails in a browser or the Rails app. A connected agent host cannot start, change or revoke a Google connection. Google's consent screen lists the permissions below. Rails requests no other Google permission.

What Rails accesses

• Sign in with Google. If you sign in with Google, Clerk, our sign-in provider, receives your name, email address and profile picture from Google (openid, email, profile). Rails uses them to create your account and show your name and picture in Rails.
• Google Calendar. Two permissions: see the list of your calendars (calendar.calendarlist.readonly) and see and edit events (calendar.events). When you connect, Rails reads your primary calendar's identifier, which is usually your Google email address, to label the connection. After that, Rails reads your calendars only when an app you installed and allowed to use the connection asks. Rails uses calendar identifiers, names, selection settings and access levels to choose calendars. Depending on the feature, event results include identifiers, status, title, start and end time, location, attendee email addresses or counts, and whether an event shows you as busy or free. These results let your agent show your schedule and find free time. Calendar tools can create, move or cancel events when you allow calendar changes. Changes require your review and confirmation within five minutes, except a guest-free change you directly request from your main agent in chat. Rails sends Google the event details needed for the change, including attendee email addresses when you include guests, and tells Google not to send invitations.
• Gmail. Your email address (openid, email) and read-only access to your mail (gmail.readonly). When you connect a mailbox, Rails reads its address to label it. After that, Rails reads mail only when an app you installed and allowed to use that mailbox asks. For a list of threads, which can match a search the app supplies, Rails reads each thread's subject, a short snippet, the sender, the names and addresses in From, To and Cc, the date, whether it is unread and how many messages it has. For one thread, Rails also reads the plain text of each message, up to 64 KB per message, and the names, types and sizes of attachments. Rails does not download attachment contents. With this permission Rails cannot send, delete, label or change your mail.
• Gmail through Composio. Rails can also connect Gmail through Composio, a service that holds the Google connection for Rails, with the same permissions (openid, email, gmail.readonly). On this connection Rails reads your address to label it. After that, when an app you installed and allowed to use it asks, Rails reads message and thread identifiers, which can match a search the app supplies, and for one message its From, To, Date, Subject and Message-ID headers. Rails does not read message bodies, snippets or attachments on this connection.

How Rails uses it

Rails uses Google data only to provide the features you turned on: signing you in, showing your schedule, checking when you are free, making calendar changes you request or confirm, and letting an app you allowed read your mail to do the task you asked for, such as finding or summarizing a message. Rails uses no Google data for advertising, to build profiles for other purposes, or for credit or lending decisions, and does not sell it.

Rails returns mail and calendar results to the app or agent you allowed to use the connection. Your agent host, such as claude.ai or the Rails app, and the model provider used by that app or agent can process those results to answer your request.

No AI training on Google data

Rails does not use Google user data to develop, improve or train generalized AI or machine learning models, and does not transfer it to anyone for that purpose.

Limited Use

Agent Rails' use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

People at Rails read your Google data only when you ask us to for a specific item, when it is needed to investigate security or abuse, or when the law requires it. Before Rails uses Google data in a new way, we update this section and ask for your consent.

Where it is stored and for how long

• Calendar tokens. Rails stores your Google access and refresh tokens, encrypted with AES-256-GCM under a key held outside the database, until you revoke the connection. It also stores the connection label and status. For each event you review, Rails keeps an encrypted copy of the requested change, including the calendar, event identifiers, title, times, time zone and attendee email addresses where supplied.
• Gmail tokens. Executor, a credential service that Rails runs on Railway apart from its main database, holds your Gmail tokens until you disconnect the mailbox. Rails' database keeps the mailbox address, the nickname you give it and its status.
• Gmail tokens held by Composio. For Gmail connected through Composio, Composio stores and refreshes the Google tokens until you disconnect it. Rails stores the mailbox address, its status and Composio's identifier for the connection, never the tokens. Composio keeps a log of each request Rails makes through it, which can hold the message headers above, for up to one year.
• Mail and calendar content. Rails does not keep its own copy of your mail, calendar list or events, apart from the event review copies above. If you read mail or view calendar results inside a Rails chat, the chat keeps those results until you delete the chat or your account. We purge it within 30 days after that.
• Receipts. Each read and each calendar change leaves a receipt with the time, app installation, operation, permission and outcome. Receipts hold no mail or calendar content and no tokens. We keep them for 730 days, then delete them.
• Sign-in. Clerk keeps the Google profile details above with your account until the account is deleted.

Rails talks to Google only over HTTPS. Before each read or event creation, Rails checks again that you still allow that app to use the connection. Tokens never appear in receipts, app records or error messages.

Who receives it

• Google receives the requests Rails makes for you, including the event details you confirm.
• Railway hosts the database and the Executor service that hold the items above.
• Composio holds the tokens for Gmail connected through it, passes Rails' requests to Google and returns the results to Rails. It uses them only to provide that connection.
• The app you allowed, your agent host and the app's model provider receive mail and calendar results, as described under How Rails uses it.
• Clerk receives only the sign-in details above.

Rails shares Google data with no one else, including advertisers and data brokers. A valid legal demand can still require disclosure, as described under Who receives information.

Revoke access and delete your data

• At Google. Remove Rails' access at any time on your Google Account's third-party connections page.
• Calendar in Rails. Revoking the connection in Rails asks Google to revoke Rails' token, erases the stored tokens and ends every app's use of it. If Google cannot be reached, Rails still erases its tokens; remove access on the Google page as well. If you remove access only at Google, the encrypted tokens stay at Rails until you revoke the connection in Rails or ask us to delete them.
• Gmail in Rails. Disconnecting a mailbox in the Rails app removes the connection and its tokens from Executor and ends every app's access to it. Rails does not separately ask Google to revoke the grant, so remove it on the Google page as well.
• Gmail through Composio. Disconnecting it in Rails ends every app's use of it, asks Google through Composio to revoke Rails' access and removes the connection and its tokens from Composio. If the revoke is not confirmed, remove access on the Google page as well.
• Delete. Write to us at the address below to delete your Google data or your account. We delete connection labels, mailbox addresses, review copies and remaining tokens within 30 days. Chats that hold mail or calendar results are purged within 30 days. Receipts, which hold no mail or calendar content, are kept for 730 days, then deleted.

Who receives information

• Model providers. Rails calls hosted model APIs on your behalf. Prompts and relevant tool results go to the provider named in the app's listing and processing disclosures so it can produce a response. Speech services receive the audio or transcript needed for the feature you use. Read that provider's policy before sending sensitive information. This policy does not promise a provider's retention period or that a provider never uses data for training.
• Your host. A host such as claude.ai, Hermes, Grok or Muse sends tool arguments and receives tool results. It can keep those results under its own rules. Disconnecting from Rails does not erase copies already held by the host. For Rails plugins, connections a host makes to services such as LinkedIn stay with the host. Rails receives the data sent to its tools, not those services' passwords or OAuth grants. Google Calendar and Gmail work differently: if you connect them in Rails, Rails holds its own Google tokens, as described above.
• Clerk. Our sign-in provider processes verification and authentication information, including your Google profile if you sign in with Google.
• Whop. If you buy paid access, our payment provider processes checkout and payment details. Rails exchanges purchase identifiers and status information with Whop to provide that access and handle refunds.
• Google. If you connect Google Calendar or Gmail, Rails exchanges authorization codes and tokens with Google and sends Google the event details you confirm. Google's privacy policy covers what Google holds.
• Railway. Our infrastructure provider hosts the service and database. Hosting necessarily processes the information stored or handled there.
• Service operators. Authorized operators access information for support, maintenance, security and legal obligations. A valid legal demand can require disclosure to a public authority. We limit that disclosure to what is required.

Rails does not sell personal information or share it for cross-context behavioral advertising. These legal pages have no analytics, advertising, third-party requests or tracking scripts. Service delivery to the providers above is not advertising.

Providers can process information in countries other than yours. Those countries can have different privacy laws. Where transfer safeguards are legally required, they must cover the transfer. Ask us which locations and safeguards apply to your app. This policy does not assert a particular data region, adequacy decision or contractual safeguard that has not been verified.

Purposes and legal grounds

We use account details, app records and payment information to provide the service you request and perform our agreement with you. We use necessary operational and security information for our legitimate interests in running a reliable service, preventing abuse and resolving disputes. We keep legally required accounting records to meet legal obligations. When a feature needs consent, we ask for it; you can withdraw it without changing the lawfulness of earlier processing.

A verified email address, phone number or Google sign-in is required to sign in. Without the content needed for a task, an app cannot do that task. App-generated feedback and estimates are assistance for you, not decisions about your legal rights. We do not use them to make solely automated decisions with legal or similarly significant effects.

Retention, export and deletion

Saved app records have no automatic age-based expiry unless the feature says otherwise. They remain until deleted. Account and installation metadata remain while needed to provide access and resolve account issues. Purchase records and receipts remain for accounting, security and disputes, including after an app is removed. Receipts for Google connections are kept for 730 days, then deleted. Chat content that holds mail results is kept until you delete it or your account, then purged within 30 days.

We assess a deletion request against the purpose of each retained category and any legal duty to keep it. If something must remain, we explain the category, reason and applicable period. This policy does not claim a fixed log, support-mail or backup deletion schedule: those operational schedules have not yet been verified.

• Available now. The authenticated service supports export, revoke and uninstall for an installation, and revocation of handoff tokens. Export includes installation information and supported activity data, with credentials removed. The records layer can export the collections in an app's current declaration.
• Revoke is not delete. Revoking an installation stops its access and work. It keeps saved records. Uninstall is the separate cleanup action. It removes supported installation content and records in the current declaration but preserves audit receipts. Export before uninstalling if you want a copy.
• Not yet complete. A single installation export that includes every declared collection, including collections from older app versions, and cleanup that covers those older collections are planned improvements. A complete self-service account erasure flow is not promised here. Do not treat a dashboard export or an uninstall as proof that every copy has been exported or erased. Contact us for a full access or deletion request, including any missing app records.

Revoking a token stops future access with that token; it does not delete saved data. Signing out clears that session, not every connection. Exports do not include provider copies or backups. Deletion at Rails does not erase material you or a host already copied elsewhere. We handle requests concerning our service providers as required by applicable law.

Your choices and rights

Contact us to ask what we hold, obtain a copy or a portable export, correct a mistake, delete information, or stop a connection. You can ask about data another person entered about you even if you have no Rails account. Tell us the app and what you need; do not send a sign-in code, password or full card number. We verify identity and authority using information proportionate to the request. An authorized agent can act for you with proof of authority. We explain any refusal and any lawful exception. You do not have to buy an app to exercise your privacy rights.

In the EEA, where the GDPR applies, your rights include access, correction, erasure, restriction, portability, objection to legitimate-interest processing, and withdrawal of consent. You can complain to your local data protection authority. We respond within one month, subject to lawful extensions that we explain within that month.

California residents have the rights that apply under the CCPA: know and access, correct, delete, opt out of sale or advertising sharing, and limit qualifying uses of sensitive personal information. We do not sell or share data for that advertising purpose, including data about minors, and use sensitive information only as needed for the requested service and permitted operational purposes. There is no sale or advertising sharing to opt out of, including when your browser sends Global Privacy Control. We do not penalize you for exercising rights. Where the CCPA applies, we respond to access, correction and deletion requests within 45 days, with notice of any lawful extension.

The categories described above include identifiers, commercial information, internet activity, content you provide, audio where used, and inferences such as learning estimates. They describe current collection and operational disclosure, not a claim that every feature ran throughout the preceding 12 months. You can ask for the categories, sources, recipients and specific information applicable to you.

Security and cookies

Rails scopes app records to a person and installation. PostgreSQL row-level security adds tenant separation behind the service's access checks. This is not end-to-end encryption: authorized service code and operators can process the data. Tokens grant access and must be kept private. Handoff tokens can expire or be revoked.

The Rails session cookie is strictly necessary for sign-in. It is host-only, HttpOnly and SameSite=Lax, with Secure on HTTPS. It is not an advertising cookie. The planned per-app sign-in flow exchanges an authorization code for a separate, host-only session bound to that app. That flow is not yet available in this release; we do not share the apex session cookie across app subdomains. Reading this privacy policy or the terms sets no cookie and needs no sign-in.

No service can guarantee perfect security. Contact us promptly about a suspected exposure. Keep control of your email and phone, and disconnect hosts you no longer trust.

Children

Rails is not for children under 13, or under 16 in the EEA. These are our minimum ages, not a claim that every country's consent age is the same. Do not create an account below the applicable age. If you believe a child below that age has supplied personal information, contact us so we can investigate, close the account and arrange deletion subject to legal obligations.

Changes to this policy

We publish changes here and update the effective date when adopted. We give notice of material changes through the service before they take effect. If a new use needs consent, we ask before starting it. A policy update does not remove your legal rights.

Contact and privacy requests

Use the address below for privacy requests, support, refunds and security reports.

Write to support@rails.so.