Privacy Policy

FleetRun is a platform for running AI agents against your own business and personal tools. You create a Fleet, add agents to it, and delegate missions. An agent works a mission in a bounded loop, may read from connected accounts using read-only tools, and must stop and ask a human before doing anything consequential.

This policy describes what the running system actually stores and transmits. It was written by reading the FleetRun source code and database schema rather than from a product summary, so where it makes a specific claim — a field name, a scope, a bucket — that claim reflects the code.

The controller of personal data described here is Leonenko Group LLC — registered entity name, jurisdiction and registered address to be confirmed. Where you use FleetRun to process other people’s personal data (for example, the contents of a mailbox belonging to your company), you are the controller of that data and FleetRun acts as your processor.

Every table below is a real table in the FleetRun database. All nineteen customer-data tables are scoped to a single Fleet and protected by PostgreSQL row-level security, so a query can only ever return rows belonging to a Fleet you are a member of.

Account and profile

Your profile record holds exactly six fields and nothing more: id, email, full_name, avatar_url, timezone, and onboarded_at, plus created and updated timestamps. We do not collect a postal address, a phone number, a date of birth, a government identifier, or any demographic data. Authentication credentials are held by Supabase Auth, not in this table.

Fleet and membership

A Fleet record holds its name, URL slug, whether it is a Personal or Company Fleet, its plan tier, its owner, its credit balance and reserved amount, its per-mission budget cap, an optional logo path, and any suspension timestamp and reason. Membership records hold your role in that Fleet, an optional job title, and who you report to.

Agent configuration

For each agent: name, role, an optional written character (“soul”), its manager in the reporting tree, status, autonomy level, and preferred model. Separately, an explicit list of which capabilities each agent has been granted and who granted them.

Mission content and traces — read this one carefully

This is the most sensitive category, because it contains whatever you or your agents put into it.

• A mission stores the title and brief you wrote, its status, its cost, its timestamps, and any error.
• Each step of a mission stores the model input and the model output as JSON, alongside the provider, the model that served it, token counts, and cost in cents. For model-call steps the recorded input is a rolling window of the last four messages in the conversation, and the recorded output is the model’s text plus any tool calls it made. This means the substance of what your agents read and wrote is retained.
• For tool-call stepsthe arguments are deliberately not stored. Only a SHA hash of the arguments is written, because a Gmail search query is itself sensitive and mission steps are readable by every member of the Fleet. The tool’s redacted result is stored.
• A mission event log records each decision point — run started, step completed, approval requested, budget exhausted, run failed — with a summary and a JSON payload.
• An approval stores the action an agent wants to take, the detail explaining it, the decision, who decided, and when.
• An approval-gated Gmail draft request stores the recipient address, subject and full body of the proposed message until it is created or rejected.

Billing

The wallet ledger records every credit movement: direction, amount in cents, a reason, the related mission, and an external reference to the Stripe payment for top-ups. FleetRun does not store card numbers, and does not store a Stripe customer or subscription identifier in its own database. Card details are entered on Stripe-hosted pages and never reach FleetRun servers.

Support, feedback and research

Tickets store a subject, body, contact email, priority, category and the message thread. Feedback stores a score or comment plus the context in which it was given. Interview notes store what we learned from a customer conversation, including verbatim quotes. Interview notes are internal and are never visible to the customer they describe — that is enforced by row-level security, not by hiding a screen.

Public pilot waitlist

The public waitlist collects your email address and, if you choose to provide them, your name and company. We use those details only to contact you about the supervised FleetRun pilot. Production may keep these records in FleetRun’s separate legacy V1 Supabase project; access uses server-only credentials and is not exposed through a customer interface. Waitlist records follow the retention approach below. You may ask us to correct or delete your entry through our contact page.

For abuse prevention, FleetRun stores keyed, one-way HMAC identifiers derived from the submitted email address and the request IP address; it does not put either raw value in the rate-limit table. These identifiers are used only to enforce signup limits and are deleted automatically after 30 days.

Activity logs

A Fleet activity log records what members did inside their own Fleet: role changes, agents created or archived, approvals decided, credits bought, members added. It is append-only through the application: no member or staff session can edit or delete a row. It is not cryptographically immutable, and an operator with direct database access could alter it.

If you connect Google to a Fleet, FleetRun requests read-only scopes only. The exact set requested is:

No write scope is requested during this flow. FleetRun asks Google to report exactly which scopes were granted, so a partial consent is recorded as a partial consent rather than assumed to be complete.

What an agent is actually shown

Holding a read scope is not the same as putting data into a model’s context. FleetRun narrows every Google request at the API level, so the omitted data is never fetched in the first place rather than fetched and then dropped. A redaction that happens after the data has arrived is one stray log line away from being no redaction at all.

Results are truncated before they reach a model, both to bound cost and to bound how much text a third party can inject into an agent’s context simply by emailing your connected mailbox. Agents are instructed to treat all tool output as untrusted data rather than as instructions.

Per-agent permission

Connecting Google to a Fleet does not give every agent in that Fleet access to it. Each agent must be separately granted each capability by a Fleet owner or admin, and the absence of a grant is a denial. An agent created before a capability existed receives nothing automatically.

Writes require your approval

There is one path by which FleetRun can write to Google: creating a Gmail draft. It requires a separate gmail.compose consent that is not part of the connection flow above, and it will not execute unless a human approves the specific draft first. FleetRun never sends mail on your behalf, never changes a calendar, and never modifies a Drive file.

Encryption and revocation

OAuth access and refresh tokens are encrypted with AES-256-GCM before they are written to the database. Each write gets a fresh initialisation vector and carries its own authentication tag, so a tampered record fails to decrypt rather than yielding altered data. The encryption key lives in the server environment and never enters the database, so a database dump alone does not expose your tokens. Tokens are never sent to a model, never returned to a browser, and never written to a log.

When you disconnect an integration, FleetRun revokes the grant at Google firstand only then deletes the stored connection record. Revoking the refresh token invalidates the whole grant, not merely the current session. You can also revoke FleetRun’s access at any time from your Google Account permissions page, independently of us.

This is the part most AI privacy policies are vague about, so it is worth being exact.

FleetRun holds no direct contract or integration with any model provider. There are no Anthropic, OpenAI, Google, Meta or DeepSeek SDKs in the codebase. Every model call in FleetRun goes to a single endpoint: openrouter.ai. OpenRouter is our processor for model traffic, and it routes the request onward to whichever provider serves the selected model.

The practical consequence: the model providers listed below are onward recipients of your prompt content, reached through OpenRouter, not parties we have contracted with directly. Their handling of that data is governed by their terms with OpenRouter, not by an agreement between them and FleetRun. We state this plainly because claiming direct data-processing agreements that do not exist would be a false statement about your data.

Which model runs a given mission depends on the agent’s configuration and its autonomy level, and FleetRun may fall back to a different model in the same tier if the first is rate-limited or unavailable. The model that actually served each step is recorded in the mission trace, so you can always see where a given request went. Enterprise Fleets can restrict the permitted providers by policy; that restriction is absolute and cannot be overridden by an agent’s own settings.

The content sent to OpenRouter is: the agent’s instructions, your mission title and brief, prior approval decisions on that mission, and the redacted results of any tools the agent called. FleetRun does not send your OAuth tokens, your payment details, or data from any Fleet other than the one the mission belongs to.

We do not use your mission content to train models, and FleetRun runs no training of its own. We cannot, however, make binding promises on behalf of onward providers we have no contract with. If your data must never transit a third-party model host, do not connect it to FleetRun.

The only external hosts FleetRun’s server code contacts are listed here. There are no analytics scripts, no advertising pixels, and no third-party session-recording tools in the application.

Two storage buckets are configured as public-read: Fleet logos and user avatars. This is a deliberate design choice and it has a privacy consequence you should understand before uploading anything.

Uploading is restricted — only a Fleet owner or admin can write a logo for their Fleet, and you can only write an avatar into a folder named for your own account. But reading is not restricted. Anyone who knows or can guess the URL of an uploaded logo or avatar can retrieve that image without signing in. URLs are not published or listed anywhere, and they contain a non-sequential identifier, so they are not enumerable in practice — but they are not access-controlled either, and a shared URL keeps working for whoever receives it.

Do not upload an image as a logo or avatar if it would be harmful for it to be viewed by someone outside your Fleet. Everything else in FleetRun — every one of the nineteen customer-data tables — is access-controlled and is not publicly readable.

One sign-in can hold several Fleets, and Personal Fleets and Company Fleets are isolated from one another. A personal agent cannot reach company systems, and a company agent cannot reach your household calendar, personal mailbox or private notes. Each Fleet has its own agents, wallet, integrations, permissions, activity log and model policy.

This separation is enforced in the database by row-level security on every table, not by an interface convention. The active Fleet is held in a cookie as a display preference only — membership is re-checked on every read, so changing the cookie grants nothing.

Your role can differ per Fleet: you may be the owner of one and an ordinary member of another. Within a Fleet, missions, mission steps, approvals, the wallet ledger and the activity log are readable by all members of that Fleet. If you would not want a Fleet member to read the full text of a mission brief or a model response, do not put it in that Fleet.

We would rather explain this than leave it out. Designated FleetRun staff can read customer data across Fleet boundaries in order to provide support and debug failures. There is an internal admin portal, and it is the one surface in the product that is not scoped by Fleet membership.

Concretely, what staff access looks like:

• Staff status is a row in a database table. It cannot be asserted by a browser, set by an environment variable, or granted by a hardcoded email list. A non-staff account querying these surfaces receives zero rows.
• Staff read access is SELECT only, granted individually for Fleets, memberships, profiles, missions, mission steps, mission events, approvals, wallet entries, agents, connections, tickets, ticket messages, feedback, and the Fleet activity log.
• Two things are excluded from every staff query by construction: encrypted connection credentials and an agent’s written character. Those columns are never named in an admin query, so their values do not cross the wire into the admin application at all.
• The portal is read-only except for a small number of actions, and every staff action writes a row to an append-only audit log recording who acted, what they did, which Fleet or person it touched, the details, and when. Staff cannot write or delete rows in that log from a browser session.

Note what this implies: staff reading a mission trace can see the model inputs and outputs stored on it, which may include content drawn from your connected accounts. Access is limited to staff who need it for support, and the internal policy governing when staff may access customer data has not yet been written and must be before launch.

We use your data to:

• Run the missions you delegate and show you their results.
• Enforce budgets — reserving credits before a run and settling actual usage afterwards.
• Show approval requests to the people entitled to decide them.
• Maintain traces and activity logs so a run can be audited and a failure debugged.
• Provide support and respond to tickets.
• Bill you, and detect and prevent fraud and abuse of the platform.
• Understand which parts of the product are useful, through feedback and customer interviews.

We do not sell personal information, and we do not share it for cross-context behavioural advertising. There is no advertising in FleetRun and no advertising network receives your data.

Where GDPR applies, our legal bases are: performance of a contract (running the service you signed up for), legitimate interests (security, fraud prevention, debugging, and product improvement), consent (connecting a Google account, which you give at Google’s consent screen and can withdraw at any time), and legal obligation (tax and accounting records).

FleetRun automatically purges completed worker-queue records after 30 days and circuit-breaker transition telemetry after 90 days. Records persist until they are deleted by the cascade rules below or by a deletion request. We would rather say that than publish a retention schedule the system does not enforce.

What the database does today:

• Deleting a Fleet cascades to its agents, missions, mission steps, mission events, approvals, wallet entries, connections, capability grants, tickets, feedback, interview notes and activity log.
• Deleting your account cascades from the authentication record to your profile, and to your Fleet memberships and prompt history.
• Some records deliberately survive the person: feedback you left, interview notes, audit log entries and activity log entries keep the record but drop the link to your profile. An employee leaving must not erase the history of what they did, and feedback stays true after the person who gave it moves on.
• Append-only tables — the Fleet activity log, the staff audit log, ticket message threads and feedback — cannot be edited or deleted through the application by anyone, including staff. Immutability is enforced by access control rather than by a database constraint.

Target retention periods still to be set and implemented for customer content and business records: mission traces, mission steps containing model inputs and outputs, support tickets, server logs, and backup retention — none of these periods have been decided.

When you request account closure, the account enters a 30-day reactivation window. If you log in during that window, FleetRun asks whether you want to reactivate the account and lets you do so if the account remains eligible, including completing any required plan setup. After the 30-day window ends, the account is permanently closed and cannot be reactivated. Associated data is then deleted subject to records we must retain for tax, accounting, fraud prevention, security, or other legal obligations.

Depending on where you live you may have some or all of the following rights. We extend the substance of these to all users regardless of location.

• Access — obtain a copy of the personal data we hold about you.
• Rectification — correct inaccurate data. Your name, avatar and timezone are editable in the app at any time.
• Erasure — request deletion of your account and associated data, subject to records we must keep for tax, accounting or fraud-prevention purposes.
• Portability — receive your data in a machine-readable format.
• Restriction and objection — ask us to limit or stop processing based on legitimate interests.
• Withdraw consent — disconnect a Google integration at any time from the integrations page, which revokes the grant at Google and deletes the stored credential.
• Non-discrimination — under the CCPA/CPRA, we will not deny service, charge a different price, or provide a lower quality of service because you exercised a privacy right.
• Complain — lodge a complaint with your local data protection authority.

Under the CCPA/CPRA specifically: we collect the categories of personal information described above; we disclose them to the subprocessors listed above for business purposes only; we do not sell personal information and we do not share it for cross-context behavioural advertising; and we do not knowingly collect the personal information of anyone under 16.

To exercise any right, contact us using the details at the foot of this page. We will verify your identity against the account before acting. The verification method and the response deadline are still to be defined, along with an authorised-agent process for CCPA requests.

FleetRun’s subprocessors operate internationally, and data you submit is likely to be processed outside your own country — including in the United States. Model requests in particular are routed through OpenRouter to whichever provider serves the selected model, and that provider may be in another jurisdiction.

We will not claim a transfer mechanism that is not in place. As of the date on this page, FleetRun has not executed Standard Contractual Clauses with its subprocessors, has no Binding Corporate Rules, and is not certified under the EU–US Data Privacy Framework. We rely on the terms of service of each subprocessor as accepted during sign-up, which is not the same thing as an executed transfer mechanism.

Executing appropriate transfer mechanisms and completing a transfer impact assessment is required work before FleetRun offers the service to customers in the EEA, the UK or Switzerland. Counsel must advise on this before launch in those markets.

Controls that are implemented and verifiable in the codebase:

• Row-level security on every customer table, with Fleet membership as the single source of truth for access.
• AES-256-GCM authenticated encryption for OAuth credentials, with one application key held outside the database in the server environment. A key identifier supports decrypt compatibility with one retired key during a manual migration. This remains a single layer of application-key encryption.
• Least-privilege OAuth: read-only scopes, with write consent kept separate and gated behind human approval.
• Server-side authorisation re-checked on every capability invocation, not assumed from the page that called it.
• Signed, single-use, short-lived OAuth state with an HTTP-only cookie, defending the connection flow against forgery and replay.
• Verified Stripe webhook signatures with idempotency, so a replayed payment event credits nothing twice.
• Budget ceilings enforced before a model call is made rather than reconciled after the money is spent.
• Secrets and tool arguments kept out of logs and traces; server keys are held in modules that fail loudly if imported into browser code.

What we explicitly do not claim. FleetRun is not SOC 2 audited, not ISO 27001 certified, not HIPAA compliant, not PCI DSS assessed, and holds no GDPR certification. No independent penetration test, vendor risk review or formal incident response process has been completed. Having sound controls is not the same as being certified, and we will not describe FleetRun as compliant merely because controls are in place or planned. Do not put protected health information, payment card data, or material subject to a regulated compliance regime into FleetRun.

No system is perfectly secure. If you believe you have found a vulnerability, please report it to us at the contact below rather than disclosing it publicly. A formal breach-notification procedure and disclosure timeline have not yet been established.

FleetRun uses cookies only to make the application work. There is no advertising or analytics cookie in the product.

• Session cookies set by Supabase Auth, which keep you signed in.
• Active Fleet preference, which remembers which Fleet you were last looking at. It is a display preference only — membership is re-checked on every read, so editing it grants no access.
• A short-lived OAuth state cookie during a Google connection flow. It is HTTP-only, scoped to the callback path, and expires after ten minutes.
• Theme preference, remembering light or dark mode.

FleetRun is not directed at children and we do not knowingly collect personal information from anyone under a minimum age to be confirmed with counsel.

Note that the Family Fleet plan supports a household member role intended for younger users, which carries restricted permissions inside a Fleet. If that plan is offered, parental consent requirements under COPPA and the GDPR children’s provisions must be assessed before launch. An account is still created and governed by this policy for any such member.

We will update this page as the product changes, and the date at the top always reflects the most recent revision. For material changes we will give notice in the application before the change takes effect.

Because FleetRun is early, expect this document to change as capabilities are added — particularly around retention, transfers, and any new connected service.

For privacy questions, data requests, or to report a security issue, write to a dedicated privacy contact address — not yet provisioned or use the contact form. See also our Terms of Service and security overview.

An EU/UK representative under GDPR Article 27 has not been appointed and may be required before offering the service in those markets. No Data Protection Officer has been appointed.