The button says "Connect," or "Allow," or "Authorize." Underneath it, in smaller type, sits a list of exactly what's being agreed to, and almost nobody reads it, because the button is right there and the list is long. That gap between the click and the list is where most of the risk in connecting an app actually lives.
A grant is three things, not one
Whatever the consent screen calls it, approving a connection hands over three separate things at once.
- A scope. Not the friendly category on the button — "connect your email," "connect your files" — but the specific list underneath it: read-only or read-and-write, one folder or the whole account, a single file or everything owned. The category name is marketing copy for the actual list.
- A duration. Most connections are standing grants. Once approved, the permission persists in the background, unattended, until someone actively goes back and revokes it. It isn't a one-time transaction like handing someone an ID at a door and getting it right back.
- A delegate. The app doesn't act with a person watching; it acts as authorized, using its own credentials, whenever its own logic decides to. Anything downstream that receives an action from it has no way to tell whether a person was paying attention at that moment. That's the entire point of delegation, and it's also the entire risk.
Losing track of any one of the three is how a connection approved once, for one small reason, ends up doing far more than intended.
Why the checkbox list is worth reading
"Read your email" and "read and send your email" look like two nearly identical checkboxes on the same screen. They are nowhere close to the same grant. One means a bug or a hijacked integration can see things it shouldn't. The other means it can become the account holder in someone else's inbox. The wording difference is often a single clause — "and send," "and manage," "all files" instead of "files opened with this app" — sitting in a scope list most people scroll past on the way to the button.
This is where permission scope and technical risk meet. An agent that can only read is bounded by how bad a wrong summary can be. An agent that can also send, or delete, or act on what it reads is bounded by something much larger — and if the content it reads is untrusted, a wide scope is also just more material available to leak: zero-click exfiltration is only as damaging as what happens to be sitting in reach when the leak fires. A scope granted once quietly sets that ceiling for as long as the connection stays active.
What to check before clicking allow
A short habit covers most of it:
- Read the permission list, not the button label. The button names a category; the list names the actual grant.
- Notice whether it says "read" or adds "write," "send," "manage," or "delete." That word is doing most of the work.
- Ask whether the grant is standing or one-time, and assume standing unless the flow says otherwise.
- Check back periodically. Most services keep a list of connected or authorized apps somewhere in account settings; the exact location differs by provider and shifts over time, but the list itself is close to universal, and stale connections that are no longer used are pure downside.
None of this requires distrusting every connector. It requires reading the same three lines — scope, duration, delegate — every time, instead of once when a service was unfamiliar and out of habit after that.
Where RelayLink differs, and where it doesn't need to
Adding RelayLink to an assistant is itself a connection, so it's worth naming what it actually asks for: a RelayLink API key, scoped to RelayLink's own tools, and nothing about any existing mailbox at all. There's no inbox scope to grant because there's no inbox connection; correspondence runs through a separate channel rather than the account someone already has.
That's a design choice worth stating plainly, not a universal rule. Plenty of legitimate tools have jobs that genuinely require inbox scopes — search, scheduling, migration — and for those, a well-scoped, revocable grant is the right tool, not a red flag. The checklist above applies to all of them the same way it applies to RelayLink: read what's actually being granted, notice how long it lasts, and remember that once it's approved, something else is acting, not just watching.
Run those same three questions on the next connector before clicking allow: what can it see, how long does that last, and who's actually acting once it's approved. Connect your assistant to RelayLink knowing the answer to that last one is nothing from any mailbox, revocable at any time.