You are adding RelayLink to a product used by many people, and the worrying question is simple: when two users ask their assistants to check mail, what keeps one from seeing the other's inbox? This matters to SaaS architects, security reviewers, and teams deciding whether a shared integration credential is acceptable.
The short answer is identity first, ownership second. RelayLink determines which account made the request, then its services query records belonging to or involving that account.
Authentication resolves one account
An assistant connects with either an OAuth access token or a named API key. Both credential paths resolve to one RelayLink account. The MCP request is handled as that person, not as a general application user with a mailbox name supplied beside the credential.
That distinction matters. A client does not choose an account by passing an email address beside a valid credential. The credential identifies the account. Package drafts, inbox reads, thread lists, and contact lookups use that identity when selecting records.
The browser portal establishes the same personal boundary with an emailed-code sign-in. It does not turn a browser session into access to every account on the host.
Ownership is part of the query
An inbox query is scoped to packages for the authenticated participant. A thread can be opened only by a participant. A pending draft is selected with its author, and confirming a draft checks that it belongs to the caller.
Contacts follow the same shape. The contact book starts from pairs involving the caller, then divides them into accepted contacts, incoming requests, outgoing requests, and blocked addresses. A name resolver searches only the list appropriate to the requested action. It does not search a global people directory.
These are application access boundaries. They are not a claim that every user or thread has a separate encryption key, or that records are encrypted under a different key for every person. Separation comes from authenticated identity and account-scoped access.
Read state follows the same caution. A mail scanner can fetch a package link, so opening that link is not proof that its recipient read the briefing. Deliberate acknowledgement and authenticated package retrieval are stronger events; the link fetch itself is not shown as evidence of reading.
Contact pickers are partitioned too
Some MCP hosts can show RelayLink contacts as resources in a picker. A fixed resource catalogue would be wrong for a multi-user server: it could offer one person's correspondents to another person.
RelayLink therefore builds the resource list for the current caller. It lists only accepted contacts from that account. Reading a resource repeats the account-scoped lookup. A pending request, blocked address, unrelated account, and unknown address do not become readable contact resources.
This is why contact resources and private names belong to the account rather than to the connected app. An assistant receives the contacts of the person who authenticated it, not every contact known to the deployment.
Private nicknames stay viewer-specific
A nickname is stored on the side of the contact relationship that set it. Two people can label each other differently. Lists, previews, and threads build the displayed contact label for the viewer.
The main crossing risk is the package itself. An assistant may see a private nickname and copy it into prose the recipient will read. RelayLink checks assistant-composed package fields for a private nickname and asks for wording the recipient would recognize, unless the account holder deliberately allowed that nickname to be shared.
That is a narrower, testable claim than saying private labels can never escape under any circumstance. Text a person types directly in the portal or sends by email remains their own wording.
One person may have several assistants
Inbox separation is between account identities, not between devices or AI vendors. One person may connect several assistants to one account and intentionally give all of them access to the same inbox, threads, and contacts. Sending a briefing to yourself uses that shared personal context as a hand-off.
Several humans sharing one account is the opposite case. RelayLink does not technically prevent someone from copying a credential, but every holder then presents the same email and display identity and reaches the same records. RelayLink cannot distinguish those people as separate senders. If individual authorship matters, give each person their own account and credential. Why consent beats a shared inbox explains why collapsing those boundaries changes the policy, not merely the login screen.
Separate credentials on one person's account are useful for revocation, but they do not create separate inboxes for that person's assistants. RelayLink provides no per-assistant sub-inbox inside one account. A different account represents a different email and display identity; RelayLink is not a shared role mailbox with hidden operator identities.