ICP MCP Privacy Policy
-Effective date: August 28, 2026
- -We, DFINITY Stiftung, Genferstrasse 11, 8002 Zürich, Switzerland -("DFINITY Foundation") disclose in this ICP MCP Privacy Policy ("Privacy -Policy") how we process personal data in connection with the ICP MCP server -(the "Service"), which lets an AI assistant interact with the Internet -Computer and its ecosystem of applications on your behalf.
- -This Privacy Policy covers the Service at
-mcp.internetcomputer.org, together with any pre-release
-deployments of the same software that we operate.
It covers both authenticated use, where you have signed in with Internet -Identity, and unauthenticated use: browsing the Service's public pages or -using the tools that read public network information generates requests and -technical logs even when you never sign in.
- -This Privacy Policy does not apply to other data processing, including: -processing by your AI assistant's provider (for example, Anthropic for -Claude), under its own terms and privacy policy; processing by Internet -Identity, which is covered by the -Internet -Identity Privacy Policy; and processing by the applications you choose to -interact with through the Service, which are operated by third parties under -their own policies.
- -How signing in works, and what the Service holds
- -The Internet Computer is a public network that runs applications reliably -using a consensus protocol. The Service lets an AI assistant read public -information from it without any sign-in.
- -For an assistant to act on your behalf, you sign in once with Internet -Identity. Your long-term credentials are never sent to the -Service. Passkey private keys remain with your authenticator, -recovery material remains with you, and linked-account credentials remain -with their respective providers; none of them are entered into the chat or -shared with the Service.
- -What the Service does hold, once you approve a connection, is a -delegated session signing key that the Service generates -itself, inside the server. No secret key crosses a network in either -direction: your credentials stay where they already live, and the Service's -key never leaves the Service. What travels is only the key's public half, -which Internet Identity signs, issuing a time-limited, scope-limited -authorization for that key to act as you. The Service uses the session key -with Internet Identity to obtain, for each application you interact with, a -further short-lived authorization and per-application key (the connection -material described in section 1), and those per-application keys are what -actually sign your requests. All of these are signing credentials the -Service generated itself, so it is worth being precise about their limits: -none of them is your Internet Identity key, none can be used to sign in as -you anywhere else, and revoking the connection stops them in the two steps -described in section 7. Separately, your AI assistant holds an OAuth access -token that lets it reach the Service; that token's lifetime is capped by the -same authorization.
- -On the Internet Identity consent screen you make two explicit choices: how -long the connection lasts (from 10 minutes up to 30 days), and its access -level:
- --
-
- "Questions only" lets the assistant read. Read access is -not the same as harmless: acting as you, the Service can retrieve data that -applications show only to you, including account balances, holdings, and -activity history, and those results are returned to your assistant. What this -level prevents is changing anything. -
- "Actions & questions" additionally lets the assistant -submit actions that change state. -
For a "Questions only" connection, the Internet Computer network itself -rejects action requests; the restriction does not depend on the Service -alone.
- -The authorization is not restricted to particular -applications. Whichever level you choose applies to any application -your assistant is directed to: the Service derives a per-application identity -on demand for whichever application is named at the time. Combined with a -duration of up to 30 days, that is a broad credential, so choose the shortest -duration that suits your task, and revoke connections you are no longer using -at id.ai/manage/settings.
- -The Service does not profile individual users, does not use advertising, -and does not use tracking cookies. It sets one transient, security-purpose -cookie during sign-in, described below.
- -1. Data Categories Processed, Purposes, and Legal Bases
- -We process the following categories, solely to provide, secure, and improve -the Service.
- -Session and authorization data: the delegated session
-signing key and the session duration and access level you chose. Purpose:
-performing the requests your assistant makes. Legal basis: performance of the
-service you requested. During sign-in the Service also sets one transient cookie
-(mcp_connect; HttpOnly, Secure, SameSite=Lax), set and read by the
-server only and not accessible to scripts in web pages. It binds the sign-in
-to the browser that started it, protecting you against session-fixation
-attacks, and is not used for tracking. Legal basis: our legitimate interest in
-securing the sign-in, and it is strictly necessary for a function you
-requested.
Requests and their results: the requests your assistant -makes (application and canister identifiers, method names, query and call -arguments) and the results returned for them. Both can -contain arbitrary personal data: your own, and data about third parties held -by the applications you query. Depending on what you ask for, results may -include account names and numbers, balances and holdings, activity and -timestamps, identifiers, web addresses, and application-specific records. The -Service encodes, signs, forwards, and returns this data; it processes it -transiently to execute each call and does not store it after the call -completes, with one exception, the per-application connection material -described below. It does not store conversation content. Legal basis: -performance of the service you requested.
- -Account information: when your assistant uses tools that -list your Internet Identity accounts at an application, or that ask which -identity you use there, the Service processes those account names, numbers, -and last-used timestamps, and the per-application identity in question. A -per-application identity is a pseudonym specific to that application; -depending on how you use that application, you may consider it private. Not -stored after the session; the account number and application used for an -authenticated call are kept during the session as part of the connection -material described next. Legal basis: performance of the service you -requested.
- -Per-application connection material: the first time your -assistant acts at a given application, the Service derives the identity you -use there and keeps, for the remainder of the session: the application's -domain, the account number used, the per-application key it generated, and -Internet Identity's signed authorization for that application (itself valid -for at most one hour). Keeping this avoids re-deriving an authorization on -every call to the same application. All of this is -held in memory only, bounded in size, and discarded when the session ends or -the Service restarts. Legal basis: performance of the service you -requested.
- -Connection (OAuth) data: when an assistant connects, the -Service stores its registration: a generated client identifier, the -assistant's redirect address, and a last-used timestamp, plus short-lived -authorization codes and access tokens. A registration describes assistant -software rather than you, but we treat it as pseudonymous personal data, -because a redirect address can identify an organisation, a deployment, or a -device. Legal basis: performance of the service you requested.
- -Technical logs: see section 5 for exactly what these -contain. Purposes: operating, securing, and debugging the Service, and abuse -prevention. Legal basis: our legitimate interest in keeping the Service -available, secure, and free of abuse.
- -Aggregated operational metrics: counts such as how many -connections are active and how often errors occur. These are aggregates and do -not identify individual users. Purpose: operating and improving the Service. -Legal basis: our legitimate interest in understanding and improving how the -Service performs.
- -2. Who Receives Data
- -Using the Service necessarily sends data to others. In order of how -directly each one is involved:
- -Your AI assistant, and its provider. Everything the -Service returns goes back to the assistant that asked for it. That includes -results you requested that contain private, account-specific data, your -account names, and your per-application identities. Your assistant's provider -(for example, Anthropic for Claude) processes that data under its own terms -and privacy policy, not this one. This is inherent to using an AI assistant as -the interface.
- -The Internet Computer network. Your requests are executed
-by the network's nodes, which are operated by independent node providers in a
-number of countries, and reach it through public API boundary nodes
-(icp-api.io). Internet Identity (id.ai)
-authenticates you. These are part of the Internet Computer and are governed by
-its DAO, the Network Nervous System, rather than operated by DFINITY
-Foundation.
The applications you choose. A question or action you -direct at an application carries your request and your per-application -identity to that application and its operator, who may be anyone. What an -application records, retains, or publishes is governed by that application, -not by this Privacy Policy, and may be publicly accessible. Actions that -change state become part of that application's state on a public network.
- -Websites you ask the Service to look up. When you ask it -to find the application behind a web address, the Service fetches metadata -from that address, which discloses the request to whoever runs that site.
- -A service DFINITY Foundation operates: the public
-canister-metadata service at dashboard.internetcomputer.org.
Our hosting provider. The Service runs on servers we rent -from Amazon Web Services, which processes data on our behalf as a processor -under its data-processing terms. We use no other infrastructure processors -today; if an observability or error-reporting provider is ever introduced, it -will be named here first.
- -Public authorities, where the law requires it. If we are -legally obliged to disclose personal data, for example by a court order or a -binding request from a competent authority, we disclose the minimum -required.
- -We do not sell personal data or disclose it for advertising. We disclose -it only to the recipients described above, as necessary to perform your -requests, secure the Service, or comply with law.
- -3. International Transfers
- -The Service's servers, and the technical logs they hold, are located in -Germany (Amazon Web Services' Frankfurt region). Germany is a -member of the European Economic Area, whose countries are recognised by the -Swiss Federal Council as providing adequate data protection, so no additional -transfer safeguard is required for this hosting. Amazon Web Services may have -limited remote access from other countries for support and operations; that -access is governed by the AWS Data Processing Addendum, which incorporates -the EU Standard Contractual Clauses, as extended to Swiss transfers in line -with the FDPIC's guidance, for any processing from a country without an -adequate level of data protection.
- -Separately, the Internet Computer is a global public network: its nodes -are operated by independent providers in many countries, whose locations are -set by the network's governance, not by us, and can include countries that -Switzerland and the EEA do not recognise as providing adequate data -protection. When you direct the Service to read from or act on an -application, the Service submits that request to the network deliberately, -on your instruction, and the network processes it internationally to execute -what you asked. What travels is the content of your request and its results -(section 1). Authenticated requests also carry the pseudonymous -per-application identifier described in section 6; unauthenticated public -reads use the Internet Computer's shared anonymous principal, which -identifies no one. This processing is inherent to the network's design and -applies to every request, so take it into account when deciding which -applications to direct the Service at.
- -4. Data Retention
- -| Category | Retained |
|---|---|
| Session and authorization data (signing key, access level, -duration) | In volatile memory only, never written to disk. Discarded -when the duration you chose elapses (at most 30 days) or when the Service -restarts, whichever comes first. |
| Requests and results | Processed transiently; not retained -after the call completes. |
| Per-application connection material (application domain, account -number, per-application key, signed authorization) | In memory, per -session; an entry is replaced when refreshed and all are discarded when the -session ends or the Service restarts. The signed authorization itself expires -at most one hour after issue. |
| Authorization codes and access tokens | In memory only; codes -expire after two minutes, tokens no later than the session duration you -chose. |
| Connection (OAuth) registrations | Stored on disk so an -assistant can reconnect across restarts. There is currently no time -limit: a registration is kept until it is displaced once the store -reaches its cap of 10,000, which for a rarely-used deployment can mean -indefinitely. |
| Technical logs | Up to three months, then deleted. |
| Aggregated operational metrics | Held in memory only, never -written to disk: gauges are computed on demand, and the status dashboard -keeps its most recent health report in memory until the next one replaces it -or the process restarts. |
Revoking a connection takes effect in the two steps described in section -7. Revocation does not by itself erase the session record: the delegated -signing key and the per-application connection material stay in memory until -the duration you originally chose elapses or the Service restarts. We intend -to discard them as soon as a revocation is observed; until that ships, the -table above describes the actual behaviour.
- -5. What Our Logs Contain
- -We would rather be specific than make sweeping promises, so:
- --
-
- Every request that reaches the Service's application produces one log
-line with the HTTP method, the path, the response status, and how long it
-took. Query strings and request bodies are never included, which keeps
-single-use codes and delegations out of these logs. Requests to the status
-dashboard (
/status/) bypass the application and produce no -routine log line at all.
- - Sign-in and session events log the session identifier, a per-connection -identifier derived from that connection's key, the access level, and expiry -times. The per-connection identifier is new for every connection, so log -entries from different sessions cannot be linked to each other through -it. -
- No log line records the applications or canisters you interact -with, the arguments you send, or the results you receive. The parts -of the Service that perform tool calls do no logging at all. -
- Our web server is configured without access logging, so client IP -addresses and browser user agents are not recorded as a matter of course. -They are unavoidably processed in transit in order to serve a request, and -its diagnostics for failed requests can include connection details and the -requested address, including any query string, when something goes -wrong. -
- Logs are held by the operating system's journal on our hosts, subject to -the retention bound above. -
6. Identifiers, and What They Could Link
- -Internet Identity gives each application a different identity for you, so -applications cannot recognise you across applications. The Service is a -participant in that design and we want to be plain about what it can see. -While a session is live it holds, in memory, the per-application identities -it has derived for you. Internet Identity derives the same identity each time -for a given application and account, so software holding one of them could in -principle tell that two separate sessions visiting that application belong to -the same user. Three things limit what the Service could link -in practice: none of these identifiers is written to -logs, which carry only a per-connection identifier that is new for every -connection (section 5); the applications you visit are not written to logs -either; and nothing the Service discloses to an application lets that -application recognise you anywhere else.
- -7. Your Rights
- -Subject to the conditions in applicable law, you have the right to -access the personal data we hold about you, to have -inaccurate data rectified, to have data -erased, to restrict or object -to processing (including processing based on our legitimate -interests), and to receive data you provided in a portable form. To exercise -any of these, email mcp@dfinity.org.
- -You can also act directly, without contacting us:
- --
-
- Disconnect the connector in your assistant. This stops -that assistant using the connection, but does not by itself end the underlying -authorization. -
- Revoke the authorization at -id.ai/manage/settings, which lists -every active connection for your Internet Identity so you can review and -revoke access even if you no longer remember which assistant sessions are -active. Revocation is carried out by Internet Identity and takes effect in -two steps: within at most five minutes, Internet Identity stops honouring the -connection, so the Service can no longer obtain authorizations for any -application; authorizations already issued for particular applications remain -usable until they expire, at most one hour after they were issued. The -practical worst case between revoking and all activity stopping is therefore -about one hour. -
If you believe we have handled your personal data unlawfully, you may lodge -a complaint with the Swiss Federal Data Protection and Information -Commissioner (FDPIC), and, where the GDPR applies to you, with the supervisory -authority of your EU or EEA country of residence or workplace.
- -Data you have submitted to applications on the Internet Computer through -your own requests is held by those applications, not by the Service; requests -about it should be directed to the relevant application operator.
- -8. Changes to This Policy
- -We may update this Privacy Policy. When we do, we will change the effective -date at the top of this page. For changes that materially affect how we use -your data or what an authorization permits, we will give reasonable advance -notice before the change takes effect, and will not apply them retroactively -to data already collected.
- -9. Contact
- -For questions about this Privacy Policy or the Service, or to exercise any -of the rights in section 7, email -mcp@dfinity.org.
-