Privacy

Effective 2026-09-26.

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 Rails, this site, and each app at <app>.rails.so. 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 phone number, its verification time, your identity provider identifier, and sign-in and session details. These identify your account and protect access to it. Clerk handles phone verification. 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, if you connect it. Encrypted Google tokens and the limited calendar details described in the Google Calendar 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 connect Google Calendar. 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.

Assistant

• Notes you ask the app to remember, in your own words.
• The note-number counter.

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.

Language Tutor (existing app)

• Your learning setup and current settings.
• Earlier versions of those settings.
• Class material you supply and its confirmation status.
• Lesson sessions and completion status.
• Lesson plans.
• Exercise prompts and expected answers.
• Exercise variants and their teaching context.
• Assessment exercises and their scoring instructions.
• Which assessment was sent for an attempt.
• Assessment results and feedback.
• Which assessment material you have seen.
• Hints shown to you.
• Request identifiers that prevent duplicate attempts.
• Your answers, their status and feedback.
• Evaluations of your answers.
• Learning observations from practice.
• Links between speech attempts and transcript revisions.
• Estimated skill levels.
• Items and dates for spaced review.
• Lesson summaries.
• Lesson output and feedback shown to you.
• For the optional live capability: conversation reports, session identifiers and voice duration.
• For the optional live capability: review prompts, answers and review dates.

Poker Trainer connector

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

Language Tutor connector

• Lesson sessions, their language, level and status.
• What each lesson set out to practise.
• Exercises in a lesson and the answers they expect.
• The answers you type and their status.
• How each answer was scored, with feedback and corrections.
• Current estimates of your skill in each area.
• When each skill is next due for review.
• Scored evidence about each skill, used to update the estimates.
• What each lesson covered and what to practise next.

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.

Recruiter

• Roles and hiring criteria you are working on.
• People considered for roles and their contact details.
• Candidate assessments and role associations.
• Where candidate information came from.
• Candidate profile details.
• Candidate lists you organize.
• Outreach campaigns and their settings.
• People included in each outreach campaign.
• Outreach message drafts.
• Review marks on message drafts.
• Hiring manager message drafts.
• Responses to outreach.
• Hiring manager responses.
• Follow-up messages and timing.
• Recorded recruiting activity.
• Recruiting operations and their status.
• Connected recruiting services and account metadata.
• Attempts to use connected providers and their results.
• Usage of connected providers.
• Acknowledgments of automated actions.
• Requests to fill hiring forms.
• Locks that prevent duplicate form fills.
• Prepared candidate packets.
• Information used to prepare candidate packets.
• Links to recruiting pages.
• Links to queued recruiting work.
• Your decisions on proposed actions.
• Items already reviewed in recruiting triage.
• Counters used to assign record identifiers.

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 Calendar data

If you connect Google Calendar, Rails stores Google tokens for your account and receives limited calendar data from Google. Only you can connect it, from a browser where you are signed in to Rails. A connected agent host cannot connect or revoke it, or confirm an event. Google asks you to allow two permissions: to see the list of your calendars (calendar.calendarlist.readonly) and to see and edit events (calendar.events). Rails requests no other Google permission. It uses the second one to read the event details listed below and to create events you confirm; it never edits or deletes an event.

• What Rails reads. When you connect, Rails reads your primary calendar's identifier, which is usually your Google email address, and keeps it to label the connection. After that, Rails reads your calendars only when an app you installed and allowed to use the connection asks. From your calendar list it uses each calendar's identifier, whether it is your primary calendar, and your access level. From a calendar's events it uses each event's identifier, status, start and end time, number of attendees, and whether it shows you as busy or free. Rails drops everything else Google returns, including titles, descriptions, locations and attendee names and email addresses, without storing it.
• How Rails uses it. Rails passes those details only to the app that asked, for the feature you allowed. Rails does not store or cache the calendar list or events it reads. It does not send Google data to a model provider or to your agent host.
• What Rails writes. Rails creates an event only after you review its calendar, title, start and end time in Rails and confirm it within five minutes. One confirmation makes at most one attempt. Rails sends Google only those four details. It adds no attendees and tells Google not to send invitations or updates. If Rails cannot tell whether Google created the event, it does not retry; check your calendar before you try again. Rails does not change or delete existing events.
• What Rails stores. Rails stores your Google access and refresh tokens, encrypted with AES-256-GCM under a key held outside the database, until the connection is revoked. It also stores the connection label and the connection's status. Each read an app asks for and each event creation leaves a receipt with the time, app installation, operation, permission, purpose and outcome. A successful read also leaves an activity entry with the number of items read. Receipts and activity entries hold no calendar content or tokens. For each event you review, Rails keeps an encrypted copy of the calendar, title, start and end time.
• How Rails protects it. Rails talks to Google only over HTTPS, to fixed Google addresses, and does not follow redirects. Encryption binds each token to your account and the connection. Before each read or event creation, Rails checks again that you still allow that app to use the connection. Tokens do not appear in receipts, app records or error messages. The Security section below describes how accounts are kept apart.
• Who receives it. Google receives the requests Rails makes for you, including the event details you confirm. Railway hosts the database that holds the items listed above. Rails does not share Google data with model providers, agent hosts, Clerk, Whop or advertisers, and does not sell it. A valid legal demand can still require disclosure, as described under Who receives information.
• Limited Use. 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. Rails uses Google data only to provide the calendar features you choose. It does not use Google data for advertising or for credit or lending decisions. It does not use Google data to develop, improve or train generalized AI or machine learning models, and does not transfer it for that purpose. 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.
• Revoke. You can remove Rails' access at any time on your Google Account's third-party connections page. The authenticated Rails service also supports revoking the connection, or you can ask us to revoke it. A Rails revoke asks Google to revoke Rails' token, erases the stored tokens, marks the connection revoked and ends every app's use of it. If Google cannot be reached, Rails still erases its tokens and reports that Google did not confirm; remove access on the Google page as well. If you remove access only on the Google page, the encrypted tokens stay at Rails until you revoke the connection in Rails or ask us to delete them.
• Delete. Revoking keeps the connection label, receipts, activity entries and review copies, and the current software does not delete them automatically. Contact us and we will delete the connection label and review copies. Receipts and activity entries, which hold no calendar content, remain for security and disputes like other receipts.

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 the connector program, connections to services such as Gmail or LinkedIn stay with the host. Rails receives the data sent to its tools, not those services' passwords or OAuth grants. Google Calendar works differently: if you connect it, Rails holds its own Google tokens, as described above.
• Clerk. Our sign-in provider processes phone verification and authentication information.
• 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, 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 phone number and verification are 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. The current software does not automatically expire those ledgers.

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