Your agent shouldn't have to turn off 2FA

agents mcp security transparency

Here is a thing that happens. You hand an agent a real task - check the staging dashboard, pull a log out of an admin panel, verify a deploy went out. It gets as far as a login, satisfies the password, and then hits a 2FA prompt. And stops. If you were watching, you read the code off your phone and type it in. If you weren’t, it sits there until you notice.

The workaround people actually reach for, when this happens often enough, is turning 2FA off on that account.

That is the problem this feature exists to solve, and we would rather say so plainly than dress it up. An agent shouldn’t have to break your second factor to get past it.

Agent access is live on Pro. You connect an AI agent to FactorCat, and it can list your factors (the accounts you have 2FA set up on) and request a code for one of them. Not by holding your secrets. By asking, the same way your browser extension asks, and getting the same answer your browser would get.

What the agent actually receives

A computed six-digit code. Never the seed it was computed from.

That distinction is the whole design. A TOTP secret is a long-lived key - whoever holds it can generate valid codes forever, for every future login, with no further involvement from you. A code is a six-digit number that is worthless in thirty seconds. Handing an agent the first thing would be handing over the account. Handing it the second is answering one question, once.

So the agent can use the code in front of it, and it cannot produce the next one. If you disconnect it, there is nothing left behind that keeps working.

To be precise about scope: this is a claim about your authentication factors, your TOTP codes. It is not a claim about every kind of credential, and we want that on the record now rather than quietly narrowed later. If we ship a way to store API keys and service secrets down the line, those are bearer strings rather than something computed, and “codes, not seeds” will not describe them. Different credential, different conversation.

Why your phone still buzzes

The approval rules your agent follows are the rules you already set. There is no separate agent policy, because agent access is not a separate system - it is another client of the approval flow the extension has used since launch.

  • Locked Vault: your phone is required. The code is generated on your device, so nothing else can produce it. No setting changes this.
  • Approval required: push to your phone, you tap, the agent gets the code.
  • Never require approval, on a Cloud Vault: the code comes back directly, with no push.

That third one deserves a straight answer rather than a skipped paragraph, because a security reader will find the setting in about four seconds and read an omission as evasion.

If you set a vault to never require approval, your agent gets codes from it without a tap. We did not carve out an exception that forces agents to be approved anyway. The reason is that the setting is a decision you made on purpose, about a vault you chose, for accounts where you decided a tap wasn’t worth it. Overriding that when the requester happens to be an agent would mean deciding we understand your threat model better than you do.

What we would not say is that this means your agent gets in without you lifting a finger. You already lifted it. You lifted it when you configured the vault. The agent is following a rule you wrote, and if you want a different rule, change the vault to require approval and it applies to the agent and your browser equally.

The connection is one object, and you can see it

Connecting an agent creates a grant: one record, visible in your dashboard, revocable in one click.

A grant is a requester, not a holder. It has permission to ask and nothing else - no key material, no cached secrets, no copy of anything. Which is why revocation is instant and total rather than a cleanup job. There is nothing to rotate, nothing to re-encrypt, and no other device that has to find out.

Every request is logged, including the ones that needed no tap. When a vault is set to never require approval, no push fires and nothing interrupts you - so the log is the only place that access appears at all. That is exactly why it is there. A feature that lets something ask for codes silently needs a record, or “silently” means invisible, and those are different words for a reason.

The log records which agent asked, as the agent named itself at the time.

One thing we want you to be suspicious about

MCP clients register themselves and supply their own display name. We cannot verify that name. An agent can call itself anything it likes, including something reassuring.

So FactorCat treats it as what it is: a label the agent gave itself, shown as self-declared everywhere it appears - the consent screen, your settings, the audit log, the push notification. We are telling you this rather than hoping you don’t think about it, because the honest version of this feature includes the part where a name on a screen isn’t proof of anything. If a request arrives from something you don’t recognise, deny it and go look at what’s connected.

Read-only, and deliberately unfinished

The agent can list and it can request. It cannot add, rename, move, or delete anything.

Grants are also unscoped in this release: a grant reaches every factor you can reach, including factors shared to you - bounded by the fact that the sharer’s own vault settings still govern, so their approval-required factor still pushes to their phone, and their notification says an agent asked.

We could have shipped a half-built permissions surface where you pick vaults per agent. We decided it was better to ship one honest thing - a grant is agent access, it reaches what you reach, here is the log - than a configuration screen with three settings that each half work. Narrowing a grant to specific vaults is work we intend to do. Until it exists, the audit trail is the control, and we would rather you know that than assume a scope you don’t have.

What is actually different here

Per-request human approval is not something we invented, and by the time you read this it is not unusual. Several products in this space ask a human before a credential gets used, and that is good - it should be table stakes.

Three things are genuinely ours:

The code comes from a device the agent isn’t running on. Your phone is not the machine the agent is working on. An approval that happens on the same device as the thing being approved is a weaker boundary than one that crosses a gap, because compromising the machine compromises both halves.

It is the same approval you already use. Nobody bolted a second mechanism onto the side. Your vault settings, your push notifications, your approval history - the agent is a new kind of client for machinery that was already there and already load-bearing.

It works with whatever speaks MCP. Any MCP client that can reach a remote server can connect. Not one assistant, not one operating system, and the code you get back is usable wherever you need it rather than only inside a browser page.

And one honest counter-point, because leaving it out would be the kind of omission this post is trying not to make: there are products that inject a credential into a page directly, so their model never sees it at all. That is a real property and we do not have it. Our agent does receive the computed code - it has to, in order to use it somewhere we don’t control, which is also what makes it work outside a browser. Never the seed. But “never the code” belongs to a different design, and it isn’t ours to claim.

What we are not suggesting you do

Two things we would rather not see, even though the feature technically permits them.

Don’t point this at your bank or your brokerage. The human tap does not change our view here. An agent authenticating into financial accounts is a risk shape we don’t think a 2FA product should be encouraging, regardless of how good the approval step is.

Don’t use it to get an agent past a service’s own automation defences. If a platform has decided it doesn’t want automated logins, supplying a valid code doesn’t make that decision go away - it just means the thing it bans is now harder for it to spot. That isn’t using 2FA as intended, and it isn’t what we built.

What this is for: your own infrastructure, your own dashboards, your own scheduled jobs. The places where you are the account holder and the only thing standing between your agent and a finished task is a code you would otherwise have typed yourself.

Getting started

Open Settings > Agent access in the dashboard, copy your server URL into your agent’s MCP settings, and approve the consent screen. There is no credential to paste. Agents that can’t open a browser use a personal access token instead.

Five connected agents on Pro. Revoke any of them whenever you want.

Learn more

Get FactorCat

Available on iOS, Android, Chrome, Firefox, and the web. Free for up to 50 factors.

Get started free See platforms