Security

No credentials to lose

• No API keys. There is no key to generate, store, rotate, accidentally commit, or paste into the wrong window. If a client asks for one, it's wrong for this server.
• Short-lived tokens. Access tokens expire quickly and are refreshed silently. A captured token has a small window and works only against the MCP endpoint.
• Audience binding. A token minted for the MCP endpoint is rejected everywhere else, and tokens minted for other Revo services are rejected here.
• PKCE is mandatory. S256 is the only challenge method offered, which closes off authorization-code interception on the redirect.
• Your password never reaches the AI client. Authentication happens in your own browser, on Revo's domain.
• Revocation is immediate. Revoking the session stops the connection at the next request. There is no offline capability to expire.
• Your identity provider stays in the loop. MCP sign-in uses the same hosted login as the Revo app, so a workspace configured with SAML or OIDC single sign-on authenticates through its own IdP here too. MFA, device posture and conditional access policies apply to the MCP connection exactly as they do to the web app.
• Offboarding takes effect immediately. Workspace membership is re-checked on every single request. Remove someone from the workspace and their next MCP call fails, regardless of how long their token had left to run. Section 6 covers revocation in full.

Authorization is computed, not claimed

This is the single most important property of the design. The access token establishes identity only. Every question of permission (which workspace, which role, which tools, which records) is answered by querying Revo's own database at the moment of the call.

The practical consequence: a forged, replayed, or over-scoped token cannot grant access, because nothing in the token is consulted when deciding what the caller may do. Neither can a compromised AI client, a malicious prompt, or a bug in the assistant. None of them are in a position to influence the answer.

Tenant isolation

The workspace an MCP call operates on is derived from your user record on the server. It is not a tool parameter: no user-facing tool accepts a workspace, team, or user identifier that would let a caller point it somewhere else. Prompt injection cannot redirect a call to another customer's data, because there is no input to inject into.

Within your own workspace, the same access rules the Revo app enforces apply again at every tool:

• Meetings resolve to workspace-shared meetings plus your own private ones, never a colleague's private recording.
• Knowledge-graph results are filtered to your visibility before they are returned.
• Memories are private to you.
• Per-teammate usage requires the admin permission; a member sees only the workspace total.
• Writes go through the same validated commands as the app, so the same rules and audit events fire.
• Record identifiers are hashed rather than sequential, so they cannot be enumerated by guessing.

The staff tools, and why they're safe

Revo's cross-workspace support tooling is the one place where a workspace is an argument, so it gets a separate control:

• A distinct permission namespace (revo_admin:*) that no customer role can ever be granted.
• An internal-staff check evaluated against a feature flag keyed on the caller's email address, off by default, so the tools are dark unless a named individual is explicitly targeted.
• Tools are removed from the listing, not merely refused, so a non-staff assistant never learns they exist.
• The one genuinely destructive tool, the account-erase used to reset test accounts, is additionally hard-locked to development environments by an allow-list, and refuses outright anywhere else. It cannot run in production regardless of who calls it.

Transport and infrastructure

• HTTPS only, HTTP/2, behind Cloudflare edge protection.
• Session identifiers returned to clients are encrypted with a shared key ring, so they cannot be forged or read, and remain valid across instances and restarts.
• Any credentials you store for your own custom MCP servers inside Revo are encrypted at rest.
• Failed authentication is logged with the specific reason (bad signature, wrong audience, expired) without ever writing the token itself to logs.

What you should still think about

Two honest caveats, neither specific to Revo but both worth stating: