What do you disconnect first if you think an agent was tricked: the chat channel, the saved login, or the API key?

Disconnect the saved login first, then the API key that can change your accounts, then the chat channel. The saved login is a live session that can still send, pay, or read while you are hunting through menus. Closing the chat stops new messages and leaves that session running. An API key comes before the channel when the key itself is what the tools use to act. A key that only calls the model comes after the login, because it keeps the loop alive but does not, by itself, open your mailbox. Do not spend the first minute muting a channel.

You can do all three. The order is about the next sixty seconds, not about which one feels most dramatic.

Why the channel is the wrong first click

I thought an agent had followed a bad page, and my hands went to the chat app. I archived the thread. The laptop was still running the agent, still logged into the browser profile, and it submitted a form a minute later. The channel was how the task had started. It was not how the next click was authenticated. Muting the room felt like control because the words had come from there. The words were done. The cookie was not.

A scheduled run or a loop already in flight does not read your mute. It uses whatever session and key were loaded when it started. Disconnect those, or the loop finishes the thing you are afraid of while the channel looks clean. I now leave the chat window alone until the session is dead. Unread messages can wait. A sent message cannot.

What “saved login” covers

The browser profile the agent was driving, especially if it is your daily profile. Sign that profile out of the sites that matter, or quit the browser and revoke the sessions from the account’s device list. Signing out on the site’s security page is better than closing a window, because the window can restore. Do mail, the registrar, billing, and work admin before you do a docs site.

OAuth grants are saved logins under another name. The connected-apps list on the account is the off switch. Remove the agent’s app. A password sitting in a manager the agent can open counts too: lock the vault and remove the integration. You are not investigating yet. You are making the next tool call fail.

If you are not sure which profile it used, sign out the daily one anyway and close the agent profile. Over-revoking a session costs you a login later. Under-revoking costs you the action that is in flight. I take the re-login.

Which API key, and when it jumps the queue

There are two keys people mix up. One pays for the model. Revoking it stops new model calls, which stops a loop that has to think before it acts. It does not invalidate a cookie already in a browser. Do it second, after the login, unless you cannot reach the login and the key is the only switch you have. Then pull the key immediately and get to the login next.

The other key is the account: a token that can send mail, push git, or move money through an API. That key is not “second.” It is the same class as the saved login. Revoke it in the same breath as the session. If you only have one minute and both exist, revoke both before you touch the chat. A model key without that account key cannot send your mail. An account key can send it with no model at all if something else is holding it. Treat account keys as logins.

Do not paste the key into a note to remember which one you killed. Revoke it in the dashboard, where the name is, and leave the secret unseen. If you cannot tell two keys apart because both are named default, revoke both. Naming was the thing you were going to fix later. Later is now.

Then the channel

After the session and the account key are dead, disconnect the channel so a new message cannot start the next run, and so a group chat is not still an input. Leave the bot, unlink the account, or disable the gateway’s connection to that room. Do this even if you think the trick was a web page rather than a chat message. The channel is still a way for the next instruction to arrive while you are tired. I would rather the agent be silent than helpful for the rest of the day.

If the channel is how you reach the machine that holds the session, do not make it your only path and then depend on it last. A phone that can only stop the agent by chatting “stop” is a bad off switch. Stop has to work as a revoke, not as a prompt the model might ignore. If “stop” is just another message, it is not step one and it is not reliable as step three. Revoke the credential.

What I do not do in the first ten minutes

I do not ask the agent what happened. That is another prompt into a system I am trying to turn off, and the answer will be a story. I do not rotate every password in the vault before I have killed the session that can read the vault. Rotating while the session lives can hand the new password to the same loop. Kill the session, then rotate the accounts that were reachable: mail, banking, registrar, the keys you revoked. I do not write a postmortem before the Sent folder is checked. The postmortem is for after the credentials are dead.

I also do not reconnect a “clean” bot five minutes later to see if it is fine. Fine is tomorrow, with a new profile that has never been logged in, and no account key until I know I want one. The rest of the evening is a human on the sites that matter, looking for a send or a setting change. The agent does not help with that look.

A machine you are not sitting at

If the agent runs on a server or a cloud box, the saved login may be a browser profile on that box, not on your laptop. Closing your laptop does nothing. You need the host’s session: revoke the OAuth app from the account website, which works from any device, and revoke the API key from the provider’s dashboard, which also works from any device. Those two pages are reachable without the agent. Use them. SSH-ing in to “kill the process” is good if you can do it quickly, and it is not a substitute for the revoke. A process supervisor will restart the agent, and the restarted agent will still have the key on disk. Revoke first so the restart is harmless. Then stop the process if you can. Then the channel.

Phone-only control is the awkward case. The phone is the channel. You can still open the mail provider’s security page in the phone’s browser and remove the app, and you can open the API dashboard and revoke the key, without sending the agent another message. Do those in the browser. Do not open the agent chat and type “disconnect yourself.” A tricked agent is a bad person to ask for help, and a message to it is another instruction. The phone is useful as a browser onto the account pages. It is a poor off switch when used as a chat.

After the credentials are dead

Check Sent, recent logins, and the calendar or billing page for a change in the last hour. You are looking for an action, not for an explanation. If you find one, the disconnect was late and you still needed it, because the session might have had a next step. If you find none, the disconnect was still right. You do not reconnect to reward a clean folder. Leave the agent off until you have a profile with no saved logins and keys that are new, named, and absent from the old machine. Copying the old profile “minus the bad tab” copies the session. Make a new one.

Tell a teammate if the shared vault or the shared mailbox was in that profile. They cannot see your mute. They can see a rule that changed or a mail that left. One sentence is enough: the agent’s session is revoked, look at the shared account for anything you did not do. Do not forward them the agent’s transcript as the proof. The transcript is the story. The account page is the proof.

The order on a card

Saved login and any account API key first, together if you can. Model API key next if the loop still needs to think. Chat channel after the credentials are dead, so nothing new starts. If you only do the channel, you have tidied the conversation and left yourself logged in. The trick, whatever it was, needed a credential to become an action. Take the credential before you take the conversation.