Agent Access (MCP)
Connect an AI agent to FactorCat so it can request your 2FA codes through the same approval flow your browser already uses. Read-only, revocable, and logged.
Agent access lets an AI agent ask FactorCat for your 2FA codes the same way the browser extension does. The agent sees the list of your factors (the accounts you have 2FA set up on) and can request a code for one of them. What happens next depends on the vault settings you already chose: the phone buzzes for a tap, or the code comes straight back, exactly as it would for your browser.
Available on Pro.
What the agent can and cannot do
It can:
- List your factors - service name, account label, and which vault each one is in
- Request a current code for any one of them
It cannot:
- Read your TOTP secrets. The agent receives a computed code, never the underlying seed the code is generated from.
- Add, rename, move, or delete anything. Agent access is read-only.
- Change your vault settings, or make approval less strict than you set it.
- Keep standing access. There is no “the agent has your vault” state. Every code is a separate request through the approval flow, and every request is logged.
Connecting an agent
There are two ways in, and both produce the same thing: a grant, which is a single revocable connection with one audit trail.
Interactive clients
Most MCP clients can connect on their own. Open Settings > Agent access in the web dashboard to find your server URL, then paste it into your agent’s MCP server settings. The client registers itself, FactorCat opens a consent screen showing you what is about to be connected, and you approve it there.
There is no credential to copy, paste, or store anywhere. The agent never holds a password or a secret of yours.
This works with any MCP client that can connect to a remote MCP server, whatever it happens to be - a coding agent in your editor, a desktop assistant, something you wrote yourself.
Headless agents
An agent that can’t open a browser - a scheduled script, a job running on a server - authenticates with a personal access token instead.
Create one in Settings > Agent access. Give it a name and choose when it expires. The name is your own label, for your records; the agent does not pick it. The expiry list includes a never-expires option, and that one you have to choose on purpose.
The token is shown once. We keep only a hash of it, so we cannot show it to you a second time, and neither can anyone who gets into your account. Copy it when it appears.
If you lose it, or you think it may have been exposed, rotate it from its row in the same panel. Rotating issues a new token and stops the old one working immediately, while keeping the connection, its settings, and its history. It is not the same as disconnecting and reconnecting the agent - only what the agent authenticates with changes.
Both paths behave identically after connection. Same approval behaviour, same audit trail, same single place to revoke.
How approval works
Your vault settings govern agents exactly as they govern your browser. This is the part worth understanding properly, because it means you have already made these decisions.
| Vault setting | What happens when your agent asks |
|---|---|
| Locked Vault | Your phone is required, always. The code is generated on your device, so nothing else can produce it. |
| Approval required | Push notification to your phone. Tap approve and the agent gets the code. |
| Never require approval (Cloud Vault only) | The code returns directly, with no push. |
That last row is a setting you turned on yourself, for a vault you chose, before any agent existed. Your agent follows the rule you set - it does not get a special exemption from one. If you would rather agents always tap through, change the vault to require approval and it applies to the agent and the browser alike.
For the full picture of what these settings do, see Push Approval.
While a request is waiting
A code request holds open for about a minute, waiting for you.
If nobody has approved by the time that runs out, the agent gets a timeout carrying a request id, not a failure. It can check that request’s status, or simply ask again. Asking again joins the same pending approval rather than starting a second one, so your phone does not buzz twice for one request.
This matters most for a headless agent reaching into a Locked Vault, where approval is never optional because the code is computed on your device and nothing else can produce it. A script is not locked out there. It just needs you to approve, and needs to come back for the answer.
Factors other people shared with you
Agent access reaches every factor you can reach, which includes factors shared to you. The bound on this is that the sharer’s vault settings still apply. If someone shared a factor that requires approval, their phone still gets the push, and their notification says an agent asked rather than just naming you.
What gets logged
Every agent request is recorded in your approval history with the agent’s name as it was at the time of the request.
Including the requests 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 shows up. That is deliberate: it is why the log exists rather than being a convenience feature.
Agent names are worth one note of caution. An MCP client supplies its own display name when it registers, and FactorCat has no way to verify it - the name is a label the agent gave itself, not an identity we confirmed. FactorCat shows it as self-declared wherever it appears. If you are approving a request from something you don’t recognise, deny it and check your connected agents.
Revoking an agent
Open Settings > Agent access and revoke the grant. It stops working immediately.
Revocation is instant because the grant never held any key material. It was only ever allowed to ask, so withdrawing permission to ask is the whole of it. Nothing needs re-encrypting and no other device is affected.
The history of what that agent did stays in your approval log after revocation. Revoking removes future access, not the record.
Revoking everything at once
The same panel has a single action that cuts off every connected agent. It is what to reach for when you think something is wrong and you would rather not work out which connection it was first.
It asks you to confirm, so a stray click cannot do it. Every token stops working immediately and none of them can be restored. It works on every plan, including after a downgrade. Revoking is never behind a paywall.
Limits
- Five connected agents at a time on Pro. The cap keeps the blast radius of any one connection small, and nudges toward one grant per agent rather than one shared grant for everything.
- Read-only, with no per-agent configuration in this first release. Every grant reaches everything you can reach. Narrowing a grant to specific vaults or factors is something we intend to add, and we would rather ship it properly than ship half of it now.
- Request limits apply per agent, so a misbehaving agent in a loop runs out rather than running on. Refused requests are counted and shown to you, because an agent stuck in a retry loop is something you want to find out about.
If you downgrade
Connected agents are suspended, not deleted. They stop working right away, stay visible in your settings, and keep their credential. Upgrading again restores them as they were, with no reconnecting.
Suspended is different from revoked. Revoked is permanent.
For the thinking behind this feature and what we do and don’t claim about it, see Your agent shouldn’t have to turn off 2FA. For how the same approval flow works in your browser, see Push Approval.