Article · Security

Why every sensitive action now asks for a second factor

published: 2026-08-16reading time: 4 min

The control plane vault holds the keys to your LLM spend. If a session is hijacked, that's where the damage happens: add a rogue provider key, mint device tokens, wipe the account. The answer isn't another checkbox on login — it's guarding the actions that matter.

The design: guard the action, not just the login

Login 2FA stops the intruder at the door, but says nothing about a session that was already hijacked, or a user whose machine is compromised. Instead, the plane guards the sensitive surface: adding/removing API keys, generating or revoking device keys, forgetting devices, deleting agents, and the factory reset. Each requires a fresh verification:

POST /api/v1/mona/2fa/challenge  {code, via: totp|email|backup}
→ grants 15 minutes of sensitive actions in this session

One code unlock, not per-click nagging. The grant lives in the session, expires after 15 minutes, and is revoked immediately after disabling 2FA.

Three channels, one goal

The dashboard flow

Because every guarded call goes through one API helper, the front-end can detect 403 code=2fa_required automatically: it opens a verification modal, accepts a code, and retries the original request. Users don't think about "challenges" — they just get asked for a code exactly when something sensitive is about to happen.

What it changes in practice

Before: one password between an attacker and the vault. After: a password plus a possession factor plus a fresh challenge per sensitive action. For a control plane whose whole pitch is "your keys stay in the vault", that's the difference between a feature and a liability.

© 2026 remoteagent.onlineRelated: Security Model