One assistant should stop accessing RelayLink, but another assistant, a workflow, and your phone still need the same account. Closing the whole account is unnecessary. The safe response is to identify the credential door the unwanted client uses and close only that door.
RelayLink has two kinds of door: OAuth applications and named API keys. Their revocation controls are intentionally separate.
Identify how the assistant authenticates
Start from the client's configuration and your RelayLink account pages.
An OAuth connection is the one that sent you through RelayLink sign-in and a consent page. It appears under Connected applications.
An API-key connection has an X-RelayLink-Key value stored in a connector, environment, or secret manager. It appears under Keys with the name chosen at issuance, a hint when available, and a last-used time.
Do not identify the door only from the model name. Claude, ChatGPT, or a framework can be configured differently in different environments. A client may also have been migrated from a key to OAuth while the old credential remained active.
Make a short inventory before acting:
client to stop: desktop-agent
possible OAuth application: example.ai
possible named key: desktop-agent
connections to preserve: ChatGPT OAuth, workflow-runner key
If compromise is active, do not delay revocation merely to make the inventory perfect. Close every credential plausibly held by that client, then restore trusted access deliberately.
Disconnect an OAuth application
Sign in to RelayLink, open Connected applications, find the application, and choose Disconnect.
The unit of revocation is the application, not one consent click or device. If you approved the same application twice, RelayLink may hold several live authorizations. Disconnecting revokes all grants and tokens for that application, so its next authenticated request fails.
That behavior prevents a misleading partial disconnect: removing one authorization while another device or refresh-token family keeps working would leave the application connected after the page reported success.
The boundary is also an honest limitation. If three trusted devices use the same OAuth application and only one device is lost, RelayLink's control disconnects all three. Approve the trusted devices again after containing the lost one.
Other OAuth applications remain connected. API keys remain active.
Revoke one named API key
Open Keys, find the credential named for the integration, and choose Revoke. The revocation is immediate and affects only that key row.
Other named keys continue authenticating. OAuth applications continue using their own tokens. RelayLink also emails the account owner about the key revocation, because a compromised assistant session may be able to revoke credentials while the mailbox remains outside it.
This surgical result depends on issuance discipline. If several assistants share the same key, every copy stops when that row is revoked. Do not postpone containment to avoid that outage. Revoke the shared key, then issue separate replacement credentials from the browser for the clients you still trust.
Last used is a coarse signal, updated at most once per five minutes. It helps identify an active key, but it is not proof that a quiet key was never copied.
Verify the result without disturbing others
After closing the door:
- Make the revoked client perform a harmless authenticated check; it should fail.
- Ask each preserved client to run
whoamior check current RelayLink state. - Confirm preserved clients report the intended account and host.
- Review active keys and connected applications again for forgotten access.
- Inspect pending drafts and cancel anything the removed client prepared but you do not approve.
Revocation stops future authenticated access through that credential. It does not erase package history, retract correspondence already sent, or automatically remove drafts stored on the shared account.
The send boundary still applies to surviving assistants: @relaylink opens a draft and never sends, and an assistant-composed package waits for human approval.
Close both doors when both were used
Disconnecting an OAuth application does not revoke a key the same client also stored. Revoking a key does not invalidate OAuth tokens. If the assistant had both, perform both actions.
That independence is what lets unrelated assistants continue, but it means there is no universal button labeled with a model's name. Revoke the credential, not the brand: application grants on one page, named keys on the other.