Short answer: Where you can, skip 2FA for agents entirely: give them an API key or service account with narrow permissions. When an agent has to use a login page, let a person handle the 2FA step. Never put a 2FA secret key in an environment variable, prompt or config file. A secret there is a permanent second factor that anyone, or any malicious instruction, can pull out.
AI agents can now book meetings, run ad reports and tidy up cloud consoles. Then they reach a login page, the site asks for a 6-digit code, and everything stops.
So the question comes up on every team that uses agents: should the agent get our 2FA codes? Here's how to think about it, from the safest option to the one shortcut to avoid.
Why agents keep hitting 2FA
2FA exists to stop software that knows your password but isn't you. From a website's point of view, an AI agent signing in with your password looks exactly like that. That's the system doing its job.
Agents meet 2FA in three ways:
- Browser agents that click through websites like a person would, including the login page.
- Automations and scripts that sign in to a dashboard to download a report or change a setting.
- Coding agents that deploy, publish packages, or call cloud consoles and hit 2FA on the way.
Each has a better route than handing over your second factor.
Option 1: Don't use 2FA at all. Use an API key
If the service has an API, an OAuth app or a service account, that's the right door for software. These are built for machines:
- they can be limited to exactly what the agent needs (read reports, not change billing),
- they can be revoked in seconds without touching anyone's login,
- they show up in the service's logs as the agent, not as you.
Most ad platforms, cloud providers, payment platforms and code hosts offer one. It's more setup than pasting a password, but it's the answer auditors and security teams expect.
Option 2: A person handles the 2FA step
When an agent has to use a login page, let it hand the 2FA step to a person. Agent makers recommend this themselves. ChatGPT agent asks you to take over the browser to sign in. Anthropic's computer-use guidance says not to give the model login details and to have a person confirm consequential actions.
This is the simplest safe pattern because it keeps a person in charge of the most sensitive moment. You see which site the agent is on before you enter anything, and you can say no.
With Fox Auth, the person's step takes seconds. In the browser the agent is using, open the Chrome extension, check it's suggesting the right code for the site, and autofill it. The reveal is logged under your name, from the extension, like any other.
Option 3: An agent that receives codes, never the secret
Some tools let an agent request the current code through an API or an MCP server, using its own token. At the time of writing, Authn8 and GroupFactor offer MCP servers for 2FA codes, and Proton Pass has access tokens for AI agents. Done well, this can be reasonable:
- the agent gets codes, never the secret key,
- its token covers only the accounts it needs,
- the token expires and can be revoked,
- every code it takes is logged against that token.
The risk is that the agent can now get past 2FA on its own, so everything rides on the agent behaving. If it's tricked into signing in somewhere it shouldn't, nothing stops it.
To be clear about Fox Auth: we don't offer agent API access today. Fox Auth is built around people revealing codes, rate-limited to 10 reveals per person per minute, with every reveal logged. If agent access matters to your team, we'd like to hear how you'd use it at hello@foxauth.com.
The shortcut to avoid: the secret key in the agent's reach
It's tempting to take the setup key from a 2FA QR code and drop it into an environment variable, a config file, a prompt, or the agent's memory. A few lines of code turn it into codes on demand, and the agent never gets stuck again.
Don't do this. Here's why:
- The key is forever. A code is valid for about 30 seconds. The key behind it makes valid codes until someone resets 2FA. Anyone who copies it has a permanent second factor.
- Agents can be talked into things. Text on a web page, in an email or in a document can carry instructions an agent may follow. This is called prompt injection, and it's ranked as the top risk in the OWASP Top 10 for LLM applications. An agent that can read the key can be tricked into revealing it.
- It spreads. Environment variables are readable by every process on the machine and end up in logs, crash reports and CI output. OWASP recommends against them for secrets. Prompts and agent memory can be kept by tools you don't control.
- You lose the trail. Codes generated from a copied key don't show up in any audit log. If something goes wrong, you can't tell whether it was the agent, a person, or someone else.
If an automation genuinely needs to sign in by itself, that's a sign it needs Option 1, an API key or service account, not a cleverer way to hold the secret.
Accounts that should stay human-only
Some accounts can bring down everything else if they're misused. Keep agents away from their 2FA entirely:
- Domain registrars and DNS. Whoever controls these controls your email and website.
- Cloud root and owner accounts. Use scoped roles for automation instead.
- Banking, payments and payroll.
- Identity provider admin (Google Workspace, Microsoft Entra, Okta).
- The email account used for password resets. It's the master key to everything else.
- Your 2FA vault and password manager. Don't give an agent the keys to the place where you keep all the other keys.
A checklist before you let an agent near a login
- Is there an API? If so, use it with the narrowest permissions that work.
- Is this account on the human-only list? If so, stop here.
- Can the agent pause for a person at 2FA? Prefer that to automatic access.
- If the agent gets codes automatically: codes only, its own token, the fewest accounts possible, an expiry date, and a log of every code.
- Is the secret key anywhere the agent can read? If so, reset 2FA on that account to make a new key, then store it in a vault.
- Can you see what happened afterwards? You should be able to say which person, or which agent, used each code, and when.
The short version
Agents are best treated like a new contractor: give them their own scoped access, keep them away from the master keys, and keep a person in the loop for anything sensitive. A shared 2FA vault fits that well. Your team gets codes without passing phones around, the secret keys never leave the vault, and every reveal has a name on it. If you're setting that up, start with how to share 2FA codes with your team, and read is sharing 2FA safe? for the security trade-offs.
Sources
- OWASP, Top 10 for LLM Applications 2025: Prompt Injection (LLM01)
- OWASP, Top 10 for LLM Applications 2025: Excessive Agency (LLM06)
- OWASP, Secrets Management Cheat Sheet
- OWASP, AI Agent Security Cheat Sheet
- Anthropic, Computer use tool documentation
- OpenAI, ChatGPT agent help article
Frequently asked questions
Can an AI agent get past 2FA on its own?
Only if it has access to a code. 2FA is designed to stop software that only knows the password. An agent needs a person to hand over the code, an API that gives it codes, or the secret key itself. That last one is the risky choice.
Is it OK to store a TOTP secret in an environment variable for an agent?
No. Anything that can read the environment can generate codes forever: the agent, its logs, a dependency, or an attacker who tricks the agent into printing it. If an automation really needs to sign in, use an API key or service account instead.
Should an agent use 2FA or an API key?
An API key or OAuth app, almost always. They're made for software. They can be limited to exactly what the agent needs, and you can revoke them without touching anyone's login.
Does Fox Auth have an API or MCP server for agents?
Not today. Fox Auth is built around people revealing codes, with every reveal logged and rate-limited. With an agent working in your browser, you can fill the 2FA step yourself using the Chrome extension. If agent access matters to you, tell us at hello@foxauth.com.