Skip to main content

MCP Client Access and Controls

Connecting an AI client through MCP lets that client request Files.com operations on your behalf, including reading or changing data within your permissions. Before approving a connection, choose an account or API key with the access the client needs and identify how you will end that access. Remote and Local MCP support different authentication methods and controls.

Credentials and Permissions

Authentication methodSupported serversCredential and access
Sign In with Files.comRemote MCPBrowser sign-in and approval issue a bearer token representing an ordinary Files.com login session. The client acts as the signed-in user.
API KeyRemote and Local MCPThe client uses the API key you supply. Access is limited by the key's scope and the permissions of its associated user, if it is a user key.

MCP does not add a separate AI permission model. Signing in as a Site Administrator gives the client administrator access; using a more restricted account limits the operations it can perform. Prompts and instructions to the AI do not replace Files.com permissions. The MCP Access Permissions page explains the permission checks for each method.

A dedicated API key lets you restrict or revoke one client's access without interrupting other integrations. Site-wide keys belong to the site, so disabling the administrator who created one does not revoke it. User keys depend on their associated user remaining enabled. See API key scopes and expiration.

Client Registration and Approval

Sign In with Files.com supports Client ID Metadata Documents (CIMD) and Dynamic Client Registration (DCR). CIMD identifies a client by an HTTPS metadata URL. Files.com reads the application's name and redirect addresses from that document, giving you a domain to inspect during approval. DCR lets a client submit those details when it requests a client ID; the submitted name does not verify who publishes the application.

The MCP Dynamic Client Registration setting is off by default. Enable it only for clients that require DCR. Leaving it off avoids enabling an additional registration method when your clients support CIMD. The setting governs registration for new DCR connections. It does not restrict CIMD clients or API-key connections, select an approved list of applications, or disconnect clients already authorized through DCR.

Registration alone does not authorize access. The browser sign-in flow includes a warning page showing the application name, the Files.com MCP resource, the redirect destination, and, for CIMD, the client's metadata domain. These details help you check that the request belongs to the connection you initiated. The page warns that Files.com has not verified the application. A displayed name or recognizable domain does not establish that the client is suitable for your data or that its actions will match your intent. Decline a request you did not initiate or do not recognize.

Session Lifetime and Access Removal

A Sign In with Files.com session follows the site's Session Expiration setting and is also limited by the OAuth application's expiration. When the application has no expiration, the site's session expiration setting supplies the lifetime. Closing the client's window does not itself revoke the Files.com session.

The session becomes invalid when it times out, when the OAuth application expires or is revoked, or when all AI features are disabled for the site. Account changes that invalidate ordinary login sessions, including a Files.com password change or disabling the user, also invalidate this session. A password change ends existing login sessions; disabling the user also blocks the user's ability to authenticate again.

Files.com does not provide a control to revoke an individual OAuth grant or a list of OAuth grants in the Web App. The site's OAuth authorization-server metadata does not advertise a revocation endpoint. Account and site controls therefore have a broader effect than disconnecting one client. Use a dedicated API key when you need a credential you can revoke individually.

API-key connections follow the key's own expiration and revocation rules. Changing a password does not revoke an independently issued API key. Credentials and Access Revocation explains these distinctions and the limits of ending access after a download has already been authorized.

Remote and Local Controls

Disabling all AI features for the site blocks the Remote MCP Server, including connections using an API key. It does not revoke that key or prevent its use through the ordinary Files.com API. The Local MCP Server connects through that API and is unaffected by the AI setting. To stop its Files.com access, revoke its API key or disable the associated user. The AI feature controls describe the site-wide setting.

The Local MCP Server runs on your computer or infrastructure. Its local file tools read and write with the operating-system privileges of that process. Files.com permissions limit access to your Files.com site; they do not limit which local files the process can use. Run it under an operating-system account with appropriate local access, and assess that access separately from the API key's scope.

Audit Records and External AI Clients

MCP operations use the standard Files.com audit logs and are attributed to the acting account under the usual API logging rules. There is no separate AI audit trail for MCP actions. Review Logs and Reports for Files.com activity and the client's own records for its conversation history.

An external AI client can pass file contents and tool results to its model provider. Review that client's and provider's data-handling terms before giving it access. Files.com does not control third-party AI tools or models, their actions, or their handling of data, as explained in the AI Features terms. Ending Files.com access does not retrieve data already delivered to the client.