---
title: "Privacy and compliance"
description: "The MCP servers use the same security and privacy controls as the rest of past.dev."
canonical: https://past.dev/docs/mcp/privacy-compliance
last-updated: 2026-10-09
---
# Privacy and compliance

> The MCP servers use the same security and privacy controls as the rest of past.dev.

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** | Independent audit of control operation over a defined review period. |

Neither server adds a data store, an identity system or a permission model. Both use the same database, access rules, infrastructure and audit scope as the rest of past.dev.

### What a reviewer usually asks

| Question | Answer |
| --- | --- |
| Does it create a new data store? | No. Reads and writes go to the existing organization data. |
| Are there standing credentials? | No. OAuth 2.1 with short-lived tokens. The one exception is an end-user access link for an agent, which section 04 states plainly. |
| Can it cross tenants? | No. The organization comes from the caller's record and the project from the handle in the address. Neither is a tool parameter. |
| How is access revoked? | For a member, remove the membership: it is verified per request and also ends their MCP sessions. For one of your users, change the trait the access rule reads or revoke their link. See section 7. |
| Can an admin disable it? | The end-user server, yes, per project, from Build › MCP server. The account server is on for every organization, and each member reaches only what their role reaches. |
| Does our SSO apply? | For your own users, yes: they sign in at your identity provider and past.dev never holds their password. For members, the account server uses the same hosted login as the console. |
| Is access least-privilege? | Yes. Per-tool scopes, role-derived, filtered per request, fail-closed, with project reach resolved on every call. |
| Is there an audit log? | Every account tool call is recorded in the organization's request log and shown on Settings › MCP, including refusals. Section 7 covers what an administrator sees. |
| 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. The AI client and its model provider receive tool results. You select and contract with that provider separately from past.dev. |

### Data minimisation in the tools themselves

On the end-user server, an identity's audiences decide what `recall` and `answer` can return, and `remember` writes only to that identity's private audience. If you call the Memory API from your own MCP server instead:

- Return only the data your application needs from the authorized recall page.
- Derive the recall identity from your authenticated user, rather than letting the model choose it.
- Keep project keys on your server and select them according to your own access policy.

> **For your security team**
>
> Request current certificate numbers, audit periods, auditor details and the subprocessor list from the past.dev trust center or your past.dev contact. Certificate details change with each audit cycle.