Can Your AI Coding Agent Log In Without You?

When you develop software with AI tools - whether it's Claude, Codex, Cursor, or Copilot - approving permissions becomes part of the job. Often, a pretty annoying part.

You realize that the more permissions you give the agent upfront, the fewer interruptions you'll have and the faster you'll get your product, feature, or ticket done. From conversations with my colleagues, everyone seems to have either switched to automatic approvals or started approving everything without looking too closely.

And this applies to more than amateur vibe coders. Professional developers are doing it too. Between pressure from management and pressure to stay competitive, they're now expected to commit a lot more AI-generated code.

Once the permissions are out of the way, the next time sink is creating accounts across all the services a project needs: hosting providers, domain registrars, DNS providers, databases, payment processors, email services, and analytics dashboards.

Naturally, developers let AI configure things inside those accounts to speed up the process.

There are two main ways to do this: through MCP, a standard that lets agents connect to external tools and services, or by giving the AI access to those accounts through a browser.

Official MCP integrations often require a paid account. Unofficial ones can be risky. The browser option means signing in through a browser the agent controls using an extension or a computer-use feature. I often choose this second option, especially when something only needs to be configured once.

Now, back to the question.

There's a constant stream of discussion about AI getting out of control. That could happen for different reasons: a new model behaving in unexpected ways, or someone deliberately trying to hijack an agent.

OWASP lists prompt injection as a leading risk. In plain English, that means malicious instructions planted in something your agent reads - such as a webpage or repository - that can trick it into following someone else's instructions instead of yours.

As long as an MCP connection remains active, or accounts remain signed in on a computer where your agent can access them, you cannot guarantee that the agent won't do something malicious with those accounts.

That part is understandable. How to deal with it deserves a separate discussion.

I wanted to answer a different question: can your AI coding agent log back in and do something malicious after you've signed out?

Let's look at a few ways an agent could gain access to your accounts and what I suggest doing in each case.

Case 1: It can log in if you don't have two-factor authentication enabled.

Of course, it's not only the agent: anyone who has your username and password can log in to your account if two-factor authentication is not set up. That's why this is the first thing to look at.

What to do: Enable two-factor authentication using an authenticator code (TOTP) or a code sent by SMS. The authenticator app or SMS messages must be on a separate device that the agent cannot access.

Check that there are no authentication methods registered other than your own. In theory, the agent could have added another method while it had access.

Case 2: You use 1Password or a similar service to sign in, and the vault is unlocked.

While your vault - the place where the password manager keeps the logins for your accounts - is unlocked, the agent can log in through a feature such as OpenAI's Computer-Using Agent or its equivalents from other vendors.

What to do: Remove the account's login entry from the vault.

For example, I keep two 1Password accounts. One is for the agent and holds the logins for the accounts the agent is allowed to use. When I want to end the agent's access to one of those accounts, I move its login to a vault the agent cannot reach.

Case 3: You manually typed your username and password into the browser.

If you have installed a browser extension such as Claude in Chrome, for example, the agent may be able to read the username and password you type into a login form in that browser. In more extreme cases, it could capture them with a keylogger.

What to do: Change the password to a unique, sufficiently long one. Don't store it or paste it anywhere on the same computer where the agent runs.

Case 4: Your username and password are - or previously were - stored in plain text on your drive.

With root access to your computer, the agent can read every unencrypted file on it - sometimes even files that were deleted in the past without being securely wiped.

What to do: Change the password to a unique, sufficiently long one. Don't store it or paste it anywhere on the same computer where the agent runs.

Case 5: You shared your username and password in a chat with the agent.

These days Claude, for example, refuses to log in on its own even when you hand it the username and password. Not long ago it would. Either way, your credentials may still sit in the chat history.

What to do: Change the password to a unique, sufficiently long one. Don't store it or paste it anywhere on the same computer where the agent runs.

Case 6: You gave the agent an SSH key or an API token to manage a server.

What to do: Revoke access for that SSH key or API token, or replace the compromised one with a new one.

My conclusions

First: In my view, an agent has the technical means to read your username and password and try to log in to your account - if it was given the access, and the model has been prompt-injected or is misaligned.

Second: You can never guarantee that your agent is not compromised right now. So for production accounts, I would always revoke the agent's access once its work is done, using the steps below.

How I would revoke that access

Use a separate, uncompromised device for all of these steps:

1. Remove the account's login entry from 1Password or any other password manager the agent can access.
2. Revoke the MCP integration's access to the account.
3. Revoke or replace any SSH keys you gave the agent.
4. Change the password to a unique, sufficiently long one.
5. Revoke the account's active sessions on the computer the agent uses. If you can't confidently identify them, use "sign out everywhere" where the service offers it. Don't assume changing the password has already done this.
6. Review API tokens, connected applications, and other access permissions. Revoke anything you don't recognize or no longer need, including credentials created for the agent's work.
7. Enable two-factor authentication if it isn't already enabled.
8. Set up two-factor authentication again with a new secret if it was previously configured. Check that no other authentication methods have been added.

I started with a simple question: can the agent log back in after I sign out? What I found is that signing out tells me very little about what access is still available. There may be another session, a saved password, or a token that no longer needs my approval.

For production accounts, I would treat the end of the agent's work as the moment to review and revoke that access. The checklist above is my starting point. Next, I want to go through this process on the services I actually use, see how practical it is to do every time, and explore how it can be streamlined.