Terms of Service

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

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.

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)
• Reading and composing emails
• Access to and management of local financial data
• 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), 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.
• 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.
• 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 and 6.1).

---

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.

(d) Browser cookies and sessions

Each browsing window the agent uses has its own isolated storage, and that storage is erased when the window is released after a page is fetched. Nothing is carried over between runs of the Software.

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 is you, from the internet's perspective. Every request made by the agent appears to the outside world as a request made by you, from your IP address, from your device.
• 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. Many websites and services prohibit automated access, content scraping, bots, or software agents. Violations of those terms 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. 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

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, any action with an effect outside the Software 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). Attribution of such actions is to the user, not to the Software or to RunMyAI.
• 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.

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 every other tool result — 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. Every tool result carries a structured verdict — clean, sanitized, or rejected — stating what the filter did to it. 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 that stops the action. Before an outbound tool call or message leaves the device it is screened for signs that it would carry the user's data out. A signal aborts the action; the Software does not remove the signal and send the remainder.
• Web access cannot reach 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. The same check covers every page the Software's built-in browser loads in the background.
• 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 cannot become a request to a third-party server.
• Nothing the agent reads can 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. It does not mean content leaves the machine by a path the user has not opened: 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 each browsing window is erased after use (Section 3.1(d)). Two residual limits are stated here rather than left implicit. The erasure is issued as soon as a window is released, but is not guaranteed to have completed before that same window is used for the next page. And on Windows the agent's browsing windows share one storage area with each other during a single run of the Software, so a site the agent visits may be able to observe storage set by another site the agent visited in the same run. Neither path 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 Software is granted Full Disk Access by the operating system and 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, and the 256-bit master key is held in a key file stored in the application's local data directory, protected by operating-system file permissions. 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 file — 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. There is no backdoor and the Company 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 physical proximity. A messaging channel only accepts commands from the single device the user paired through a short-lived code generated on the desktop; messages from any other identity are dropped.
• 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, so a compromised channel cannot move money.
• Outbound redaction. Credential-shaped values are stripped from every message the agent sends out over a channel before it leaves the device.
• 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), every message is cryptographically signed and verified, and an unsolicited first contact is held for explicit human approval before the agent will respond.

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.

---

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: MyAI training pairs are not kept as files of their own but are derived from the database for each training run, and the state of that training (what has already been extracted, the fixed evaluation set and the retention baseline) is kept in the database too.

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.

Three 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), 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); 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.
• 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.
• The database key file described above, and the prefix snapshots described next.

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). It is stored unencrypted because it holds no user content, but each snapshot is authenticated with a key derived from the database key, and 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).

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

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

(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). 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 never reachable from the network 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 requires approval on the user's desktop for every scope; 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 links, which carry the amount, currency, and reference the user supplies for that charge. 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.

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 nothing that identifies the user. 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 Company-operated infrastructure. 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:

1. Update check and download. The Software periodically (at launch and approximately every six hours) asks the Company's update endpoint whether a newer version exists. The request carries the operating system, CPU architecture, the installed app version, and 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 downloads it 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. Those requests carry the confirmation code, a secret generated for and held only by this installation (it never leaves it and is discarded once the pairing settles), and the two values described next. 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 request carries no payload.
5. Model catalog and downloads. Downloading a model or runtime component fetches files from the Company's model repository or from the source model hub; the request identifies the file being fetched, not the user.
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, and it keeps the logs and the profile picture when the user keeps the group each belongs to. 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 record of the user's acceptance of these Terms; the licence and the application's own preferences; downloaded model files 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 sole exception of bug reports the user has explicitly submitted under Section 6.6, which are retained under the policy defined in that Section and may be deleted by the user at any time via the User Hub > Support tab.

6.5 Age Restriction

The Software is not intended for persons under 18 (eighteen) years of age. By accepting these Terms, the user declares they are 18 years of age or older.

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); 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. 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 and signs and transmits an erasure request to the Company's instance so that the corresponding record is removed there as well.

(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. That specification is subject to the same independent legal review as this Section before any commercial launch.

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. 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. 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 ASCII control characters 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.

6.8 No Monitoring and No Duty to Monitor

The Software runs entirely on the user's machine. There is no user account, no login, and no server-side record of the user's activity (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, and no remote "kill switch" over an individual install.
• 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 anonymous — it carries no per-device identifier, so 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, 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

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, RUNMYAI SHALL NOT BE LIABLE FOR:

• Direct, 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
• Violations of third-party platform Terms of Service resulting from agent use
• 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

The Company's total and aggregate liability, under any circumstances, 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

Some jurisdictions do not permit the exclusion or limitation of certain warranties or liabilities, including liability for fraud or gross negligence, or non-waivable consumer rights. In those jurisdictions, the exclusions and limitations above apply to the maximum extent permitted by law. Nothing in these Terms excludes or limits rights that cannot be excluded by mandatory applicable law.

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

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

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 take full effect on 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. 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, the disclosure obligation for that interaction rests with the user (Section 4.5).

---

9. Jurisdiction and Dispute Resolution

9.1 Informal Resolution First

Before commencing arbitration, 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 to arbitration.

9.2 Binding International Arbitration

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). Uninstallation removes all local data; the Company holds no copy of that data.

10.3 Termination by Company

Because the Software is locally operated with no user account and no server-side service the Company can revoke (Section 6.8), the Company has no remote means to disable an individual installation. In the event of a breach of these Terms, the Company may withdraw the user's right to use the Software and may decline to provide updates, support, or future licenses; the user is then contractually obligated to cease use and uninstall. 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. Material updates will be communicated to users through:

• An in-app notification upon opening the Software
• Email to the registered address (where applicable)

Material updates require a new explicit user acceptance before the Software may be used. Users who do not agree with updates must uninstall the Software.

Best practice note: The Company will maintain a public version history of these Terms, with the effective date of each version, accessible 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 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. 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 (Product Team Specification)

Acceptance must be obtained in 3 sequential steps at first use of the Software:

Step 1 — Risk Summary (plain language)

Display 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 — view full Terms"

Step 2 — Full Terms With Checkboxes

• Mandatory scroll to end of document
• 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"
• Button enabled only after full scroll and all checkboxes checked

Step 3 — Initial Autonomy Configuration

Before any agent execution, the Software presents the five autonomy levels (Section 4.1) with plain-language descriptions and confirms that every product and every surface is set to Level 0 (Manual) by default. The Software does not recommend a specific level to new users. The user may keep the defaults or raise individual products/surfaces consciously.

11.2 Feature Availability at Higher Autonomy Levels

All features of the Software are available to the user immediately after the general acceptance (Section 11.1) is obtained. 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.

Two point-of-use acknowledgments are the exception, because each opens a specific scope of third-party personal data: the iMessage third-party-data acknowledgment (Section 5.6) and the recording acknowledgment (Section 5.9). Each is shown once, at the moment the user first engages that scope, and records the user's acknowledgment of the responsibility described in the corresponding Section.

When the user raises the autonomy level of a product or surface to Level 3 or Level 4 for the first time, the Software may display 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"). This disclosure is informational only; it does not require a second acceptance and does not gate the configuration change. The user's general acceptance under Section 11.1, combined with the conscious per-product per-surface autonomy configuration, covers all feature use.