Terms of Service

<!-- terms-source-version: 1.29 -->

1. Preamble

READ CAREFULLY BEFORE INSTALLING OR USING RUNMYAI DESKTOP.

RunMyAI Desktop is an AI-powered automation application that delegates the ability to act on your behalf to AI agents. This means the Software can autonomously or under human supervision browse the internet, access your local data, send communications, and execute tasks — all from your own computer.

None of this runs on the Company's servers. The Software runs on your personal computer, uses your internet connection, your real IP address, and — where authorized by you — your local sessions and data. You can reach it while you are away from that computer — from a messaging app, from a browser on your own network, or from another install of your own — and when you do, the work still runs on your computer: what travels is the message, not the task (Sections 2.2 and 6.2(b)).

If you do not agree with these Terms in their entirety, do not install, use, or purchase the Software. Using the Software constitutes full and unconditional acceptance of all terms described herein.

No software is completely secure. The Software reduces the risks described in these Terms; it cannot remove them, and nothing in these Terms promises that it does. You, as an adult user, are responsible for how you use the Software and for any misuse of it by you or by anyone you allow to use it, to use your device, or to reach it over a network (Sections 4, 5.10, 5.12, 6.5 and 8). The Software is released continuously and changes between versions; the version history of these Terms is published at runmyai.app/legal/terms.

These Terms are intended to be clear, honest, and accessible. Any questions: legal@runmyai.app

---

2. What the Software Is

RunMyAI Desktop ("Software") is a personal computer application developed and distributed under the RunMyAI brand by Ritual do Cálculo, Unipessoal Lda ("Company"), a private limited company incorporated in Portugal, tax and registration number (NIPC) 518859002, with registered office at Rua Comissão de Iniciativa, n.º 2-A, 2.º andar, Porta 212, Torre Brasil, Leiria, Portugal, contactable at legal@runmyai.app. The Software uses large language models ("LLM") to plan and execute tasks on behalf of the user, either autonomously or under human supervision.

2.1 The Software IS

• A delegation tool: the user instructs the agent; the agent acts.
• A tool orchestrator: the Software connects local LLMs to built-in tools (web search, email, finance, documents, filesystem within attached workspace folders, image, video, and voice generation, process automation, and other product domains).
• Locally operated software: processing, data, and browsing occur on the user's machine, not on the Company's servers.

2.2 The Software is NOT

• A service operated by the Company: the Software does not execute searches, inference, or actions on the Company's servers, and the Company operates no relay through which your requests or results pass. The Software can be reached remotely — from a messaging channel, from a browser on your own local network, or from another of your own installs — and in every such case the work still runs on your machine; only the message transport crosses infrastructure outside it, either a platform you chose or a server you operate yourself (see Sections 5.9 and 6.2(b)).
• An agent with legal personhood: all actions executed by the Software are legally attributable to the user who authorized them. The Software is a tool, not an autonomous agent with its own legal liability.
• An AI model provider: the Software runs inference on the user's own machine using large language models distributed with or downloaded by the Software, all executing locally. The Software does not call third-party LLM providers on the user's behalf and does not require the user to supply provider API keys.
• Infallible software: LLM outputs are probabilistic. They may contain errors, inaccuracies, outdated information, or content inconsistent with reality.

2.3 Software Capabilities

The Software includes, without limitation, the following capabilities that the user acknowledges and accepts:

• Autonomous internet search from the user's machine
• Web page navigation using a native browser engine (WKWebView / WebView2), including scripted interaction on the user's behalf: clicking, typing into fields, submitting forms and signing in to websites, in a hidden browser window bound to one website that keeps its cookies and session state while that window lives (Section 3.1(d))
• Reading, composing, sending and scheduling emails; managing calendar entries and answering calendar invitations; running the user's own mail rules
• Access to and management of local financial data, including creating and sending invoices and payment requests, creating payment requests through the user's own payment-service account, recording and voiding transactions and transfers, and exporting reports (Section 5.13)
• Follow-up on outstanding requests: the agent can track something owed to the user by another person (a payment, a reply, an approval) and draft reminders to that person by email, over a connected messaging channel, or to that person's agent, on a schedule; each outward reminder is shown to the user for confirmation before it is sent
• Task and project management
• Image generation on the user's machine (stable-diffusion.cpp; on Apple Silicon also the mlx-vlm image engines)
• Video generation on the user's machine (MLX mlx-video, Wan and LTX-2 families; stable-diffusion.cpp, Wan, MiniMax-H3 joint audio and video, and Wan2.2 S2V, which animates a portrait the user supplies to a speech track the user supplies)
• Reconstruction of a 3D model of an object from a picture the user chooses, on the user's machine; the model file carries the AI-generated marker of Section 8.3
• Estimation of the body pose of people in a picture the user chooses (keypoints, joint angles and posture), on the user's machine; it identifies no one and infers no emotion or personal characteristic
• Audio clips the user attaches or records, heard by the on-device model alongside the user's message when that model accepts audio; the clips stay on the user's machine and only their name and duration are kept in the conversation
• Voice synthesis and transcription on the user's machine (text-to-speech and speech-to-text)
• Execution of multi-step plans with parallel sub-agents
• Iterative execution with autonomous refinement (quality loops)
• UI control via navigation commands
• Remote control of the agent from messaging channels (Telegram, iMessage, and, where enabled, WhatsApp, Signal, and an on-device WebChat that the user can also open to other devices on their local network), and from the user's own paired devices (Remote Link). Each install serves a single user; there is no cloud relay and no multi-user access (Section 5.10).
• Server Mode (off by default): on request, the Software serves the user's local model to other programs on this computer or, if the user chooses a network address, to other devices on the user's network, protected by an API key the user controls (Section 5.10).
• Scheduled and proactive autonomous execution: the agent may run tasks on a schedule and initiate messages or actions without a contemporaneous prompt (for example, a morning briefing), subject to the autonomy level configured for the relevant product and surface.
• Reading the user's local message stores when the user enables a messaging channel — for example, the macOS Messages database (~/Library/Messages/chat.db), which contains the user's conversations with third parties (see Section 5.6).
• Agent-to-agent (A2A) communication: the agent may exchange cryptographically signed messages with another person's agent to negotiate an arrangement (for example, a meeting time) within a user-defined, scoped mandate, and may auto-confirm an outcome that falls entirely inside that mandate (see Sections 4.2 and 4.5).
• Video and audio calls between the user and their contacts, established either directly between the two devices (peer-to-peer) or through a media server the user operates themselves. No call media passes through the Company's infrastructure at any point. To discover a usable network path, call setup contacts public STUN servers operated by a third party, which see the user's public IP address and the fact that a connection is being set up, never call content (Section 6.2(d)).
• Recording of those calls on the user's device (and, where the user operates their own media server, on that server), followed by on-device transcription, AI-generated summaries, and extraction of action items and dates, all of which are attached to the originating email thread and made searchable (see Section 5.9).
• Live, on-screen transcription while a recorded call or captured meeting is in progress. The live transcript is never persisted; only the final transcript is stored.
• On-device capture of meetings held in third-party conferencing applications: the Software records the user's microphone and the device's system audio. No bot joins the meeting, nothing is installed on the other side, and the other participants receive no notice from the Software (see Section 5.9).
• Import of externally produced audio and video recordings into the same local transcription and analysis pipeline, and re-transcription of any stored recording with a newer or larger model.
• Digital signature of documents and contracts, and verification of signatures on documents the user receives. The user signs with a certificate file or a hardware token held on the machine, or with a remote advanced-signature service the user links to their own identity (see Section 6.2(i)).
• Local adaptation of the agent's own planning guidance, always on. The Software keeps count of how its own plans fare on the user's machine and, when its rules find a recurring failure in those counts, proposes one small adjustment to how it handles that kind of request. The proposal is shown to the user with the figures behind it; nothing changes until the user approves it; an approved adjustment is measured live against the previous behaviour and withdrawn by the Software if it does worse; and the user can revert any adjustment at any time, which restores the built-in behaviour for what that adjustment changed. Most evaluations end with no change. The adjustment is proposed by rules, never by a model, and learns nothing from the content the agent reads (see Sections 5.2, 6.1 and 6.9).
• Opening at login (off by default) and registering as a handler for document, image and text file types, so that a file the user opens with the Software is passed to it.

---

3. Local Execution and Digital Identity

3.1 Your Searches Leave Your Machine With Your IP

When the Software conducts internet searches, accesses web pages, or makes requests to external services on your behalf, those actions are executed from your computer, using:

(a) Your real IP address

The network address that identifies your internet connection. Unlike cloud-based AI services — where searches and browsing are performed by remote servers in data centers, using those providers' IP addresses — RunMyAI Desktop executes these operations directly from your device.

Every site visited by the agent will see your real IP address.

This means:

• Your geographic location can be inferred by the sites the agent visits.
• Your internet service provider (ISP) or corporate/home network may log these requests as part of your browsing history.
• From the technical and legal perspective of remote servers, agent traffic is indistinguishable from your own browsing traffic.

(b) Your geographic location

Inferable from your IP address by the servers the agent contacts.

(c) Your browser fingerprint

The embedded browser engine (WKWebView on macOS, WebView2 on Windows) carries technical characteristics — operating system version, screen resolution, language, time zone, and others — that third-party sites may use to identify your device, independently of your IP address. Pages may also be fetched by the Software's own HTTP client, which presents a browser-style identification string and has network characteristics of its own.

(d) Browser cookies and sessions

Pages the agent fetches are loaded in a hidden browser window with its own storage, and on macOS that storage is erased when the window is released after the fetch; a window whose erasure the browser does not confirm promptly is discarded rather than reused. Scripted interaction (signing in, submitting a form) runs in a window bound to one website that keeps its cookies and session state across the steps of the interaction and for as long as that window stays open: at most three such windows exist, the least recently used is closed first, and all are closed when the Software quits. The Software does not intentionally keep browsing storage between runs, and nothing is written to your own browsing profile.

In particular, the agent does not inherit your sessions. Cookies and logins created while you browse manually in the embedded panel are not available to the agent's searches, and cookies the agent receives while fetching a page are not available to the panel. On Windows, the agent's own browsing windows share one storage area with each other for the duration of a single run of the Software, which is erased when the Software next starts; on macOS each window is separate from every other.

One consequence is visible to you: because the agent arrives at each site carrying no prior cookies, some sites treat it as a first-time visitor and present verification pages that a browser you use regularly would not show.

3.2 Why This Is Different From What You Are Used To

Users accustomed to cloud-based AI services (cloud-hosted chat assistants and search engines) are familiar with a model where:

• The search is performed by the provider's servers, in geographically distant data centers, using the IP addresses of those data centers.
• The searched site has no connection to the end user's IP address.

RunMyAI Desktop operates on a fundamentally different model:

• The agent acts from your address, as you. Every request made by the agent originates from your IP address and your device; a site may or may not be able to tell it from your own browsing, and in either case the request is attributed to you.
• This is a deliberate architectural choice that offers privacy advantages regarding your data (your data does not pass through the Company's servers), but it means your network identity is used by the agent.

3.3 Legal Implications

All activity performed by the agent on the internet, from your machine, is legally attributable to you. This includes:

(a) Compliance with third-party Terms of Service

You are solely responsible for ensuring that the agent's use of third-party websites, services, and platforms complies with those parties' Terms of Service, including when the agent signs in to a site with credentials you supplied, submits a form, or completes a purchase or registration on your behalf. Many websites and services prohibit automated access, content scraping, bots, software agents, or the circumvention of access controls such as CAPTCHAs. Violations of those terms, and every account, purchase, submission or commitment the agent makes through a site, are your sole responsibility.

(b) Browsing history

Searches and pages accessed by the agent may appear in records held by your ISP, home or corporate router, or any network monitoring systems present in your environment.

(c) Third-party tracking

Sites visited by the agent may collect visit data, set cookies, and process your IP address exactly as they would if you had visited the site manually via a conventional browser.

(d) Personal data under GDPR, LGPD, and US state privacy laws

Under the GDPR (EU General Data Protection Regulation), the LGPD (Brazilian General Data Protection Law), and equivalent laws, IP addresses constitute personal data. In the United States, which has no general federal privacy law, the CCPA/CPRA (California Consumer Privacy Act, as amended by the California Privacy Rights Act) and the other state consumer privacy laws treat an IP address as personal information when it can reasonably be linked to a particular person or household. The processing of your IP address by third-party sites visited by the agent occurs under those sites' own privacy policies, over which the Company has no control.

---

4. Agent Autonomy and Responsibility

4.1 Autonomy Levels

The Software operates at five autonomy levels, configured independently by the user per product and per surface (desktop, the messaging channels, paired MCP clients, and any additional surface). Scheduled and proactive runs follow the desktop setting. Autonomy levels govern actions that change something: writing, sending, spending, creating, deleting, or reaching another person or system. Read-only tools (web search and page retrieval, which use the user's own IP address, and reading the mail, finance, contacts and files the user has given the agent access to) run at every level, including Level 0, without asking. The levels are:

First-launch default. On first launch, every product and every surface is set to Level 0 (Manual). The Software does not recommend raising the level. The user raises each product and each surface consciously after evaluating the risk profile of the specific workflow. Importing data from another installation does not bring that installation's autonomy settings: the levels on this device change only when the user changes them here.

The user is solely responsible for configuring an autonomy level compatible with their personal judgment, their available supervision capacity, and the sensitivity of the tasks being delegated. "Consent fatigue" — approving actions without careful review, or raising autonomy levels without reflection — is the user's sole responsibility.

4.2 Actions With External Consequences — User Assumption of Risk

Some actions, when executed by the agent, reach third parties or external systems that are not party to these Terms (people, services, banks, government agencies, remote APIs). Non-exhaustive examples:

1. Sending emails, messages, or any communication on behalf of the user
2. Executing financial transactions of any amount
3. Accepting Terms of Service on third-party platforms
4. Creating or modifying accounts on external services
5. Sharing the user's personal data with third parties not previously authorized
6. Writing to external APIs, databases, or services not owned by the user
7. Negotiating and auto-confirming an arrangement with another person's agent over the Agent-to-Agent channel, within the scope of a mandate the user defined
8. Executing any of the above on a schedule or proactively, while the user is away from the machine and not contemporaneously supervising
9. Reminding or pressing a third party about a payment, reply or approval owed to the user (Section 2.3), by email, over a messaging channel, or to that person's agent
10. Signing in to a website with the user's credentials, submitting a form, or completing a purchase, registration or acceptance of terms on a website on the user's behalf

The user expressly acknowledges and accepts that:

• At Level 0, such actions are not executed. At Levels 1 and 2, each such action waits for the user's explicit approval.
• At Level 3, such actions execute without approval only under the rule described in Section 4.1; otherwise they wait for approval.
• At Level 4, such actions execute immediately with no runtime confirmation, subject only to the settings below. The agent may send, transfer, accept, or create on behalf of the user at any time, without prompting.
• The configured level applies across the Software, including to financial operations, files, email, contacts, documents, and the other sensitive areas. The user can set any area to "ask every time", in which case its actions ask at Levels 1 to 4 (and still do not execute at Level 0). Installations that predate version 1.24 of these Terms keep "ask every time" in the sensitive areas until the user changes it. A per-action "always allow" that the user grants on the desktop runs that action without asking at Levels 1 to 4, never at Level 0. Saving the credentials of a new account always asks.
• Protection against hidden instructions in external content is a user setting, on by default. While it is on, every action the Software classifies as having an effect outside it (sending, writing, spending, calling an external service, and a web request to a site the run has not already read from) that the agent takes after reading untrusted external content in the same run asks for the user's approval, at every level (Section 5.2). The user can switch it off and on at any time; while it is off, such actions follow the configured level.
• Where an approval is needed and no one is present to give it (a scheduled or proactive run), the action is not executed: the request is refused, or denied when it is not answered.
• The Software does not silently raise the user's autonomy configuration, and every change the user makes to it is recorded in the local audit trail.
• The user assumes full legal, civil, contractual, and reputational responsibility for every action executed at every level, including actions that affect third parties who did not consent to these Terms and who may have their own policies governing AI-agent interaction (for example, anti-spam policies of email providers, AI-transaction rules of financial institutions, bot policies of online services, and the rules that govern reminders about money owed, which in some jurisdictions are regulated as debt collection). Attribution of such actions is to the user, not to the Software or to RunMyAI. The same holds where the agent acted on an instruction the user did not intend, misread a page or a message, or was manipulated by content it read (Section 5.2): higher autonomy levels reduce the user's opportunity to review in advance, and the user should not use any autonomy level for a decision that could cause serious harm if it is wrong.
• The user is solely responsible for deciding whether Level 3 or Level 4 is appropriate for any given product, action, or surface, and for setting per-action or per-product overrides when finer control is desired. The autonomy settings UI presents informative metadata (risk level, categories of user data touched, reversibility) to support the user's decision at configuration time; that metadata is informative only and does not restrict the user's choice.

4.3 User Responsibility

The user is solely responsible for:

• Validating and reviewing all agent-generated outputs before making decisions or acting on them
• Configuring autonomy levels compatible with their available supervision capacity
• Ensuring their use of the Software complies with applicable law in their jurisdiction
• All actions executed by the agent that have been authorized, whether explicitly or through elevated autonomy configuration
• Providing clear and precise instructions to the agent, knowing that ambiguity may result in unintended interpretations

4.4 Iterative Execution and Local Compute Cost

The Software may execute plans in iterative refinement cycles (e.g., generate, evaluate, refine, repeat). All inference runs on the user's machine, so each iteration consumes local CPU, GPU, memory, disk, and battery resources. The user acknowledges that multi-step plans, parallel sub-agents, and quality loops may substantially increase local resource usage, and that there is no per-token or per-call monetary cost paid to the Company or to any third-party model provider.

4.5 AI Disclosure on Agent Communication With Third Parties

When the agent autonomously composes and sends a communication to a third party, the Software marks that communication as AI-generated. For an email sent through the built-in mail tool, the mark has two parts: a short human-readable line in the message body (for example, "Sent by [your name]'s AI agent — RunMyAI") and a machine-readable header. For a message exchanged with another person's agent over the Agent-to-Agent channel, the mark is the machine-readable header: the message body is a signed, encoded envelope addressed to another agent — machine-to-machine signaling already labelled as an agent message at the protocol level, with no human-readable prose to carry a body line. This is the Software's implementation of the transparency obligation in Article 50 of the EU AI Act (see Section 8.3). The marking is applied automatically at the point of sending and the user cannot suppress it for autonomous agent sends.

Replies the agent composes and sends over a messaging channel carry a one-line notice in the message body that the message was sent by an AI agent.

This marking is not applied to messages the user composes themselves in the interface and then sends (the user is the author of those), nor to the connection metadata the Software exchanges to set up a call (Section 6.2(d)), which is machine signaling rather than a communication the agent composed.

The user acknowledges that this automatic marking covers the channels the Software controls. Where the user directs the agent to act through a surface the Software cannot mark, or where local law requires a different or additional form of disclosure, the user is responsible for providing it.

---

5. Known Risks and Limitations

The user acknowledges having been informed of and accepts the following risks:

5.1 LLM Inaccuracy

Large language models generate text probabilistically. Outputs may be factually incorrect, incomplete, outdated, misleading, or inconsistent with reality. No output should be treated as fact, professional advice (legal, financial, medical, technical), or absolute truth without independent verification by a qualified source.

5.2 Prompt Injection

Content the agent reads that the user did not write — web pages and search results, emails, documents, files, messages received on a paired channel, call transcripts, calendar entries, images, model descriptions, and the other tool results the Software's ingress review has identified — may carry hidden text written to give the agent instructions of its own ("prompt injection"). The Software treats every such source as data rather than as instruction, and applies the following deterministic controls to it, all of them on the user's own machine:

• Filtered before the model reads it. Third-party content passes a deterministic filter on the user's machine before it enters the model's context. The filter recognises known injection and exfiltration formulations, including disguised and encoded forms, in every language the Software ships in.
• A model-based pass that runs unless the user turns it off. In addition to the deterministic chain, the Software carries an on-device classifier, switched off in the Trust Center by a user who wants it off. It is on by default. While it is on and the classifier is ready, a page the deterministic chain did not already reject and the classifier scores as hostile is withheld from the model instead of passed on, and the verdict that travels with the content says which layer withheld it. Where the pass could not run, the Software records that rather than treating the page as cleared by it. The text is scored on the machine, and nothing about the page is sent anywhere for that purpose.
• Marked as data. Content that passes the filter is marked as third-party text before the model reads it, so the model is told where it begins, where it ends, and that nothing inside it is addressed to it. This covers web pages and search results, email bodies, documents and their titles and snippets, inbound channel messages, call transcripts and contact context, calendar-derived meeting and summary fields, transaction descriptions read from a bank statement, local files opened because the user named them, retrieval hits whose origin is not established, images handed to a vision model, site-map URL listings, and the descriptive text that accompanies a model the user installs. Shortening the content to fit never removes its marking. Fields that must sit outside the marking to be usable — an email's subject, sender and recipients, a document title — are cleaned of instruction-shaped text instead.
• A verdict travels with the content. Web and document tool results carry a structured verdict — clean, sanitized, or rejected — stating what the filter did to them. Rejected content is withheld from the model rather than passed on with a warning attached.
• Provenance decides trust, and an unrecorded provenance is third-party. Every document indexed for retrieval records how it arrived: typed by the user into the Software's own composer, added as a file, received as a mail attachment, transcribed from a recording, or read from disk by the agent. Only the first of those counts as the user's own writing: choosing a file is not authoring it. Anything whose route is not recorded is treated as third-party, on every operating system the Software runs on, and is filtered accordingly. Content fetched from the web is held in a separate index that accepts only text the filter has already cleared.
• Explicit approval for anything consequential, on by default. While the user's setting "Ask before acting after reading external content" is on, which it is unless the user switches it off, any action with an effect outside the Software — sending a message, writing a file, moving money, calling an external service — taken after the run has read third-party content requires the user's explicit approval. This holds whatever autonomy level the user configured for that product and surface, and no stored auto-approval suppresses it. Where no person is present to answer, the request is refused rather than left waiting: an approval that is not answered, or that cannot be delivered, denies. The user can switch the setting off and on at any time; while it is off, such actions follow the configured autonomy level, and the other controls in this Section keep running.
• Outbound screening for secrets and known exfiltration shapes. Before a web request, an email, a payment request, a call invitation or an agent-to-agent message leaves the device, its content is screened for credential-shaped values, known exfiltration destinations and long encoded values in web addresses. A match aborts that action; the Software does not remove the match and send the remainder. Messages the agent sends over a messaging channel are handled differently: credential-shaped values are replaced with a marker and the rest of the message is sent. The screen recognises these shapes only; it does not detect personal data written in ordinary words.
• Web access is checked against the user's own network. Every address the agent asks the Software to open on the web is validated before a connection is made: an address that points at the user's local network, the machine itself, or a cloud metadata service is refused, whether it is written directly, reached through a redirect, or returned by a name lookup that changes its answer. For pages loaded in the built-in browser the check is weaker: a site name the Software has not resolved before is let through and checked on the next navigation, and on macOS background requests to private addresses written as numbers and to known internal host names are blocked at the browser layer. These browser-path checks reduce but do not eliminate the risk that a hostile page reaches a device on the user's network.
• Answers are screened before they are shown. A model's answer is checked before it reaches the user: a link to a known exfiltration destination and any credential-shaped value are replaced by a redaction marker, and a link to a destination none of the turn's sources mentioned is marked as untrusted.
• The interface fetches nothing on the model's behalf. Remote content referenced in a model's answer, a remotely hosted image above all, is not loaded while that answer is displayed. It loads only if the user clicks it, so the model's own output is not designed to become a request to a third-party server.
• Content the agent reads is not used to teach it. The local adaptation of planning guidance described in Section 2.3 learns only from turns that read no third-party content at all. A turn that read a web page, an email, a document, a file, a channel message, a recall hit or any other content the user did not write, a turn in which the filter above matched anything, and a turn that did not originate on the user's own desktop are all excluded from that learning entirely. The learning reads counts of outcomes, never text: no word of any page, message, document or model answer is read into it, so free text cannot become an instruction. It can change the agent only through a closed set of planning adjustments, each approved by the user before it is used and reversible afterwards. No adjustment can add a tool, raise an autonomy level, or bypass any approval described in this Section.
• No cloud step anywhere in this. Every control above runs on the user's machine. No content is sent to a service for classification, and no inference happens off the device.
• Measured, not asserted. A curated adversarial corpus of injection and exfiltration cases is run against these controls in the Software's own test suite before a release, and that run reports the measured rate. It is a curated set and not a live attack rate: it establishes that the controls catch the cases in it, not that no case exists that they miss.

Prompt injection is not a solved problem in the field, and the Software does not present it as one: published research treats detection-based defenses as bypassable by an attacker who adapts to them. What remains, therefore, is that hostile content may reach the model despite these controls and influence what the agent proposes. Bounded by the architecture described above, that means the agent may propose or take an action the user did not intend, within the access the user granted it, and data the agent can already reach may be carried into an action the user approves. Data the agent can already reach may also be carried out through the address of a web request it makes (for example a page address that contains a fact read earlier); the Software asks for approval before such a request to a site the run has not already read from, but only while the protection setting described above is on. There is no cloud inference, nothing is sent to the Company, and the outbound paths are the ones Section 6.2 enumerates. The user should be aware of this risk, particularly when directing the agent at content from a source they do not trust.

These safeguards reduce, but do not eliminate, the risks described in this Section. They are disclosed here as evidence of the Software's safety-by-design; they are not a warranty, and the user's responsibilities under Sections 4 and 8 are unchanged.

5.3 Session and Cookie Isolation

The agent does not browse with the user's sessions, and the storage of a fetch window is erased after use (Section 3.1(d)). Three residual limits are stated here rather than left implicit. A window the agent uses for scripted interaction with one website keeps that site's cookies and session state for as long as it stays open, so a later task on the same site in the same run may find the agent still signed in. The erasure of a fetch window is issued as soon as it is released; if the browser does not confirm it promptly, the window is discarded instead of reused. And on Windows the agent's browsing windows share one storage area with each other during a single run of the Software, which is erased when the Software next starts and not when a window is released, so a site the agent visits may be able to observe storage set by another site the agent visited in the same run. None of these paths reaches the sessions the user establishes personally in the embedded panel. The user may clear this data via the Software's settings.

5.4 Unintended Scope Escalation

When operating with multiple tools in parallel or iterative execution, the agent may access data domains beyond what was originally intended by the user (e.g., when searching for a project, the agent may access related emails). Use of supervised mode is recommended for highly sensitive tasks.

5.5 Third-Party Availability

The Software depends on third-party APIs and services (web search engines, email providers used by the local mail client, and other external services) that may be unavailable, may alter their terms of use, or may be discontinued without prior notice. The Company assumes no liability for interruptions caused by third parties.

5.6 Access to Sensitive Local Data

The Software, when authorized by the user, may access emails, documents, financial data, and other sensitive local data. The user is responsible for defining what data the agent may access and for not authorizing access to data whose exposure to the agent would be undesirable.

In particular, when the user enables the iMessage channel, the user grants the Software Full Disk Access in the operating system's settings and the Software reads the local macOS Messages database (~/Library/Messages/chat.db). That database contains the user's entire conversation history, including messages exchanged with third parties who are not party to these Terms. The user acknowledges this scope of access and is responsible for the third-party personal data thereby made available to the agent, including any obligations the user has as a data controller under applicable data-protection law. Before the iMessage channel can be enabled, the Software requires the user to acknowledge this third-party access in a dedicated in-app disclosure; the channel cannot be activated until that acknowledgment is given.

5.7 Local Key File Dependency

The user's local database (runmyai.db) is encrypted at rest. The 256-bit master key is stored on the same computer: in an owner-only key file in the application's local data directory on macOS and Linux, and in the Windows Credential Manager on Windows. Anyone who controls the user's operating-system account, or who copies both the database and its key (for example through a backup that captures the data folder), can read the data; the operating system's disk encryption is part of what protects it when the computer is off. The Company does not store, copy, escrow, or transmit the master key, and there is no recovery mechanism on the Company's side.

The user acknowledges that loss of the key — whether through operating system reinstall, hardware change, user account loss, disk format, or any other event that destroys it — renders the local database, and the call and meeting recordings encrypted under the same master key (Section 6.1), permanently unreadable. The Company holds no copy of the key and cannot recover the data.

The only sanctioned path for moving data between installs, or for keeping an independent copy that survives loss of the key file, is the password-protected Export and Import flow described in Section 6.7. The export contains the database — including every transcript, AI summary, and search index derived from recordings — but not the recording media files themselves, which have no key-independent backup path and are permanently lost with the key file. The user is solely responsible for proactively creating such an export before any event that may destroy the key file.

5.8 Channel and Agent-Mesh Safeguards

Because remote control and agent-to-agent communication widen what the agent can do, the Software applies deterministic safeguards on these surfaces that operate independently of the configured autonomy level:

• Pairing by one-time code. A messaging channel accepts commands only from the devices or accounts the user paired through a short-lived one-time code generated on the desktop; messages from any other identity are dropped. On iMessage, only messages delivered over the iMessage service are accepted, because the sender of an iMessage is authenticated by the platform; an SMS or RCS message forwarded from the paired phone is not, since its sender number can be forged. A newly paired device starts with read-only scope, and each paired device is rate-limited.
• Reduced default scope on remote channels. Financial mutation operations are excluded from the default capability scope granted to a paired channel and require explicit opt-in, to reduce the risk that a compromised channel moves money.
• Outbound redaction. Credential-shaped values are stripped from every message the agent sends out over a channel before it leaves the device. What the agent says over a channel (an answer that quotes the user's mail, finances or files) is readable by the operator of that platform under its own terms (Section 6.2(b)).
• Scoped, signed mandates for agent-to-agent. An agent-to-agent negotiation is bounded by a user-defined mandate enforced in code (counterparties, topics, time window, duration; a field the user leaves empty places no limit on that dimension), every message is cryptographically signed and verified, and an unsolicited first contact is held for explicit human approval before the agent will respond. By default the Software drafts the reply or commitment and waits for the user; it answers alone only at an autonomy level the user set for that surface and with the external-content protection switched off.
• Remote Link carries the desktop. A device the user pairs through Remote Link has the authority of the desktop interface at the autonomy level set for that surface; the user is responsible for every device they pair and for unpairing a device they no longer control.
• No remote command before acceptance. A paired device cannot drive the agent while the desktop is showing a version of these Terms the user has not yet accepted.

These safeguards reduce, but do not eliminate, the risks described in this Section. They are disclosed here as evidence of the Software's safety-by-design; they are not a warranty, and the user's responsibilities under Sections 4 and 8 are unchanged.

5.9 Recording of Calls, Captured Meetings, and Imported Recordings

The Software can record video and audio calls, capture meetings held in third-party conferencing applications, and import recordings produced elsewhere (Section 2.3). Every such recording, and every transcript, summary, and search index derived from it, contains the voice — and on video calls, the image — and the spoken words of the other participants, who are third parties not party to these Terms.

(a) Where this data lives. Recording, transcription, summarization, and indexing run on the user's device (or, for server-side call recording, on a media server the user operates). Nothing is transmitted to the Company. The user is the controller of this third-party personal data under the GDPR, the LGPD, and equivalent laws, with all obligations that role carries. Where the user records conversations in a professional or business context, personal-use exemptions of data-protection law will generally not apply.

(b) Participant consent is the user's responsibility. The laws governing the recording of conversations differ by jurisdiction and are determined by the location of every participant, not only the user's. Many jurisdictions require the consent of all participants before a conversation may be recorded or transcribed; in some, recording without consent is a criminal offense. Consent to be recorded does not automatically extend to transcription, AI analysis, indexing, or storage; where the applicable law distinguishes these, the user is responsible for covering each of them. The user is solely responsible for identifying the applicable law and for obtaining any consent or providing any notice it requires, before recording, capturing, or importing.

(c) What the Software does and does not do. Before the first recording, capture, or import on an install, the Software requires the user to acknowledge this responsibility in a dedicated in-app notice; recording, capture, and import are not available until that acknowledgment is given. While a call is recorded or a meeting is captured, the Software displays, by default, a persistent recording indicator on the user's device; after giving the acknowledgment described in this subsection, the user may turn this indicator off in the Software's settings. During a meeting captured from a third-party conferencing application, the Software gives no notice of any kind to the other participants — it records the audio the device already plays and captures. Informing the other participants is solely and entirely the user's obligation.

The acknowledgment notice and the recording indicator are awareness aids for the user only. They are visible solely on the user's own device, are not notice to or consent from any participant, are not legal advice, and do not satisfy any notice or consent obligation that applicable law places on the user. They do not transfer to the Company any part of the responsibility described in subsection (b), whether the indicator is on or off.

(d) No biometric identification. The Software transcribes speech to text; it does not create voiceprints, speaker-identification templates, or any other biometric identifier from recordings. The Company will not add such processing without updating these Terms.

(e) Retention and deletion. Recordings, transcripts, and derived data are retained locally until the user deletes them. Requests from recorded participants to access or delete their data are directed at the user as controller; the Company holds no copy and cannot act on them.

5.10 Network Exposure the User Chooses

Three features open the Software to other devices. Each is off by default, is turned on only by the user, and is the user's own decision and responsibility:

• WebChat on the local network. When the user switches on network access for WebChat, the Software listens on every network interface of the computer on port 7880, over a connection it encrypts with a certificate it created itself; a phone's browser will warn about that certificate, and the user must verify the fingerprint the Software shows. Anyone on the same network can reach the sign-in page; access requires the one-time pairing code and a session token.
• Server Mode. When the user binds Server Mode to a network address rather than to this computer alone, any device on that network that presents the API key can use the user's models and this computer's processing power. The key is stored on this computer in a file readable only by the user's own account, and it travels over the network unencrypted (plain HTTP); on an untrusted network it can be observed and reused.
• Remote Link and paired MCP clients. A paired device or client reaches the agent with the scope and autonomy level the user set for it (Sections 5.8 and 6.2(h)).

The user is responsible for the network these features are exposed on, for the key, pairing code or token that protects them, for every device that connects through them, and for turning them off when they are no longer needed. Use them only on networks the user trusts.

5.11 Generated Media, Likeness and Voice

The Software can generate images, video, speech and 3D models, animate a portrait the user supplies to a speech track the user supplies, and synthesize speech. The user is solely responsible for having the right to use any person's image, likeness, name or voice they supply or ask the agent to depict, including the user's own contacts, and for obtaining any consent the applicable law requires. The user may not use these features to produce sexual content involving a real person without that person's consent, content that sexualizes minors, or media that deceives a person about a real individual's words or actions. Generated media carries the machine-readable AI-generated marker described in Section 8.3; the user may not remove it and is responsible for any disclosure that the law of the place where the media is published requires in addition to it.

5.12 Security Measures Are Reasonable, Not Absolute

The Company designs the Software with security measures it considers appropriate to the risks described in these Terms, publishes security updates, and receives vulnerability reports at legal@runmyai.app, which it handles under a coordinated disclosure practice. No software or computing environment is completely secure, and the Company does not promise that the Software is free from vulnerabilities, errors, interruptions or attacks, or that any safeguard described in these Terms will hold against every adversary. The Software runs on the user's device and on accounts and services the user controls: the security of that device, its operating-system account, its passwords and permissions, the connected accounts, the backups and the network is the user's responsibility, and the user should install updates when the Software offers them. Section 7.4 states what this Section does not limit.

5.13 Financial Features and Document Signing

The finance features organize and analyze data the user provides or connects, and act on it as the user's autonomy configuration allows (Section 4.2). They are not financial, investment, tax, accounting or credit advice; the Company is not the user's adviser; and calculations, categorizations, extractions and projections produced by a model may be wrong. The user is responsible for the accuracy of the data, for every tax or legal filing, and for every financial decision and transaction, including one the agent executed at an autonomy level the user set.

The Software can apply electronic signatures to documents (Sections 2.3 and 6.2(i)). Unless a document is signed with a certificate issued by a qualified trust service provider, the signature is a simple or advanced electronic signature whose legal effect, and whose acceptance by a counterparty or authority, depends on the applicable law and on that counterparty. Every signature applied by or through the Software is the user's own: the user is responsible for reading the document, for their authority to sign it, for who may use their signing keys and credentials, and for the consequences of the signed document. The Company is not a party to any document the user signs and gives no legal advice.

---

6. Data and Privacy

6.1 Locally Processed Data

The Software stores all user data locally, on the user's own computer. Its main location is the application's data directory:

• macOS: ~/Library/Application Support/com.runmyai.desktop/
• Windows: %APPDATA%\com.runmyai.desktop\

Caches, logs and temporary files are kept in the locations the operating system provides for them, and downloaded model files in the model folders the Software uses. When the user runs MyAI from a separate volume (the MyAI Wallet), the user's content -- the database and its key file, MyAI and the models, documents, images, generated media, recordings, attachments, the local backups, the default location of the password-protected export, and the messaging-channel session state -- is kept on that volume, and copies of that content that earlier versions of the Software left on the computer are moved there at start. What stays on the computer in that mode is the application's own state (its preferences, the licence, diagnostics, helper programs and the record of acceptance of these Terms), the speech-synthesis model, the logs, and caches and temporary files, including the training workspace of a MyAI training run while that run is in progress.

The user's primary data store is the local database file runmyai.db inside that directory. This database holds, among other things, mail bodies and credentials, financial extractions, MyChat conversation history, vector embeddings, local diagnostic data, and everything MyAI learns from: the state of MyAI training (what has already been extracted, the fixed evaluation set and the retention baseline) is kept in the database, and the training pairs are kept between runs in one file of their own, described next, so that an incremental retrain can extend the previous dataset.

The same database also holds the record of every adjustment the local adaptation of planning guidance (Section 2.3) proposed, together with its approval, rejection, live measurements, promotion, retirement or reversal and the counts behind each. The database also holds the message history of the agent's own sub-agents that a conversation keeps addressable between requests. Both stores are encrypted with the rest of the database, are erased when the user deletes their data (Section 6.4) — the sub-agent history also when its conversation is deleted — and leave the machine only inside a bug report the user reviews and sends (Section 6.6(a)) or, for adjustments, as the anonymous outcome counts described in Section 6.9(a).

The entire runmyai.db file is encrypted at rest with AES-256 via SQLCipher v4 (page-level AES-256-CBC, HMAC-SHA512, PBKDF2-HMAC-SHA512 key derivation with 256,000 iterations). The 256-bit master key is generated on first launch via a cryptographically secure random number generator and stored in a key file in the application's local data directory, protected by operating-system file permissions. The Company never receives the key and has no mechanism to decrypt the user's data. See Section 5.7 for the consequences of losing the key file.

Four kinds of files are kept outside runmyai.db and are encrypted at rest with AES-256-GCM under keys derived from the same master key that protects the database: call and meeting recordings, mail attachments (those received and those attached to a draft), the MyAI training dataset (myai-dataset/sft_dataset.enc, whose plaintext pairs exist only inside a training run's workspace), and the temporary copy of the database that Smart Reset makes while it runs and removes once it has finished. An attachment is decrypted only when the user opens or saves it or the Software reads it; the decrypted copy is temporary and is removed when no longer needed and at every application start.

Call and meeting recordings are stored as individual files in a subdirectory of the same application data directory. A recording is decrypted only transiently, for playback or processing; the transient copies are removed when no longer needed and at every application start. Recordings made by versions of the Software that predate this encryption are migrated to the encrypted form automatically. The transcripts, AI summaries, and search indexes derived from recordings are stored inside the encrypted database. Deleting a recording removes the media file and its derived data. When the user operates their own media server (Sections 2.3 and 5.9), server-side call recordings are stored on that server's disk, under retention and access controls the user administers.

The following are stored unencrypted, each for the reason given, and are protected by the operating system's file permissions (and by full-disk encryption where the user has turned it on):

• Files the Software opens by path or hands to another program: images in conversations; generated images and videos, which carry the AI-generated marker (Section 8.3); the shared media library, holding the pictures a product imported and the retained copies of the inputs behind generated media; MyDocs documents with their source files, revisions, signed copies and templates; the user's profile picture; and images pasted into a mail draft.
• Messaging-channel sessions: the WhatsApp session, which the WhatsApp component reads from disk and of which an encrypted copy is also kept in the database; and the Signal account state (keys, sessions and message store), which the Signal component keeps in its own format in a folder of the application readable only by the user's own account.
• MyAI model weights: the adapters and fused models trained on the user's data, which the model runtimes load from disk. The training pairs are written to disk only for the duration of a training run, into a folder readable only by the user's own account, and are deleted when the run ends and, if the run was interrupted, at the next start.
• Logs: the application's log files, up to about 128 MB with the oldest removed first, which can contain email addresses, excerpts of chats and searches, prompts given to the generators, and file paths.
• Performance ledger: one line a day, in a file of its own, holding how fast the local models ran (rates and shares of time) and the name of the other program on the computer that used the most graphics-processor time while they ran, so that a slow day can be explained. The name is the program's process name only, never its command line, window title or file path. The ledger never leaves the computer, is not part of a bug report, and is erased by Delete All Data and by every Smart Reset (Section 6.4).
• Local backups: the backups the Software makes into its own backups folder (by default when the application closes, keeping the newest 10), which hold a copy of the database, still encrypted, together with unencrypted copies of the files listed above.
• Working files: the storage of the agent's browsing windows (Section 3.1(d)), and the temporary files the Software hands to a converter, a transcriber, a player or another program, which are removed after use.
• Application state files: the application's own settings and preference files; the licence token and the random installation identifier (Section 6.3(a)(2)), in files readable only by the user's own account, the token carrying the account email and identifiers of the purchase; the Server Mode settings with their API key, likewise readable only by the user's own account; the staged-update cohort number; a record of the last version launched; a calibration file of measured model speeds keyed by model file path; the model-download queue; a small agent configuration file in the user's home folder (~/.runmyai/agent.json: budgets and opt-in toggles); a cache of mean embeddings of the Software's built-in phrases (obfuscated, not encrypted, holding no user content); and the daily diagnostics (database size history, schema-start trace and reset receipt: step names, counts and timestamps only). None of these holds the user's content; Delete All Data does not remove them (Section 6.4).
• The database key file described above, and the prefix snapshots described next.

Database files that earlier versions of the Software kept beside runmyai.db unencrypted, and that no current version uses, are removed at every start.

When the Software runs a local model through its llama.cpp runtime, it also keeps, in a .kv-cache folder inside the folder that holds that model file, a per-model snapshot of the model's pre-computed working state (its key-value cache) for the fixed instruction prefix the Software places ahead of every request, so that the prefix need not be processed again on every start. A snapshot holds only that fixed instruction prefix, which is built solely from instruction text that ships with the Software and is the same for every user, together with a fixed placeholder message and, where the model's own prompt format inserts one, the current date. It never holds the content of a conversation or request, or the user's profile (such as the user's name, work schedule or preferred language). The instruction text in a snapshot is sealed on disk under a key derived from the database key; the cached model state itself is stored unencrypted because it holds no user content; and each snapshot is authenticated with a key derived from the database key, so a snapshot that fails that check is deleted and not used. At every start the Software deletes, in the snapshot folder of every model it has recorded, every snapshot that is not so authenticated, that was written under an earlier snapshot format, or whose model is no longer present; the first start of each new version of the Software does the same in every snapshot folder under its model folders. Delete All Data and Smart Reset (Section 6.4) empty the snapshot folder of every model the Software has recorded and every snapshot folder under its model folders, without touching the model files.

This data is NOT transmitted to RunMyAI, except as described in Section 6.2; when the user explicitly submits a bug report, as described in Section 6.6; or as the automatic, anonymous ModelIndex performance contribution described in Section 6.9.

6.2 Data Transmitted to Third Parties

When using the Software, the following data may be transmitted to third-party services:

(a) Sites and services accessed by the agent Web content accessed by the agent is returned to the local LLM context. The user's IP address and browser fingerprint are transmitted to the servers of those sites (see Section 3). These include the search engines the agent queries, the caption track of a video page the user names, structured-data services such as weather and encyclopedia lookups, the web page of the user's own mail host when the agent is setting up webmail, and the website of a domain the user names when importing a brand kit for signatures.

(b) Messaging platforms used to control the agent When the user pairs a messaging channel, the message content the user sends to the agent and the agent's replies transit the infrastructure of that platform (for example, Telegram's Bot API servers, or Meta's servers for WhatsApp). For iMessage, replies are sent through the user's own Messages application. This traffic flows under the platform's own terms and privacy policy; it does not pass through RunMyAI servers.

(c) The user's own mail account, and recipients of agent communications To provide the mail, calendar and contacts features, the Software connects to the servers of the mail provider the user configures and synchronizes the user's own mailbox, calendars and contacts with them: over IMAP and SMTP, over JMAP and its push channel, over CalDAV and CardDAV, and, for a self-hosted mail server the user operates, through that server's account interface. These connections carry the user's credentials and mail to and from the user's own provider, under that provider's terms. When the user tests the deliverability of their own domain, the Software also sends test messages through the user's own outgoing server to a mailbox of the user's that the Software synchronizes, and checks the encryption (TLS) set-up of the user's mail host.

Email sent by the agent and Agent-to-Agent messages are delivered to their recipients through the user's own mail provider and the recipient's mail provider. They do not pass through RunMyAI servers. Such outbound agent communications carry the AI-disclosure mark described in Section 4.5. To authenticate the agent of another person, the Software looks up a public DNS text record on that person's mail domain, through the system's DNS resolver, falling back to a public resolver only when the system's configuration cannot be read.

When the user chooses Unsubscribe on a message whose sender offers one-click unsubscribe (RFC 8058), and only then, the Software sends one HTTPS POST request, with the body List-Unsubscribe=One-Click, to the address the sender wrote into that message. The request carries no message content and no credentials. The server that receives it sees the user's IP address and learns that the mailbox is active. The Software refuses to send it to an address that is not HTTPS or that points to a private or local network, follows no redirect, and gives up after 15 seconds; where one-click is not offered or does not succeed, the Software offers the sender's page or address for the user to open instead.

Remote content a message body references — images, and whatever else it points at — is never fetched while the message is in its default blocked state. When the user allows remote content for one message, or for every message from a sender's domain, the Software fetches the referenced assets over HTTPS itself and inlines them into the reading view, so that view holds no network reference of its own. The server that serves an asset therefore sees the user's IP address, and the sender learns that the message was opened. An asset that is a vector image, whose decoded size is that of a tracking pixel, or that exceeds the size ceiling is refused and shown as a placeholder; the Software follows no redirect to a private or local network, gives up on a request after 10 seconds, and holds what it fetched only in memory for the session.

(d) Call signaling through the user's mail provider When the user initiates or answers a call (Section 2.3), the connection metadata — a structured call invitation and answer carrying network addresses and encryption public keys, never call content — travels as email through the user's and the contact's mail providers, under those providers' own terms and privacy policies. In addition, every email sent from the built-in mail client carries a short machine-readable header that marks the sending installation as able to receive calls; recipients and mail providers can therefore technically observe that the user runs the Software. Call media itself never transits the mail provider: it flows directly between the devices or through the user's own media server (Section 5.9). To find a network path between the two devices, call setup contacts public STUN servers operated by a third party; those servers see the user's public IP address and that a connection is being set up, and nothing of the call.

(e) Mail account setup (auto-discovery) When the user adds a mail account, the Software determines the provider's server settings automatically. To do so it may query, in parallel: the provider's own configuration endpoints (autoconfig.<domain> and well-known paths on the provider's domain — these requests may carry the email address being configured, which that provider already knows); the public Thunderbird ISPDB configuration database operated by the Mozilla Foundation (autoconfig.thunderbird.net — this request carries the mail domain only, never the address); and the mail domain's public DNS records (SRV and MX lookups through the system's DNS resolver, falling back to a public resolver only when the system's configuration cannot be read). The Software also opens a connection to the candidate mail-server ports of the mail domain, including a TLS handshake, to read the server's greeting, and requests the well-known JMAP address on that domain; nothing is sent over these connections. These lookups run only during account setup, at the user's initiative; they transmit no password, no message content, and no identity beyond what is described above, and they receive only public server-configuration data in return.

(f) Reference-data and measurement endpoints The Software makes a small set of public, unauthenticated requests that carry no user content, account, or identity: currency exchange rates for the finance features (fiat rates from the Frankfurter service; crypto rates from the CoinGecko service — the requests carry currency codes only), and internet speed and latency measurement against public measurement endpoints (Cloudflare's speed-test and network-trace endpoints and Hetzner mirror servers) used to size model downloads and display connection health. Whether the computer is connected at all is read from the operating system, which sends nothing. While the Software is running it also uses the same latency measurement in the background, only when there is a reason to: when the operating system reports that the network has changed; when a reading older than 10 minutes is needed, because the agent is planning a task that can use the web or the user opens the Reach panel; after a failed check, again after 1, 2, 4 and 8 minutes and then every 15 minutes until one succeeds; every 15 minutes while a window of the Software is in the foreground; and once about a minute after launch. Each such check sends one request, alternating between the Cloudflare network-trace endpoint and a Hetzner mirror server, or two, one to each, when the Reach panel asks for a fresh reading; each request is a plain HTTPS request whose answer is not read, only timed. No check is sent while the operating system reports no network connection. As with any internet request, the user's IP address is technically visible to the receiving server; results are stored locally only.

(g) Domain DNS management (user-configured) When the user connects their own Cloudflare account to manage DNS records for their mail domain, the Software sends requests authenticated by the user's own API token to Cloudflare's API, and verifies record propagation by querying a public DNS-over-HTTPS resolver for the user's domain. This feature is user-initiated and uses the user's own account throughout. Separately, when the user checks whether their domain is ready to deliver mail to particular addresses, the Software sends DNS-over-HTTPS queries to Cloudflare's public resolver for the mail-exchanger (MX) record of the domain of each address the user enters, as well as for the records of the user's own domain. These queries carry domain names only, never a full address or any message content; Cloudflare, as the operator of the resolver, sees which domains were queried and the user's IP address.

(h) Paired MCP client software (local, user-configured) When the user pairs their own MCP-capable client software with the Software, the Software accepts requests from that client on a local loopback endpoint only (127.0.0.1:57292); the endpoint is not reachable from other computers and runs only while at least one such pairing is active. Each pairing is a device with its own bearer token, of which the Software stores only a hash, and its own access scope, which defaults to read-only; the pairing expires after 90 days and the user can revoke it at any time, which takes effect at the next request. Before any request is served the Software checks this acceptance, the token, a per-device rate limit, and the scope; every action that changes data follows the autonomy level the user set for the MCP surface (Level 0 refuses it; Levels 1 to 3 ask for approval on the user's desktop; Level 4 runs it without asking unless the area is set to ask every time or the external-content protection applies), and the scope never lifts that gate; every response passes the same outbound secret redaction applied to messaging channels; and every call is recorded in the local audit trail with the device as origin. The paired client is the user's own software: the data it receives is whatever the user's chosen scope allows, and wherever that client forwards it -- including to any remote model or service backing it -- is the user's configuration and the user's responsibility, under the terms of that client and service. The Software does not send anything to such a client on its own initiative.

(i) Document signing and signature verification (user-configured) When the user signs a document with a digital certificate, what the Software contacts depends on the certificate chosen. A certificate file or a hardware token held on the machine signs entirely on the device and contacts nobody. A gov.br advanced signature does not: the user signs in at that service (sso.acesso.gov.br), and the Software then asks the signature service operated by the ITI (assinatura-api.iti.br) to return the user's own public certificate and to produce the signature. The signing request carries the SHA-256 digest of the document and nothing else — the document itself never leaves the machine on this path — and the authorization it uses is single-use, short-lived, and never written to disk. Where the user configures a timestamp authority, the Software sends that authority the digest of the signature so it can attest the time, again never the document. Separately, when the Software checks whether a signing certificate is still valid — the user's own, or one on a document the user received — it contacts the revocation endpoints named inside that certificate (an OCSP responder, or a certificate revocation list distribution point). Those addresses are chosen by whoever issued the certificate, not by the user and not by the Company, and the request identifies the certificate being checked. All of these run only when the user signs a document or verifies a signature.

(j) The user's own payment-service account (user-configured) When the user connects their own payment-service account (Stripe) to the finance features, the Software sends requests authenticated by the user's own API key to that service: to verify the connection, and to create payment requests, which carry the amount, the currency, the invoice's internal identifier and the invoice number. The Software also listens on the loopback address of this computer (127.0.0.1:57291) for payment events the user forwards from their own account at that service; the listener is not reachable from other computers. The account, the credentials, and the relationship with the payer are the user's own, under that service's terms; the Company operates nothing in this path and receives nothing from it.

(k) Native reminders and tasks bridge (user-configured) When the user enables the reminders and tasks bridge, the Software writes reminders and MyProject tasks into a reminders list the user selected in the operating system's own reminder store, and reads back what the user wrote in that list, so a change made on either side appears on the other. The bridge is off unless the user turns it on, and turning it on requires acknowledging a notice that names the destination; the user then chooses which lists are in scope. The Software reads each list's own account at the time of the operation to determine whether the list is held on the device only or belongs to an account that syncs to a server, and shows that classification on each list in the picker. Where the list belongs to a synced account, the copies the Software writes into it are carried off the device by that account's own sync, to that account's provider, under that provider's terms and privacy policy; the Software contacts no server on this path and names no destination of its own. Deselecting the list, or turning the bridge off, stops the next operation. Where a list is shared with other people, the text in it may have been written by those other people.

(l) WebChat on the user's network and Remote Link (user-configured) When the user enables WebChat, the Software serves its interface on the user's own computer, on the loopback address by default. If the user enables network exposure (Section 5.10), it listens on port 7880 on the local network with a certificate it created itself, protected by a one-time pairing code and rotating session tokens, so a browser on another device on the same network can reach it. Remote Link carries the same interface between the user's own devices through a media server the user operates, with every message sealed end to end. Nothing on either path passes through the Company.

6.3 Telemetry, Analytics, and Service Connections

RunMyAI Desktop collects no telemetry about the user's content or activity: no analytics of what the user does, no automatic crash reports, no keystroke or interaction tracking, and no content, activity or hardware identifier; the licence service recognises a licence and its activated installations, as (a)(2) below describes, and nothing more. Only two kinds of data about the user's system leave the device for RunMyAI, and neither carries the user's identity, content, or stored IP address:

• an automatic, anonymous ModelIndex performance contribution (Section 6.9), which reports how models ran on the hardware, never what the user did with them; and
• a bug report the user chooses to send (Section 6.6), which is user-initiated and shown in full for review before it leaves the device.

(a) Service connections. In addition to those two data flows, the Software makes a small set of content-free service connections to infrastructure operated by the Company or on its behalf (and, for item 5, to a public model hub). They exist to keep the Software working — updates, licensing, model delivery — and none of them transmits user content, activity, or any telemetry about the user. None of them is made before the user has accepted these Terms:

1. Update check and download. The Software periodically (shortly after launch and approximately every six hours) asks the Company's update endpoint whether a newer version exists. The request names the operating system, CPU architecture and the installed app version in its address, and carries as a header a rollout cohort number — a random number between 0 and 99, drawn once on the device and stored locally, that lets a new release be offered to a growing percentage of installations. The cohort number is not derived from the hardware and is shared by roughly one install in a hundred; it identifies neither the device nor the user. Nothing else accompanies the request. When an update exists, the Software makes one further request to the Company's published-build manifest, which carries no payload (on Windows it names the platform in the address), downloads the update from the same infrastructure and cryptographically verifies its signature before applying it.
2. License activation and refresh. Activation happens one of two ways, and neither sends usage data or user content. Pasting a license token is local: the Software verifies the token's signature on the device and contacts no server; that token — a value that identifies the purchase, not the user's content — is first sent to the Company's license endpoint at the first periodic refresh, and periodically thereafter, to renew the entitlement. Signing in instead pairs this installation with the user's account: the Software asks the Company's license endpoint for a short confirmation code, opens the Company's confirmation page in the browser so the user approves that code where they are already signed in, and then collects the license token from the same endpoint. The start request carries the two values described next; the polling requests carry the confirmation code and a secret the Company's endpoint issued for this pairing, which the installation holds only until the pairing settles and then discards. The confirmation page is opened without the code in its address, so the link alone cannot approve anything. On this path the token arrives at activation and is refreshed periodically like a pasted one. Two further values accompany these requests, and only these: a random installation identifier generated on the device (a random value stored locally, not derived from the hardware, and carrying no serial, network address, or other property of the machine) and the operating-system family (for example "macos"). They exist so that one licence runs on a limited number of devices and so the user can see and remove their own activated devices from their account. No usage data accompanies the token.
3. Subscription management. When the user opens Manage Subscription, requests authenticated by the license token are sent to the Company's subscription endpoint; payment itself is processed by the payment provider under its own terms.
4. Release notes. Opening the in-app release notes fetches the public changelog from the Company's endpoint. The Software also fetches it once, shortly after the first launch of a new version, to tell the user whether that release changes how data is handled. The request carries no payload.
5. Model catalog and downloads. Downloading a model or runtime component fetches files from the Company's model repository or, for models the user chooses to get from there, from the Hugging Face model hub, a third party; the request identifies the file being fetched, not the user. Browsing or searching that hub from the model library sends the text the user typed and the repository names listed to the hub, with the user's IP address.
6. ModelIndex contribution token. When fewer than two unused anonymous tokens (Section 6.9(a)) are stored on the device, the Software requests one in a contribution cycle: it first fetches the Company's public token key, a request that carries no payload, and then sends the license token, the identifier of that public key, and one blinded value that the Company signs without being able to read it. The request carries no report data and nothing else, and the Company issues at most two tokens per licence in any 20-hour window. What the Company stores about it is stated in Section 6.9(a).

As with any internet request, the user's IP address is technically visible to the receiving server at the network level. The Company does not use these connections to identify, track, or profile the user.

The bug report is always:

• Per-report opt-in — there is no global "share telemetry" toggle and no silent background transmission of any kind.
• Previewed in full before sending — the user sees every field that will be transmitted, in a mandatory preview dialog, and must explicitly confirm before the report leaves the device.
• Cancellable at any point before the user clicks Send, with no residual transmission.
• Limited to a fixed allow-list of technical fields (report identification and classification, runtime environment, an optional execution-trace digest, a failure-recurrence count, and a short abstract summary generated by the local on-device AI — the complete list is in Section 6.6(a)).

The Company will not introduce any form of passive or automatic data collection in the Software without first updating these Terms and obtaining the user's renewed consent.

6.4 Data Retention and Deletion

All local user data may be deleted at any time via Settings > Data > Delete All Data. Delete All Data replaces the database and deletes every store named in Section 6.1 that holds the user's data -- the encrypted recording and attachment files, the unencrypted files listed there (the logs and the local backups in the Software's own backups folder included), the training workspace and the prefix snapshots -- with the exceptions listed below. Smart Reset does the same while restoring the groups of data the user chooses to keep; unlike Delete All Data, it keeps the local backups, it keeps the logs and the profile picture when the user keeps the group each belongs to, and it always keeps the local audit trail (the record of the agent's actions, of every autonomy decision and of every autonomy level and protection switch the user set), which only Delete All Data erases. The group and per-product resets on the same Settings page clear database rows only; they do not delete the files that belong to those rows (attachments, recordings, documents and generated media), which Delete All Data and Smart Reset remove -- with one exception: a reset that covers the media library also deletes that library's own files, the pictures a product imported and the retained copies of the inputs behind generated media, which exist only for the rows the reset removes. Smart Reset offers the media library as a preservation group, unticked by default: kept, its rows and its files both survive; left unticked, both are removed with the rest. No reset deletes: the password-protected export files (Section 6.7), which exist to survive a reset; the database key file, under which the new database is encrypted; the encrypted archive of acceptance receipts that every reset appends to before it wipes the database (the live acceptance record itself is part of the database, so after Delete All Data the acceptance screen is shown again); the licence, the random installation identifier and the application's own settings and state files (Section 6.1); downloaded model files, adapters the user placed in the models folder, and the model backups the Software makes (of which it keeps the newest three); the support-desk store in which an operator of the Software keeps reports other people sent to it (Section 6.6(d)); and files the user saved to a location of their own choosing.

The Company does not hold a copy of this data, with the exception of the records described in Sections 6.3(a) (the licence account and the activated installations), 6.6 (bug reports the user has explicitly submitted, retained under the policy defined there and deletable by the user at any time via the User Hub > Support tab) and 6.9 (the anonymous aggregate index).

6.5 Age Restriction

The Software is not intended for persons under 18 (eighteen) years of age, is not directed at children, and the Company does not knowingly process their data. By accepting these Terms, the user declares that they are 18 years of age or older and have full legal capacity to enter into a binding contract in their country of residence, and the Company relies on that declaration. The user agrees not to allow anyone under 18 to use the Software on their devices or under their licence, and is responsible for any use of the Software by a person they allow to use their device or licence. If the Company learns that a user is under 18 it may withdraw the user's right to use the Software (Section 10.3); a parent or guardian who believes a minor has used the Software may contact legal@runmyai.app.

6.6 Bug Reports

The bug report described in this Section is user-initiated and per-report: nothing is transmitted unless the user opens "Report a bug", reviews the exact payload, and sends it. The Software never sends a report automatically, in the background, or at any autonomy level.

When the user explicitly chooses to submit a bug report via the in-app "Report a bug" function, a limited amount of structured diagnostic data is transmitted to RunMyAI servers for the sole purpose of investigating and fixing the reported issue. This is one of only two kinds of data that reach RunMyAI — the other being the automatic, anonymous ModelIndex contribution (Section 6.9). The bug report itself is always initiated by the user, never automatically and never in the background.

(a) What is transmitted The payload is built from a fixed allow-list of technical fields: a report identifier and creation timestamp; the report's category, severity, and product area as selected in the report form; the runtime environment (app version, build identifier, operating system and architecture, and the app's interface language); the subscription plan tier; at the user's option, a technical digest of the failed execution — an internal request identifier, the outcome status, the execution strategy, an error summary, the total duration, the name of the local model involved, the quality-gate rejection count, the planning fallback reason, and, for the failing step, its lane, action, error message, and quality-gate reason — and, when the local adaptation of planning guidance (Section 2.3) shaped that execution, a digest of the adjustments in force for it: for each of the two adjustable components (the planner and the tool router), the adjustment version number, which of three fixed evaluation groups the turn ran in (base, probation or incumbent), the request class as two fixed category names (a complexity level and an execution lane, or unclassified), the list of typed adjustments (each as its kind and the request class, lane and tool names it refers to, all drawn from the Software's fixed catalog), a hash of that component's built-in instructions, and a fingerprint of the local model that ran it derived from the model file's name and size (not from the folder it is stored in); whether the same request was re-run with every adjustment turned off; whether the Software could read its record of adjustments when it built the report (if it could not, the adjustments, the hashes and the fingerprint are absent for that reason rather than because none was in force); and a whole number identifying the version of the adaptation rules — together with a count of how many recent local failures share the same technical failure signature (a number only, never any content); an abstract summary generated locally by the Software's on-device AI describing the nature of the problem; and the list of category names of anything the outbound redaction removed from the draft (names of categories only, never the removed content). Optionally, if the user explicitly opts in, the payload may also include a free-text description written by the user. Every text field of the payload passes the outbound credential redaction before the preview is shown, and every field that can carry free text — the on-device AI abstract summary, the user's own description, and the execution digest's error and reason text — additionally passes a personal-identifier redaction that removes email addresses, home directory paths, network addresses, phone numbers, long numeric identifiers such as payment card numbers, and grouped identification numbers such as tax or citizen numbers, for every country alike. That redaction has two layers, merged by union, so what either layer finds is removed: a fixed table of patterns, which runs on every report and is the floor, and an optional on-device identifier model, which finds identifiers that have no fixed shape, such as a person's name, a postal address, a personal date, a private link, an account number or a secret typed into a sentence. The model is downloaded only when the user installs it from the Support tab, runs on the user's machine, and sends nothing anywhere to do its work; it can only add to what the pattern table removes, never withdraw a removal. If the model is not installed, or cannot run, the pattern table screens alone, and the preview the user reviews before sending states which screen ran. The report's generated identifiers and its fixed-vocabulary fields (the report and request identifiers, the status, the execution lane and action, the runtime environment, and the adjustment digest, which holds only catalog names, whole numbers and hashes) take the credential redaction only: they are the correlation keys the support desk answers the report with, and a generated identifier or a closed vocabulary cannot carry a personal identifier in the first place. Before any transmission, the Software displays the complete payload to the user in a preview dialog; no data is sent until the user clicks Send.

(b) What is never transmitted Bug reports do not include and will never include: message contents (iMessage, Telegram, email, or any other communication), file contents from the user's filesystem, LLM prompts or completions from the user's normal use of the Software, credentials, API keys, tokens, keystrokes, session recordings, screenshots or any binary attachment, or any form of browsing or location history.

(c) Identity and authenticity A bug report is transmitted as a cryptographically signed message sent from the user's own email account to RunMyAI's support address, over the user's existing mail provider (the transport described in Section 6.2(c)). Because the report travels over the user's own email, the sending email address is visible to the Company, as it is for any email the user sends; a bug report is therefore not anonymous. The report is signed by a self-generated key pair (the local "Agent Passport") that the Company does not issue and cannot forge, which authenticates the sender without any central identity server. A report may include the user's subscription plan tier, for prioritization, but never the user's name, phone number, payment details, or any identifier beyond the sending email address and the allow-listed technical fields in (a).

(d) Storage A submitted report is received and held only within RunMyAI's own instance of the Software, operated by the Company on its own systems, in that instance's dedicated local support-desk store. No third-party managed database, object store, or third-party support-desk service holds the report; no separate cloud database or third-party processor has access to it. Reports are text-only; the Software does not transmit screenshots or binary attachments.

(e) Retention A submitted report is retained only as long as needed to investigate and resolve the reported issue and to prevent its recurrence. The user may request erasure of any report at any time (see (f)); on such a request the Company removes the corresponding record from its instance. The Company will not retain reports for any purpose, or for any period, beyond what this Section permits without updating these Terms and obtaining the user's renewed consent.

(f) User rights At any time, the user may:

• View every bug report ever submitted from their device, along with the exact content of each report, via the User Hub > Support tab;
• Delete any individual report via the same interface, which removes the local record immediately and signs and sends an erasure request to the Company's instance so that the corresponding record is removed there as well; the Software keeps that request and repeats it until the Company's instance acknowledges the deletion. The copy of the report in the Sent folder of the user's own mail account is not touched by this request.

(g) No secondary use Bug reports are used exclusively for diagnosing and fixing defects in the Software. They are not used for analytics, product research, marketing, machine learning training, profiling, advertising, or any purpose other than resolving the reported issue. They are not shared with or sold to any third party.

(h) Legal basis The processing of this data is based on the user's explicit, per-report consent given at the moment of submission. Withholding consent (by not clicking Send, or by cancelling the dialog) has no consequence for the user's ability to use the rest of the Software.

(i) Technical architecture reference The full technical specification of the bug report program — including the local data pipeline, allow-list composition, the role of the on-device AI in producing the abstract summary, the signed agent-to-agent transport over the user's own email, and the failure modes of the automatic layers — is maintained in the Company's technical architecture documentation.

6.7 Password-Protected Export and Import

The Software offers a password-protected Export and Import flow as the only sanctioned mechanism for moving data between installs, or for keeping a backup that survives loss of the key file (see Section 5.7).

(a) Export The user initiates the export and chooses a password. The Software writes a single file (default extension .runmyai-export) containing the entire local database re-keyed under a fresh PBKDF2-HMAC-SHA512 derivation (256,000 iterations) of that password, together with the adapter and fused-model weights trained from the user's data and, if the user selects them, model weight files. The file is independent of the originating install's key file and may be imported on any other install of the Software.

(b) Import Import is replace-only, not merge: importing replaces the current live database, except that the autonomy settings of the installation doing the import are kept. An acceptance record carried in the imported database counts as acceptance on the importing install only if it is for the current version of these Terms. Before replacement, the Software rotates the current file to a one-time safety copy retained for 24 (twenty-four) hours, after which it is deleted automatically at the next start of the Software.

(c) Password constraints The export password must be between 12 (twelve) and 256 (two hundred and fifty-six) characters. Single quotes and control characters (including tab and line breaks) are not permitted. A wrong password at import time produces an explicit "wrong password" outcome, distinct from a "file corrupted" outcome.

(d) User responsibility The user is solely responsible for (i) choosing a strong password, (ii) storing the password securely outside the Software, and (iii) storing the exported file securely. The Company does not store, retain, or escrow the password or the file, and cannot recover either if lost. The export file contains the same data protected under Section 6.1; the user should treat it with the same care.

(e) No transmission Export and Import are local operations only. The exported file does not pass through the Company's servers at any point.

(f) Readable JSON export Separately, the user can export the contents of the database as an unencrypted JSON file, a data-portability copy readable by any other program. That file is not encrypted, is written where the user chooses, and omits credential columns. The user is responsible for storing it as described in (d).

6.8 No Monitoring and No Duty to Monitor

The Software runs entirely on the user's machine. The Software has no in-app user profile and no login to use it. The Company's licence service holds a customer account for the purchase, the licence token and the random installation identifiers of the devices activated on it (Section 6.3(a)(2)); it holds no record of the user's activity or content (the only data that ever reaches the Company is an automatic anonymous ModelIndex performance report (Section 6.9), which carries no identity or content, a bug report the user chooses to send (Section 6.6), and the content-free service connections described in Section 6.3(a)). As a direct consequence of this privacy-first, local-only architecture:

• The Company has no ability to observe, inspect, monitor, log, or audit what the user does with the Software, what the agent is instructed to do, or what data the agent processes or transmits.
• The Company has no technical means to detect a prohibited use (Section 8.2) before, during, or after it occurs. The only remote control the Company has over an individual installation is the licence service: when it refuses a renewal, because a subscription has lapsed, a device was removed from the account, the device limit was reached, or the Company has withdrawn the user's right to use the Software (Section 10.3), the installation locks at its next renewal after the offline grace period, keeping the user's content readable, exportable and deletable. That control is exercised on licence status, never on observed use.
• The Company therefore assumes no duty to monitor, screen, review, or police any user's use of the Software, and the absence of monitoring is a deliberate privacy feature, not a deficiency.

This allocation of responsibility — full local control and privacy for the user, full responsibility for use resting with the user — is fundamental to these Terms.

6.9 ModelIndex Contribution (Anonymous Performance Data)

The ModelIndex is a community feature: your installation contributes anonymous performance measurements, and that shared data is what powers the hardware-matched model recommendations you receive in return. The contribution is designed to be anonymous — it carries no per-device identifier, so that no report can be linked to another or to a person — and it is made automatically, the same way for everyone, with no regional distinction.

There are now millions of local AI models and quantizations, and the question every user faces — "which one actually runs well on my hardware?" — cannot be answered by synthetic, data-center benchmarks. The RunMyAI ModelIndex answers it: an aggregate, community index measured on real consumer hardware, which exists only because every installation contributes. Participation is part of how the Software works rather than a per-use export — the Software sends an anonymous performance report, and in return every user benefits from the resulting recommendations. By accepting these Terms and using the Software, the user agrees to this automatic, anonymous contribution. A user who does not agree should not install, purchase, or use the Software (Section 1). The report is transmitted to the Company, but it carries no identity, no content, and nothing that reveals what the user did (subsections (a)–(c)).

(a) What is transmitted A fixed allow-list of non-identifying technical measurements. For each measured model: the model name and quantization (the model name is the name the model carries on the user's computer: for a model downloaded from the catalog, the catalog name; for a model the user imported or trained, the name the user gave it or its file name, never its folder path, so the user should not give a model a name that identifies a person), tokens-per-second in two forms — the sustained rate the model holds across a whole answer, and the highest rate it reached for a moment — time-to-first-token, the nucleus quality-gate pass rate, the number of plans the model participated in, how many of those plans finished, the share of the finished ones that delivered a result, and — when the user has rated that model — the average of the user's own 1-5 star ratings (a number only, never any content). The counts about finished plans, for models and for pairs alike, are aggregate numbers about the Software's own runs on the user's machine, of the same nature as the plan count already listed: they say how often a model completed its work, never what the work was. For each measured model pair: the two model names with their combined quality-gate pass rate, the share of their finished runs that delivered a result, replan rate, average plan duration, and plan count. For each adjustment of the local adaptation of planning guidance (Section 2.3) that reached a final live outcome since the previous report: which of the two adjustable components it applied to (the planner or the tool router); the typed adjustment itself, as its kind and the request class, lane and tool names it refers to, all drawn from the Software's fixed catalog; the name and quantization of the local model it ran on; a whole number identifying the version of the adaptation rules; its outcome as one of three fixed words (promoted, live regression, or inconclusive); and the number of evaluation units it was measured over. These are catalog values and counts about the Software's own runs, of the same nature as the plan counts listed above: they say how an adjustment fared, never what any request was, and they carry no text, no trace identifier and no identifier of the installation. The service's answer to that same report may carry back, for the models the report named, the community's aggregate for each adjustment — the adjustment, the model name and quantization, the version of the adaptation rules the outcomes were produced under, how many installations promoted it, how many retired it, and how many installations contributed — which the Software stores on the device and, only for an aggregate produced under its own version of those rules, uses for two things only: to lower the amount of local evidence a proposal of that adjustment needs before the user is asked, and to show those counts on the approval card. It cannot propose, approve or apply anything by itself, and it travels in the response to a transmission the Software already makes; no new connection is opened. The hardware specification of the machine the measurements were taken on, reported both as plaintext class fields and as a non-reversible hash derived from those same fields: the processor's model name as its manufacturer publishes it (for example "Apple M4 Max" or "Intel Core Ultra 7 155H"), its vendor, and its published core count; the RAM tier with its nominal gigabyte value; the accelerator's model name as its manufacturer publishes it (for example "NVIDIA GeForce RTX 4090"), its published core count where the platform reports one, and the inference runtime type; the video-memory tier; the operating-system family (for example "macOS"); and a short accelerator label composed on the device from those same accelerator values, so that the public index words them one way (for example "40-core GPU", "NVIDIA GeForce RTX 4090", or "CPU"). That label is derived from values already listed here and adds nothing that is not. These are published product specifications of manufactured parts, each shared by a very large number of machines: a core count is printed on the spec sheet of the part, identical on every unit of it, and is what separates two parts sold under one name (an "Apple M4 Max" ships as a 32-core and a 40-core graphics part, and reporting only the name says nothing about which one ran). The report never carries a value particular to the user's own machine: not the measured RAM amount, not the measured video-memory amount, not the operating-system version, and no serial number, network address, or other device identifier. The subscription plan tier. And report bookkeeping: the app version, the report's creation timestamp, and the payload schema version. A contribution may carry a single-use anonymous token (anon_token). The token is issued to your licence in an earlier contribution cycle through a blind signature (RFC 9474): the site that issues it cannot recognise it when it is spent, so it proves only that the report comes from a licensed installation, never which one. The site stores a one-way hash of each spent token to refuse reuse, and a keyed hash of the account identifier in your licence with a counter to limit how many tokens are issued. The report contains no per-installation key and no other per-device identifier.

(b) What is never transmitted A ModelIndex report does not include and will never include: the user's name, email, phone, payment details, or IP address; conversation, message, or email content; prompts or model outputs; file contents or file paths; credentials, API keys, or access tokens (the only token a report may carry is the anonymous token described in (a)). Nor does it include any measured value particular to the user's machine, as opposed to the published specification of the parts it is built from: the measured RAM amount, the measured video-memory amount, the operating-system version, a serial number, a network address, or any other device identifier. It carries the allow-listed elements in (a) and nothing else.

(c) Anonymous, and on third-party infrastructure A report carries no identifier of the user: no name, email, account, license id, or IP address, and no content. Because the report contains no per-installation key and no other per-device identifier (subsection (a)), no contribution can be tied back to a device or to an individual person; reports are merged into an aggregate index across all installations. Nor can two reports be attributed to the same machine. The only value two reports from one machine have in common is the hardware specification described in subsection (a) and the hash derived from it — and every machine built from the same published parts produces that same specification and that same hash, so two matching reports are indistinguishable from two different machines of the same model. What the specification identifies is a product; the number of machines answering to it is not something a report reveals, and the Company has no means of narrowing it. The same holds for the adjustment outcomes described in subsection (a): an adjustment is a combination of catalog values that every installation running that model can emit alike, and its outcome and unit count move with every further evaluation, so neither can act as a stable identifier or tie two reports together. Reports are sent to a cloud aggregation service operated by the Company on third-party infrastructure (for example, managed hosting and database providers), where the anonymous report is processed to compute the public index. The user's IP address is visible to the receiving service at the network level, as with any internet request, and is not stored as part of the report.

(d) Purpose and no secondary use Contributed data is used solely to compute and publish the aggregate ModelIndex (rankings by model, hardware tier, quantization, and model pair) and to power in-product recommendations. It is not sold, not used for advertising or profiling, and not used to train machine-learning models, and it is never tied back to an individual user.

(e) Legal basis The report is designed to be anonymous: it carries no per-device identifier, so a single contribution cannot be singled out and the data is not personal data under the GDPR, UK GDPR, or LGPD. The hardware specification in subsection (a) does not change that. It names manufactured products, not the user's machine — each of those product names is shared by a very large number of machines worldwide, and the report deliberately carries no measured value that would narrow the set to one. On that basis the contribution is automatic for everyone, with no regional distinction. To the extent any applicable law nonetheless treats a transmitted element as personal data, the Company relies on its legitimate interest (GDPR Article 6(1)(f) and equivalents) in maintaining the community ModelIndex, together with the user's acceptance of these Terms; the user's interests are protected because the data is anonymous, aggregated, allow-listed, and never used for advertising, profiling, or model training (subsection (d)). Where applicable law grants rights over any transmitted element, the Company will honor them.

(f) Changes The Company will not expand what a ModelIndex report contains beyond the allow-list in (a) without updating these Terms.

(g) Reading the community ranking back To show the user how models rank on hardware like theirs, the Software also reads the published ranking back from the Company's aggregation service. The request is the same for every installation: it carries no path parameter, query, body, cookie, licence or header of its own, so it sends no hardware class and no hash, no model list, no measurement, no identity, and no content. The answer is the public ranking of every hardware class the index publishes (model names, quantizations, community scores and ranks, and the model file names the index grouped under each model). The Software selects the ranking of its own hardware class on the device, stores only that ranking, and matches it against the user's own models locally, so neither the machine's hardware class nor which models the user has is sent. The Software makes this request when its stored ranking is missing, is older than 24 hours or belongs to a different hardware class, and when the user asks for a refresh. As with a report, the user's IP address is visible to the receiving service at the network level and is not stored with the request.

---

7. Limitation of Liability

7.1 Disclaimer of Warranties

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, THE SOFTWARE IS PROVIDED "AS IS" WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, CONTINUOUS AVAILABILITY, OR FREEDOM FROM ERRORS.

7.2 Disclaimer of Liability

SUBJECT TO SECTIONS 7.3 AND 7.4, AND TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, RUNMYAI SHALL NOT BE LIABLE FOR:

• Indirect, incidental, special, punitive, or consequential damages
• Loss of data, profits, revenue, goodwill, or business opportunity
• Business or activity interruption
• Actions executed by the agent that cause harm to third parties, including an action the agent took on a misread instruction, page or message
• Violations of third-party platform Terms of Service resulting from agent use, and the restriction, suspension or termination of the user's account, number or device by a platform the user connected the Software to (Section 8.1)
• Access to the user's models, data or computer obtained through a feature the user exposed to a network (Section 5.10), or through a device, client or person the user paired, allowed or failed to unpair
• Use of the Software by a person under 18, or by any person the user allowed to use their device or licence (Section 6.5)
• Decisions, filings or transactions made in reliance on the finance features, and documents signed by or through the Software (Section 5.13)
• Media generated from a person's image, likeness or voice without the right to use it (Section 5.11)
• Exposure of the user's IP address or digital identity resulting from the agent conducting searches and browsing from the user's machine
• Decisions made by the user based on agent outputs without independent verification
• Damages caused by prompt injection or manipulation of the agent by third-party content
• Recording, capture, transcription, AI analysis, or import of conversations performed by the user without the participant consent or notice that applicable law requires, including where the user has turned off the on-device recording indicator (Section 5.9)

THESE LIMITATIONS APPLY EVEN IF RUNMYAI HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES AND REGARDLESS OF THE LEGAL THEORY APPLIED (CONTRACT, TORT, ETC.).

7.3 Liability Cap

Subject to Section 7.4, the Company's total and aggregate liability is limited to the greater of (a) the amount paid by the user for the Software in the 12 (twelve) months preceding the event giving rise to the claim, and (b) USD 100.00 (one hundred US dollars).

7.4 Legal Exceptions

Nothing in these Terms excludes or limits the Company's liability for death or personal injury caused by its negligence, for fraud or fraudulent misrepresentation, for intentional or grossly negligent acts, for defects for which product-liability law makes the Company liable to a natural person, for breach of mandatory data-protection or consumer-protection law, or for anything else that cannot be excluded or limited under the law that applies to the user. Some jurisdictions do not permit the exclusion or limitation of certain warranties or liabilities or of non-waivable consumer rights; in those jurisdictions, the exclusions and limitations in this Section 7 apply only to the extent permitted by law, and the rights of a consumer under the law of their country of habitual residence prevail.

7.5 Indemnification by the User

To the maximum extent permitted by applicable law, the user agrees to indemnify, defend, and hold harmless the Company and its founders, officers, directors, employees, contractors, and agents from and against any and all third-party claims, demands, actions, proceedings, liabilities, damages, losses, fines, costs, and expenses (including reasonable attorneys' fees) arising out of or related to: (a) the user's use of or access to the Software; (b) any action the agent executed that the user authorized, whether explicitly or through the user's autonomy configuration, including actions affecting third parties or external systems; (c) the user's violation of these Terms or of any applicable law or regulation; (d) the user's infringement or misappropriation of any third party's rights, including intellectual-property, privacy, publicity, or data-protection rights; (e) any content, data, or instruction the user provided to or processed through the Software; and (f) any recording, capture, transcription, AI analysis, or import of a conversation the user performed, including claims by recorded participants or by authorities arising from the user's failure to obtain any consent or give any notice required by applicable law (Section 5.9); (g) use of the Software by a person the user allowed to use their device or licence, including a minor (Section 6.5); (h) access obtained through a feature the user exposed to a network or through a device or client the user paired (Section 5.10); (i) media the user generated from a person's image, likeness or voice (Section 5.11); and (j) the user's breach of a third-party model licence or acceptable-use policy (Section 8.4) or of export-control or sanctions law (Section 8.5).

This indemnity does not apply to the extent a claim arises from the Company's own fraud, gross negligence, or willful misconduct, or to any liability that mandatory applicable law does not permit to be allocated to the user (including non-waivable consumer protections). The Company will give the user reasonable notice of any claim subject to this Section and may, at its option, participate in the defense with its own counsel.

7.6 Time Limitation on Claims

To the maximum extent permitted by applicable law, any claim or cause of action arising out of or related to the Software or these Terms must be commenced within one (1) year after the claim or cause of action first arose; otherwise it is permanently barred. Where applicable law does not permit this shortened period, the shortest limitation period that law does permit applies instead.

---

8. Compliance with Applicable Law

8.1 User Responsibility

The user is solely responsible for ensuring their use of the Software complies with all applicable laws in their jurisdiction, including but not limited to:

• Personal data protection laws (e.g., GDPR — European Union, LGPD — Brazil, CCPA/CPRA — California/US, PIPL — China)
• Computer access and cybercrime laws (e.g., CFAA — US, Budapest Convention, Lei 12.737/2012 — Brazil)
• Intellectual property and copyright law, including protections over web-scraped content
• Sector-specific regulations applicable to the user's activities (financial services, healthcare, legal, government, etc.)
• Terms of Service of third-party platforms and services with which the agent interacts

Messaging-channel platforms. The Software can connect to Telegram, iMessage, WhatsApp, and Signal so the user can drive their own agent. These connections run under the user's own accounts (a Telegram bot token the user creates, the user's Apple ID for iMessage, a linked-device session for WhatsApp, and so on). Several of these platforms restrict or prohibit automated access, unofficial clients, or bot-mediated use in their own terms. The user is solely responsible for confirming that connecting and using each channel is permitted by that platform's current terms, and assumes the risk of any account restriction or termination the platform may impose.

8.2 Prohibited Use

Use of the Software for the following purposes is expressly prohibited and constitutes grounds for immediate termination of access, without prejudice to applicable civil and criminal liability:

• Collecting, processing, or using third-party personal data without an adequate legal basis
• Recording, capturing, transcribing, or importing a conversation without the participant consent or notice that applicable law requires (see Section 5.9)
• Unauthorized access to third-party computer systems
• Scraping content in violation of Terms of Service or applicable law
• Generating illegal, defamatory, deceptive, or rights-infringing content
• Any activity that causes harm to third parties or constitutes a crime in any relevant jurisdiction
• Trading in, facilitating, or arranging illegal goods or services (including controlled substances, weapons, stolen data or credentials, or counterfeit goods)
• Fraud, scams, phishing, social engineering, or impersonation of any person or entity
• Generating or distributing child sexual abuse material, or any content that sexualizes minors
• Harassment, stalking, doxxing, threats, or coordinated intimidation of any person
• Sending unsolicited bulk or automated messages (spam) over any channel, or operating messaging, email, or platform accounts in a manner that violates the platform's terms
• Market manipulation, money laundering, or evasion of taxes, sanctions, or export controls
• Generating or amplifying disinformation, or operating undisclosed automated identities ("bots") where disclosure is required
• Giving, or presenting the agent's output as, professional medical, legal, tax or financial advice to another person, or using the Software for safety-critical control, emergency response or health decisions
• Any use that Article 5 of the EU AI Act prohibits (including social scoring and manipulative or exploitative techniques), and any decision about another person in the areas Annex III of the EU AI Act lists as high-risk (employment, credit, education, essential services, law enforcement, migration and the administration of justice) without the human oversight and obligations that law requires of the user as the deployer
• Defeating or solving CAPTCHAs, rate limits or other bot-detection or access controls of a website or service, or scraping or automating a site in breach of its terms
• Creating sexual content of a real person without that person's consent, media that deceives about a real person's words or actions, or any use of a person's image, likeness or voice the user has no right to (Section 5.11)
• Removing or altering the AI-generated marker the Software embeds in generated media and documents (Section 8.3)
• Pressing a third party about a debt in a manner, or at a frequency, that the law of the place where that person is located prohibits
• Using the Software's local, anonymous operation to conceal, organize, or carry out any of the foregoing, or to evade lawful process

The user acknowledges that, because the Software runs locally with no server-side visibility into the user's activity (Section 6.8), the Company has no technical means to detect or prevent a prohibited use in advance. This list defines the contractual boundary of permitted use; it is not, and cannot be, a monitored or enforced control. Responsibility for staying within it rests entirely with the user. Termination for a prohibited use is effected as described in Section 10.3.

8.3 EU AI Act

For users in the European Union: the Software qualifies as a general-purpose AI system, and the agent interacts directly with natural persons and produces AI-generated content. The transparency obligations under Article 50 of the EU AI Act apply from 2 August 2026.

The Software addresses the Article 50 transparency duty for the communications it controls by marking autonomous agent messages to third parties as AI-generated, as described in Section 4.5, and by embedding a machine-readable marker in the media and documents it generates. The Company commits to keeping these Terms and the Software's disclosure behavior updated in accordance with the EU AI Act implementation schedule. Where the user directs the agent to act through a surface the Software cannot mark, or publishes generated content where the law requires a visible disclosure, the disclosure obligation for that interaction rests with the user (Sections 4.5 and 5.11). Where the user deploys the Software for a use the EU AI Act regulates, the obligations that law places on the deployer rest with the user.

8.4 Third-Party Model Licences

The Software downloads and runs AI models published by third parties under their own licences and acceptable-use policies (for example, community licences that restrict certain uses or require a paid licence above a revenue threshold). The licence and any use policy of each model are shown in the model catalog and in the third-party notices the Software ships, and apply between the user and the model's publisher in addition to these Terms. The user agrees to comply with them, including every use restriction they contain, and not to use a model for a purpose its publisher prohibits; the user is responsible for checking whether a model's licence permits the user's intended use and whether it requires a licence of the user's own. The Company's licence to the user grants no right in any model beyond what its publisher grants, and the Company may remove or disable a model whose publisher withdraws or changes its licence. The Company does not warrant the accuracy, legality or fitness of a model's output (Sections 5.1 and 10.14(f)).

8.5 Export Control and Sanctions

The Software contains cryptography and is distributed from the European Union. The user may not use, download, export, re-export or transfer the Software in breach of the export-control or sanctions laws of the European Union, of Portugal, of the United States, or of any other jurisdiction that applies to the user. The user represents that they are not located in, ordinarily resident in, or organized under the laws of a country or territory subject to comprehensive sanctions or embargo, that they are not on any sanctions or restricted-party list, and that they will not use the Software for a prohibited end use, including the development of weapons, a military end use, or the surveillance of human-rights defenders. The Company may refuse, suspend or withdraw a licence, and may decline a sale, to comply with these laws. This Section survives termination.

---

9. Jurisdiction and Dispute Resolution

9.1 Informal Resolution First

Before commencing arbitration or court proceedings, a party must first try to resolve the dispute informally by sending written notice of the dispute to the other party (to the Company at legal@runmyai.app). The parties will negotiate in good faith for 30 (thirty) days from that notice. Only if the dispute is not resolved within that period may it proceed under Section 9.2. A consumer may also refer a dispute to a consumer dispute-resolution body: in Portugal, the consumer arbitration centres and other entities listed by the Directorate-General for Consumers (consumidor.gov.pt), in which the Company participates where the law requires it or the consumer elects it; in Brazil, the consumidor.gov.br platform. The European Online Dispute Resolution platform no longer operates.

9.2 Dispute Resolution and Binding Arbitration

Consumers. If the user is a consumer resident in a country whose law gives consumers a non-waivable right to bring claims before their local courts or before a consumer dispute-resolution body (including every member state of the European Union, the United Kingdom and Brazil), nothing in this Section 9 removes that right: the user may bring a claim before the courts of their country of habitual residence, the Company may bring a claim against such a user only in those courts, arbitration is available to such a user only at the user's own election after the dispute has arisen, and the mandatory consumer protections of that country apply.

All other users. Any dispute, controversy, or claim arising out of or relating to these Terms or the Software — including its existence, validity, breach, or termination — that is not resolved under Section 9.1 shall be finally settled by individual and binding arbitration under the Rules of Arbitration of the International Chamber of Commerce (ICC). The seat of arbitration is Geneva, Switzerland; the language is English; and the tribunal consists of a sole arbitrator unless the ICC determines otherwise. The award is final and binding, and judgment on it may be entered in any court of competent jurisdiction (the New York Convention applies). Nothing in this Section prevents either party from seeking interim or injunctive relief from a competent court where necessary to preserve rights pending arbitration.

9.3 Class Action Waiver

To the maximum extent permitted by applicable law, all disputes are conducted on an individual basis only, and the user waives any right to participate in a class, collective, consolidated, or representative action against the Company. This waiver applies to the fullest extent the law allows; where mandatory law (for example, in Brazil or in European Union member states) does not permit it, this Section does not deprive the user of any non-waivable right to collective redress that such law guarantees, and the remainder of this Section 9 continues to apply.

9.4 Governing Law

These Terms, and any dispute arising out of or relating to them or the Software, are governed by the substantive laws of Switzerland, without regard to its conflict-of-law principles and excluding the United Nations Convention on Contracts for the International Sale of Goods. Mandatory rights guaranteed to a consumer by the law of the consumer's country of habitual residence — including non-waivable consumer protections under the Brazilian Consumer Defense Code, EU Directive 2019/770, or equivalent legislation — are not affected by this clause and prevail to the extent applicable; this choice of law does not deprive a consumer of the protection afforded by provisions that cannot be derogated from by agreement under the law of their country of habitual residence.

---

10. Term, Termination, and General Provisions

10.1 Term

These Terms take effect upon acceptance by the user and remain in force until the user uninstalls the Software or the Company discontinues the product, whichever occurs first.

10.2 Termination by User

The user may terminate these Terms at any time by uninstalling the Software. No automatic refund is issued for interrupted use (see separate refund policy). Uninstalling does not by itself remove the user's data: to delete it, the user first runs Delete All Data (Section 6.4) and then removes the application data folder (Section 6.1) and any exports, backups and model files kept elsewhere. Except for the records described in Sections 6.3(a) and 6.6, the Company holds no copy of that data.

10.3 Termination by Company

The Software is operated locally, but its licence is renewed with a Company service (Section 6.3(a)(2)). In the event of a breach of these Terms, the Company may withdraw the user's right to use the Software, which it does by refusing the licence renewal for the account or device concerned, and may decline to provide updates, support, or future licenses; the installation then locks after the offline grace period, keeping the user's content readable, exportable and deletable, and the user is contractually obligated to cease use and uninstall. The Company cannot observe use (Section 6.8), so it acts on a breach it learns of from the user, from a third party, or from a court or authority. Nothing in this Section limits the remedies available to the Company or to affected third parties under applicable law for a breach or an unlawful use.

10.4 Updates to These Terms

The Company may update these Terms periodically, with the reason for each change stated in the public version history. A new version reaches an installation inside a Software update; the first time the Software is opened afterwards, it shows the acceptance screen with a summary of what changed since the version the user last accepted, and the Software cannot be used until the user accepts. A user who does not agree with an update may decline it, stop using the Software and uninstall it, and may terminate their subscription; where the update materially reduces what the user paid for, the user may request a refund of the unused part of any prepaid period, and the Refund Policy and mandatory consumer law apply. The Company publishes the version history of these Terms, with the effective date of each version, at runmyai.app/legal/terms.

10.5 Severability

If any provision of these Terms is held invalid, illegal, or unenforceable by a court, tribunal, or authority of competent jurisdiction, that provision is severed or limited to the minimum extent necessary, and the remaining provisions remain in full force and effect.

10.6 Survival

Any provision that by its nature should survive termination or expiry of these Terms survives, including (without limitation) the attribution rule in Section 3 and Sections 4, 5, 6, 7 (disclaimers, limitation of liability, indemnification, and time limitation), 8, 9, and this Section 10, including Section 10.14 (intellectual property).

10.7 Entire Agreement; No Reliance

These Terms, together with any separate refund policy and any policy expressly referenced herein, constitute the entire agreement between the user and the Company regarding the Software and supersede all prior or contemporaneous agreements, understandings, communications, marketing materials, and representations on that subject. The user acknowledges that they have not relied on any statement, promise, or representation not expressly set out in these Terms.

10.8 Force Majeure

The Company is not liable for any failure or delay in performance resulting from causes beyond its reasonable control, including acts of God, natural disasters, war, terrorism, civil unrest, epidemic, labor disputes, governmental action, sanctions, or network, power, or third-party-service failures or discontinuations on which the Software depends (Section 5.5).

10.9 No Waiver

The Company's failure or delay in enforcing any provision of these Terms is not a waiver of its right to enforce that or any other provision later. A waiver is effective only if made in writing by an authorized representative of the Company.

10.10 Assignment

The Company may assign or transfer these Terms, in whole or in part, including in connection with a merger, acquisition, financing, reorganization, or sale of assets, without the user's consent. The user may not assign or transfer these Terms or any rights or obligations under them without the Company's prior written consent; any attempted assignment in breach of this Section is void. These Terms bind and benefit the parties and their permitted successors and assigns.

10.11 No Agency or Partnership

Nothing in these Terms creates any agency, partnership, joint venture, franchise, employment, or fiduciary relationship between the user and the Company. The user has no authority to bind the Company in any way.

10.12 Capacity and Authority

By accepting these Terms, the user represents and warrants that they are at least 18 years old (Section 6.5) and have the legal capacity to enter into them and, where they accept on behalf of an organization, that they are duly authorized to bind that organization, which is then equally bound as the "user".

10.13 Controlling Language

These Terms are authored in English (the controlling master version) and may be made available in other languages for convenience. In case of any conflict or discrepancy, the English version prevails to the maximum extent permitted by applicable law; where mandatory local law requires the local-language version to govern for a consumer, that requirement prevails for that consumer.

10.14 Intellectual Property

(a) Ownership of the Software. The Software, including its source and object code, its design, its documentation and the content the Company ships with it, is owned by the Company and is protected by copyright and other intellectual property laws. The Software is licensed, not sold. All rights not expressly granted in these Terms are reserved by the Company.

(b) License to the user. Subject to these Terms and to a valid license where one is required, the Company grants the user a personal, non-exclusive, non-transferable, non-sublicensable and revocable license to install and use the Software on devices the user owns or controls, within the number of devices the user's license allows, for the user's own personal or internal business purposes. The user may not, except to the extent applicable law expressly permits it notwithstanding this restriction: copy the Software other than for installation and backup; sell, rent, lend, sublicense or redistribute it; modify it or create derivative works of it; decompile, disassemble or otherwise attempt to derive its source code; or remove or alter any copyright, trademark or attribution notice in it. Nothing in these Terms limits a right that cannot be excluded by contract, including the right to decompile the Software to the extent indispensable to obtain the information necessary for the interoperability of an independently created program, under the conditions applicable law sets.

(c) Third-party components. The Software includes third-party components distributed under their own licenses, some of them open-source licenses such as the GNU General Public License. Those components are listed, with their licenses, in the third-party notices the Software ships and shows in its About window. Each such component is governed by its own license, and nothing in these Terms restricts a right that license grants to the user, including any right to the component's source code.

(d) Trademarks. "RunMyAI", the RunMyAI logo and the names of the Software's products are trademarks of the Company. These Terms grant no right to use them, except to refer truthfully to the Software. Names of third-party products, services, models and companies that appear in the Software are the property of their respective owners and are used only to identify them; their appearance implies no affiliation or endorsement.

(e) The user's content. The user retains every right the user holds in the content the user provides to the Software, including prompts, files, documents, messages and other material ("Input"). The Company acquires no right in Input. The Software processes Input on the user's device as described in Section 6, and the Company does not receive it except where Section 6 states that the user chooses to send something to the Company.

(f) Output. As between the user and the Company, the user owns the text, images, audio, video, code and other content the Software generates for the user ("Output"), and the Company assigns to the user any right it may hold in Output. The Company claims no ownership of Output and does not use it. The user acknowledges that: (i) Output generated by a model may not be protected by copyright or other intellectual property rights, in particular where it lacks sufficient human creative contribution, and the Company does not warrant that any Output is protectable; (ii) Output may be similar or identical to content generated for other people, and the Company does not warrant that Output is original or unique; (iii) Output may reproduce or resemble material protected by third-party rights, and the Company does not warrant that Output is free of such rights; and (iv) the models the Software runs are distributed under their own licenses, and some of those licenses place conditions on the use of their output, which the user is responsible for observing (Section 8.4). The user is solely responsible for reviewing Output and for any use the user makes of it, under Sections 4.3 and 8.1.

(g) Feedback. If the user sends the Company suggestions or other feedback about the Software, the Company may use it without obligation to the user. Feedback never includes the user's Input or Output unless the user chooses to include them.

---

11. Acceptance and Consent Mechanism

11.1 In-App Acceptance Mechanism

At first use of the Software, and again whenever these Terms change (Section 10.4), acceptance is obtained in 3 sequential steps:

Step 1 — Risk Summary (plain language)

The Software shows a screen with the 6 critical risks in short bullet points:

1. Internet searches run from your machine, using your real IP address.
2. The agent can act autonomously at Levels 3 and 4. You configure the level per product and per surface; you assume full responsibility for what runs.
3. AI outputs may be wrong — always verify before acting.
4. Web pages, emails and documents can carry hidden text written to give the agent instructions of its own (prompt injection). The Software screens that content on your machine before the agent reads it and, unless you switch this protection off, asks for your approval before any action with an outside effect after reading it; no defense against this is complete.
5. Your local data is encrypted with a key held in a key file on your computer. If you lose that file (OS reinstall, account loss, format) without first creating a password-protected Export, the data is permanently unrecoverable.
6. RunMyAI contributes anonymous performance measurements (model and hardware only — never your content or identity) to the community ModelIndex (Section 6.9); this is automatic for everyone, and the report carries no per-device identifier.

Button: "I understand the risks"

Step 2 — Full Terms With Checkboxes

• The full text of these Terms, in English or Portuguese
• Checkbox 1: "I have read and fully understand the Terms of Use and Risk Acceptance"
• Checkbox 2 (separate and required): "I understand that web searches and browsing performed by the agent occur from my machine using my real IP address, and that such traffic is attributable to me in relation to third parties"
• Checkbox 3 (separate): "I confirm that I am 18 years of age or older"
• The Continue button is enabled only after the user has scrolled to the end of the document (or used the control that jumps to the end) and ticked all three boxes

Step 3 — Initial Autonomy Configuration

Before any agent execution, the Software presents the five autonomy levels (Section 4.1) with plain-language descriptions. The desktop starts at Level 0 (Manual), and every channel, remote and MCP surface starts at Level 0. The user may keep these defaults or choose a starting level for the desktop, and can set levels per product and per surface at any time in Settings. The Software marks Manual as the default and does not otherwise recommend a level.

The record of acceptance. The Software records, on the user's computer, the version and language of the Terms accepted, a cryptographic hash of the exact text shown, the three acknowledgments, the confirmation of the autonomy step, the time, the application version and operating system, and the random installation identifier (Section 6.3(a)(2)). The record is kept in the encrypted database, is archived in encrypted form before any reset, and cannot be altered or removed by the Software's own interface. The user can export it at any time as a receipt file from Settings > Data, signed with the install's own agent key where one exists; the Company holds no copy, so this receipt is the user's own proof of what they accepted.

11.2 Feature Availability at Higher Autonomy Levels

After acceptance, all features of the Software that the user's licence includes are available to the user. The Software does not gate specific features (for example, autonomous email sending, autonomous financial transactions, autonomous account creation on third-party services) behind additional acceptance steps.

Three point-of-use acknowledgments are the exception, because each opens a specific scope of third-party data: the iMessage third-party-data acknowledgment (Section 5.6), the recording acknowledgment (Section 5.9) and the reminders-bridge notice (Section 6.2(k)). Each is shown once, at the moment the user first engages that scope, records the user's acknowledgment of the responsibility described in the corresponding Section, and is archived with the record of acceptance (Section 11.1).

When the user raises a product, surface or action to Level 3 or Level 4 for the first time, the Software shows a one-time plain-language summary of what that level will now execute autonomously (for example: "At Level 4 in MyMail, emails will be sent without asking") and applies the change when the user confirms it. This confirmation is not a second acceptance of these Terms. The user's general acceptance under Section 11.1, combined with the conscious per-product per-surface autonomy configuration, covers all feature use.