Approvals & 2FA
How a member gets something done that their role cannot do alone.
A member cannot connect a connector, and nobody can delete one without a second factor. Both of those are handled by the same idea: the action is proposed, then executed server-side once someone with the authority signs off.
What needs an approval
| Request | Raised when | What happens once approved |
|---|---|---|
| Connect MCP | A member connects a connector | The connect flow runs, with the requester as the actor |
| Write action | A member proposes a provider write | That one tool call executes, server-side |
Owners and admins never generate these. They act directly.
The flow
The member files a request
They pick one owner or admin by name from the list of people who can approve. The action and its payload — including any credentials they entered — are encrypted at rest with AES-256-GCM before the request row is written.
That person gets an email
The email carries a single-use review link. The token behind it is 256 bits of randomness and is stored only as a SHA-256 hash, so the row itself cannot be replayed into a working link.
They approve or reject
Opening the link is not enough. The decision requires an active session belonging to the named approver, and their authority is re-checked at that moment rather than trusted from when the request was filed.
The action runs server-side
On approval the action executes with the requester recorded as the actor. A connect request has its stored credentials cleared the moment they have been used.
Both parties get a result email.
Request states
| Status | Meaning |
|---|---|
| Pending | Waiting on the named approver |
| In progress | Approved, action executing |
| Approved | Executed successfully |
| Rejected | The approver declined |
| Expired | Nobody acted within the window |
Requests expire after 7 days. Members track their own at /requests; approvers see what
is waiting on them there too.
An approver who has since lost the role cannot approve. Because authority is re-checked at decision time, demoting someone immediately invalidates every request pointing at them — the requester picks someone else.
Two-factor on destructive actions
Some actions require a one-time code emailed to whoever is performing them, on top of the role check. This is not the same system as approvals: there is no second person, just a second factor.
- Signing in
- Deleting a connector
- Deleting the organization's account
Codes are never stored in plaintext. What is stored is an HMAC of purpose:email:code, which
means a leaked table cannot be reversed against a rainbow table of all one million six-digit
codes.
A delete code is also bound to the specific resource it was issued for, so a code you requested to delete one connector cannot be replayed against a different one. Attempts are counted, and codes expire.
A member cannot delete a connector at all, with or without a code. The one-time code is a second factor on an owner or admin, not a way to raise a member's authority.