---
title: "Privacy and compliance"
description: "The MCP server is part of the past.dev platform and sits inside the same certified information security and privacy management systems. It is not a side channel around them."
canonical: https://past.dev/docs/mcp/privacy-compliance
last-updated: 2026-08-26
---
# Privacy and compliance

> The MCP server is part of the past.dev platform and sits inside the same certified information security and privacy management systems. It is not a side channel around them.

Product: past.dev MCP Server. Source: https://past.dev/docs/mcp/privacy-compliance

| Certification | What it covers |
| --- | --- |
| **ISO/IEC 27001** | Information security management. Independently certified controls covering access control, cryptography, secure development, supplier management, logging and incident response. |
| **ISO/IEC 27701** | Privacy information management, extending 27001. Covers how personal data is processed, minimised, retained and handled when a data subject exercises their rights. |
| **SOC 2 Type II** | Independently audited controls tested *over a period of time*, not just at a point in time: evidence that the controls described here operated consistently. |

The MCP server introduces no new data store, no new identity system and no new permission model. It is a protocol surface over the platform you have already assessed: the same database, the same identity provider, the same access rules, the same infrastructure and the same audit scope.

### What a reviewer usually asks

| Question | Answer |
| --- | --- |
| Does it create a new data store? | No. Reads and writes go to the existing past.dev workspace data. |
| Are there standing credentials? | No. OAuth 2.1, short-lived tokens, no API keys. |
| Can it cross tenants? | Not for customers. The workspace is derived server-side and is not a parameter. |
| How is access revoked? | Remove the workspace membership, verified per request, so effective at the next call. IdP deactivation blocks sign-in and refresh but not an already-issued token. See section 6. |
| Can an admin disable it? | Not yet, workspace-wide. See section 6 for the full control inventory and compensating controls. |
| Does our SSO apply? | Yes. MCP uses the same hosted login as the app, so an SSO-configured workspace authenticates through its own IdP. |
| Is access least-privilege? | Yes. Per-tool permissions, role-derived, filtered per request, fail-closed. |
| Is there an exportable audit log? | Not per workspace today. Activity is captured in past.dev's internal logging within the certified audit scope. See section 6. |
| Data residency and subprocessors | Same as the past.dev platform. Request the current subprocessor list and DPA from past.dev. |
| Does data leave to a third party? | Yes, by design: your AI client and its model provider receive whatever the tools return. That provider is *your* choice and your relationship, not past.dev's. |

### Data minimisation in the tools themselves

Beyond policy, the tools are built to hand back less rather than more:

- Knowledge-graph results carry only recorded relationships, so an assistant can't present an inferred connection as fact.
- Knowledge-graph answers return matched snippets with their sources, not whole documents; each result is filtered to the caller's visibility before it leaves the server.
- Memories are returned only to the person they belong to; there is no tool that reads someone else's.

> **For your security team**
>
> The certification numbers, audit period, auditor and current subprocessor list should come from past.dev's trust centre rather than this page. Ask your past.dev contact for the current pack. Everything above describes engineering controls, which are stable; certificate details change with each audit cycle.