---
title: "Security"
description: "The short version: no long-lived secrets exist to be leaked, authorization is never taken on trust from a token, and a workspace is never a parameter your assistant can change."
canonical: https://past.dev/docs/mcp/security
last-updated: 2026-08-26
---
# Security

> The short version: no long-lived secrets exist to be leaked, authorization is never taken on trust from a token, and a workspace is never a parameter your assistant can change.

Product: past.dev MCP Server. Source: https://past.dev/docs/mcp/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 past.dev 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 past.dev itself.
- **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 past.dev 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 past.dev'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 past.dev app enforces apply again at every tool:

- Knowledge-graph results are filtered to your visibility before they are returned.
- Memories are private to you.
- 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.

### 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 past.dev 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

One honest caveat, not specific to past.dev but worth stating:

> **Inherent to MCP**
>
> **Whatever a tool returns, the assistant's model sees.** Connecting past.dev means workspace knowledge and personal memories can flow into your AI client and its provider. That's the point of the integration, but it's a real data flow, and it should appear in your own data map. Choose an AI client whose data handling you're comfortable with.