---
title: "Security"
description: "Short-lived OAuth tokens, permissions derived from server-side records on every request, and one tenant per caller."
canonical: https://past.dev/docs/mcp/security
last-updated: 2026-10-09
---
# Security

> Short-lived OAuth tokens, permissions derived from server-side records on every request, and one tenant per caller.

Product: past.dev MCP Server. Source: https://past.dev/docs/mcp/security

### Credentials

- **No API keys.** An MCP connection does not use an API key. A client configured to ask for one is using the wrong authentication method. The one exception is an end-user access link, where the secret in the URL is the credential and section 04 states the trade.
- **Short-lived tokens.** Access tokens expire within the hour and refresh automatically. A token works only against the address it was issued for.
- **Audience binding.** A token minted for one MCP address is refused everywhere else, and a token minted for another past.dev service is refused here. A token for another project's handle is refused, never a cross-project read.
- **PKCE is mandatory.** S256 is the only accepted challenge method. It protects the authorization code during the redirect.
- **Your password never reaches the AI client.** Authentication happens in your own browser, on past.dev or on your own identity provider.
- **Refresh tokens rotate.** Each use issues a new pair, and a refresh naming a different client is refused.
- **Revocation applies on the next request.** Signing out from the client ends the refresh token at once. The servers have no offline mode.
- **Sign-in policies apply.** The account server uses the same hosted login as the console, so the policies enforced there apply to it. The end-user server uses your identity provider, so your policies apply there.
- **Membership is checked per request.** A removed member cannot make another account call, even with an unexpired token. Removing a member also ends every account MCP session that person holds.

### Authorization uses server-side records

The access token establishes identity and nothing else. For each call past.dev evaluates the caller's current organization, platform role, project reach and audiences.

Permission claims inside a token cannot widen access, because the server does not read them. A client or a prompt can call only the tools exposed for the caller's current server-side permissions.

### Tenant isolation

The organization is derived from the caller's record. Organization and user identifiers are **not tool parameters**, so a prompt cannot redirect a call to another organization through one of these fields. On the end-user server the project comes from the handle in the address, and the identity comes from the token. Nothing on the token, the link or the client widens what that identity sees.

Inside your own organization, the same rules the console enforces apply again at every tool:

- Results are filtered to the caller's current visibility before they are returned.
- Writes run the same validation and authorization as the console action they mirror.
- Record identifiers are opaque and cannot be enumerated as a sequence.

### Transport and infrastructure

- HTTPS only, HTTP/2, behind Cloudflare edge protection.
- Session identifiers returned to clients are opaque and validated by the service.
- An authentication failure never echoes the submitted token, and a refusal names nothing about the account.

### Data sent to the AI client

> **External data flow**
>
> **The assistant's model receives tool results.** Anything a tool returns can be sent to the AI client and to its model provider. On the account server that is account administration data. On the end-user server it is the memory that identity may see.
>
> Include this flow in your data map, and review the provider's data-handling terms. You select and contract with that provider separately from past.dev.