Skip to content
Neural networks and AI3 minOctober 22, 2026

MCP security: deciding what AI may access

Robert MirovUpdated Oct 22, 2026

MCP security: deciding what AI may access

An instruction saying do not change anything is not an access-control system. Before connecting company information, define which people may see each record, what actions are permitted and how access can be revoked.

01Create a permission matrix

List sources, allowed fields and read/write actions by role. A salesperson might access assigned enquiries, a manager the department, and an administrator the connection settings. Enforce permissions server-side on each action. Knowing a record ID or possessing its link must not grant extra rights.

02Separate reading and writing

Begin with the reading operations needed for the pilot. Price updates, deletion, sending messages and bulk exports require separate decisions. Before a write, show the object and intended change, then check permissions and current state. Human approval adds oversight but cannot replace technical restrictions.

03Keep credentials outside conversations

Store keys and tokens in the intended protected secret store, not assistant instructions, response logs or repositories. Use the minimum rights required. Consider individual authentication where supported. When staff leave or a connection is transferred, check revoked rights and remaining sessions.

04Treat outside text as data

A document or task can contain a request to export the database to an external link. Such content must not authorise an action. Limit sources, tools and recipients within the system. Convincing tool descriptions do not establish that a server is trustworthy.

05Log enough to investigate

Record the user, action, time, object ID, outcome and error. Protect logs too; avoid indiscriminately storing full conversations or secrets. Important updates should be traceable to source records. Define retention and ownership for investigating failures.

06Test before granting access

Attempt another user's record, a forbidden field update, repeated execution and access after revocation. Check that upstream errors do not reveal restricted details. Provide an off switch and credential-replacement procedure. These measures reduce risk; they do not promise absolute security.

07Official sources and example boundaries

Platform capabilities were checked against documentation on 22 October 2026. Interfaces, availability and permissions depend on the account and organisation settings. Workflow examples are illustrations, not client case results. Official documentation: MCP security

Summary

For UZNEO AI integration, access and checks are agreed before launch. Compare standard and custom MCP when choosing the implementation.

Need help with a project?

Tell us about your task — we'll suggest a solution and price

Frequently asked questions

Should we provide an administrator password?

Prefer a separate integration identity with minimum permissions. A password pasted into a conversation is unsuitable for access segregation.

Is approving actions in chat enough?

No. The server must still verify the user, object and permitted fields.

Is read-only access harmless?

No. Reading can disclose confidential or personal information, so it also needs restrictions.

How do we disable the assistant?

Revoke access in the source and connection, then check tokens and sessions. The steps depend on the authentication design.