> ## Documentation Index
> Fetch the complete documentation index at: https://docs.relayapp.im/llms.txt
> Use this file to discover all available pages before exploring further.

# Trust, privacy, and control

> What Relay stores, what an independent agent operator receives, and what the user controls.

An agent in Relay is independently operated AI: software with a named operator,
usually someone other than Relay. The product makes that boundary
understandable before the user sends private context or grants a consequential
capability.

<Warning>
  Relay encrypts traffic in transit today; end-to-end encryption is planned and
  unshipped. Consumer blocking, reporting, account deletion, and related safety
  paths exist locally but still require deployment and production proof.
  [See the current status](/current-status).
</Warning>

## The data path

```text theme={null}
User's Relay app
        ↕
Relay conversation and delivery service
        ↕
Independent agent operator's backend
```

Relay stores the canonical conversation needed to order, deliver, synchronize,
recover, and render messages. When the user messages an agent, Relay sends the
authorized conversation content to that agent's external backend so it can
respond. The user authorizes each transmission by choosing that conversation and
tapping Send for the specific message or attachment.

Relay's built-in agent uses Google Gemini through Cloudflare AI Gateway for
reply generation. Google may receive the current message, up to 30 recent
messages from that Relay conversation, and images the user attaches.
Cloudflare Workers AI processes voice audio and transcripts for transcription
and speech, and image prompts for generation. These built-in AI requests do not
include the user's phone number, address book, profile photo, device identifier,
or messages from other conversations.

The current developer contract scopes an Agent Token to one agent: its own
conversations, through the public API. Relay user accounts, email addresses,
address books, other agents, unrelated conversations, and Relay's database all
stay outside that scope.

## What the operator can receive

For an active conversation, the agent backend may receive:

* message content and ordered parts;
* sender, agent, message, and conversation identifiers;
* reply targets and reactions;
* delivery and read state;
* attachments the user includes;
* timestamps and sequence information required to maintain the thread.

The operator may copy that information into its own logs, memory, tools, or
model pipeline according to its disclosed policy. Relay review cannot guarantee
that an agent is accurate, safe, private, or appropriate for every use.

## Relay deletion and external memory are separate

Deleting Relay's copy erases Relay's copy. An independent copy already stored
by the agent developer persists under that operator's own policy until the
public contract and backend propagate the deletion. Users need to know:

* what the operator retains and for how long;
* whether messages or derived data can be used for training;
* how to request deletion from the operator;
* what happens to history or memory if the agent shuts down;
* whether the conversation can be exported before access ends.

Until Relay ships and proves a developer-facing deletion event, every agent
operator should provide a direct deletion path for data it retains outside
Relay.

## Adding an agent grants messaging, and only messaging

An installation creates a messaging relationship. Every further capability
requires its own explicit, understandable, and revocable grant as it ships:

* retaining messages in external memory;
* sending proactive messages or expanded notifications;
* receiving location, media, voice, or call access;
* initiating or requesting payments;
* joining groups or sharing context with another agent;
* invoking consequential tools.

The inbox stays relational: an agent reaches a user only after that user adds
it, and a store listing stays a listing until then.

## Removal, blocking, and reporting

Removing or blocking an agent ends the active installation. The current server
contract rejects new backend messages after that relationship ends, even if the
operator still has an old conversation ID.

Blocking, reporting, account deletion, support, and operator identity are release
requirements, not secondary settings. They must be production-proved before
Relay asks people to trust a public agent network.

<Columns cols={2}>
  <Card title="How Relay works" icon="route" href="/how-relay-works">
    Follow the intended user relationship and ownership boundary.
  </Card>

  <Card title="Developer data access" icon="brackets-curly" href="/reference/data-and-permissions">
    Read the exact preview API scope, retention, attachment, and authorization behavior.
  </Card>
</Columns>

## See also

* [Developer data access and retention](/reference/data-and-permissions)
* [How Relay works](/how-relay-works)
* [Current status](/current-status)