Примерно год честный ответ на вопрос «безопасно ли подключать AI-ассистента к моим заметкам?» звучал так: подключение их только читает. Так работало большинство MCP-серверов для заметок со встреч, и вопрос о безопасности решался легко: инструмент, который ничего не меняет, не может изменить не то.
Интересный вопрос теперь не в этом. Ассистенты расставляют теги, переименовывают спикеров, перезапускают распознавание и публикуют заметки в общие каналы — и полезная версия вопроса звучит точнее: что должно быть верно, прежде чем вы дадите модели менять ваши данные? Четыре вещи, и ни одна из них — не «вендор обещал быть аккуратным»: клиент спрашивает перед вызовом, изменение достаточно узкое, чтобы описать его одной фразой, необратимые изменения помечены как необратимые, и есть журнал, который можно потом прочитать.
Статья о том, где проходит эта граница. Если сам протокол для вас в новинку, начните с материала что такое MCP-сервер.
«Право на запись» — одна фраза для трёх совершенно разных вещей, и именно смешение делает тему страшнее, чем она есть.
Разметка. Теги, названия, имена спикеров. Это метаданные рядом с записью: они добавляются или заменяются. Если ассистент отметил не ту встречу, вы открываете приложение и снимаете тег. Худший случай — прибраться за перестаравшейся моделью.
Замена содержимого. Повторное распознавание записи даёт новый текст и удаляет прежний — вместе с правками, которые вы вносили руками. С машины ничего не ушло, но то, чем вы владели, пропало. Здесь «обратимо» тихо перестаёт быть правдой.
Выход за пределы машины. Публикация записи в командный канал, отправка транскрипта почтой, выдача доступа. Тут меняются не столько данные, сколько круг тех, кто их видел. Отмена — техническая операция над социальным фактом, и она не работает.
Модель безопасности, которая считает эти три случая одной настройкой, ошибётся в обе стороны: слишком назойливо для первого, слишком свободно для третьего.
У MCP есть словарь для этого. В описании инструмента бывают аннотации:
readOnlyHint (инструмент только читает), destructiveHint (может перезаписать,
а не дополнить), idempotentHint (второй вызов ничего не добавит) и
openWorldHint (обращается к внешним системам). Сервер, который публикует
инструмент для отправки данных наружу без openWorldHint, описывает себя
неверно.
Насколько этот словарь ценен, решают две фразы из спецификации. Первая — об обязанности клиента: «ради доверия и безопасности в цепочке ВСЕГДА ДОЛЖЕН быть человек, способный запретить вызов инструмента». Вторая — о самих аннотациях: клиенты «ОБЯЗАНЫ считать аннотации инструментов недоверенными, если те приходят не от доверенных серверов».
Вместе они закрывают вопрос об устройстве. Аннотации — способ сервера объявить риск, а не замок, который сервер может закрыть. Ворота стоят на стороне клиента, и окно подтверждения перед запуском инструмента — решение вашего клиента, принятое с оглядкой на объявление сервера. Claude Code, например, по умолчанию спрашивает про MCP-инструменты, а про собственные встроенные — нет.
Практическое следствие неприятно, и его стоит назвать прямо: вы решаете что-либо ровно один раз — в тот момент, когда выдаёте постоянное разрешение. После «всегда разрешать» диалог перестаёт быть средством контроля. Выдавайте разрешение по инструментам, а не по серверу: поиск каждый час — нормально, публикация каждый час — нет.
Полезная ось — не «чтение против записи». Полезная ось — во что обойдётся ошибка.
| Действие | Отмена | Почему |
|---|---|---|
| Добавить или снять тег | Да, в приложении | Метаданные рядом с записью |
| Переименовать запись или спикера | Да, в приложении | Это ярлык, а не содержимое |
| Перезапустить распознавание | Нет | Текст заменяется вместе с ручными правками |
| Опубликовать в командный канал | Нет | Коллеги могли уже прочитать |
| Отправить транскрипт почтой | Нет | У получателей остаётся то, что пришло |
Всё из трёх нижних строк заслуживает явного подтверждения каждый раз; всё из двух верхних, скорее всего, нет. Список инструментов — то место, где вендор сообщает, что из этого у него есть, и его стоит прочитать до того, как что-то подключать.
Подтверждения обесцениваются. Одна исследовательская задача способна выдать их десятками, в том числе для инструментов, которые вообще ничего не меняют, и задокументированный итог таков: люди отключают запросы целиком, а не читают следующий. Средство контроля, которое приучает себя закрывать, средством контроля не является.
Журнал не обесценивается: его читают постфактум и только тогда, когда возник вопрос. Рекомендации спецификации клиентам включают ведение журнала вызовов для аудита, и та же логика верна для сервера: если ассистент может что-то менять, вы должны потом увидеть, что именно он изменил, когда и в какой записи.
Полезная проверка любой MCP-интеграции с правом на запись: если ночью модель сделала что-то неожиданное, где я прочитаю об этом сегодня? Если ответ — «нигде», значит, всю модель безопасности в одиночку тянуло окно подтверждения.
Остановить ассистента можно двумя способами, и они не взаимозаменяемы.
По клиенту, в конфиге этого клиента. Сервер, запущенный в режиме только для
чтения, публикует лишь читающие инструменты. Отличие от отказа в вызове не
косметическое: инструмент, которого модель не видит, она и не предложит, — вы
никогда не получите «сейчас опубликую это в командный канал», а следом ошибку.
В Speak-Y это флаг --read-only в args сервера, и с ним остаётся шесть
читающих инструментов.
Глобально, в приложении. Один выключатель сразу для всех подключённых клиентов, независимо от того, кто из них обратился.
Различие важно, потому что флаг в конфигурационном файле Cursor ограничивает Cursor и больше никого. Флаг на стороне клиента говорит «Cursor может только читать, Claude Code может всё»; и только выключатель в приложении — утверждение обо всех сразу.
Speak-Y намеренно разводит две половины, и это видно снаружи.
Чтение локальное и не требует запущенного приложения. Поиск, транскрипты, саммари, задачи и теги берутся из библиотеки на вашем Mac, которую отдельный процесс открывает только на чтение; приложение при этом запускать не нужно. Ничего никуда не загружается ради того, чтобы ассистент это прочитал, — хотя, как и с любым MCP-сервером, всё прочитанное уходит провайдеру вашей модели в составе разговора, а это отдельный вопрос, не связанный с тем, где хранятся данные.
Изменения идут через запущенное приложение. Теги, переименование, повторное распознавание и публикация в командный канал выполняются тем же кодом, что стоит за кнопками интерфейса, а не второй реализацией со своим представлением о правилах. Если приложение не запущено, эти инструменты так и сообщают, а не работают наполовину.
Каждое действие объявлено и записано. Меняющие инструменты публикуются с
readOnlyHint: false; повторное распознавание и публикация в канал несут ещё и
destructiveHint, а публикация — openWorldHint, потому что это единственное
действие, выходящее за пределы машины. Последние 50 действий перечислены в
разделе Настройки → Интеграции: время, операция, запись и результат — без
текста транскрипта, который иначе пережил бы саму запись. Выключатель действий
ассистента — на том же экране, а сервер доступен на любом тарифе.
Проверено 13 августа 2026 года по документации самих вендоров:
Список Fireflies тут самый показательный, потому что «отправь этот транскрипт на такие-то адреса» — ровно тот класс действий, где подтверждение в клиенте остаётся единственным, что стоит между неверно понятой инструкцией и получателем. Это не упрёк функции: перечислить её в списке инструментов — честный способ её выпустить. Это довод за то, чтобы читать список до того, как выдавать постоянное разрешение целому серверу.
Ничего из этого не требует верить в намерения вендора — в этом и смысл. У вопроса «безопасно ли позволять ассистенту менять мои данные?» нет общего ответа, но он раскладывается на вопросы, у которых ответ есть: что меняется, кто подтверждает, что обратимо и где это записано.
Если ассистента вы ещё не подключали, практичнее всего начать с материала как подключить заметки со встреч по MCP: там разобраны настройка и первые запросы — до того, как всё сказанное выше станет актуальным.
Безопаснее в одном узком смысле: инструмент, который ничего не меняет, не может изменить не то. Но «только чтение» — грубое средство, а не модель безопасности. На деле защищает другое: понимание, какие изменения обратимы, подтверждение в клиенте перед необратимыми и возможность потом прочитать, что было сделано. Сервер только на чтение даёт первое свойство ценой самой функции.
Это свойство вашего клиента, а не сервера. Спецификация MCP говорит, что в цепочке всегда должен быть человек, способный запретить вызов инструмента, и клиенты вроде Claude Code по умолчанию спрашивают про MCP-инструменты. Сервер может объявить инструмент меняющим или разрушающим через аннотации, но спецификация требует от клиентов считать эти аннотации недоверенными, если сервер не доверенный, — так что они влияют на подсказку, а не принуждают.
Окно подтверждения перестаёт быть средством контроля для этого инструмента, и все следующие вызовы проходят без вопросов. Для поиска это разумный размен, для инструмента, который делится данными с другими людьми, — плохой. Выдавайте постоянное разрешение по инструментам, а не по серверу, и считайте журнал действий тем, что отвечает на вопрос, что произошло на самом деле.
Да, если сервер поддерживает режим только для чтения, задаваемый в конфигурации самого клиента. В Speak-Y он есть: флаг --read-only в args в MCP-конфиге клиента публикует для него только читающие инструменты, поэтому Cursor можно ограничить чтением, а Claude Code оставить полный доступ. Выключатель внутри приложения, наоборот, действует сразу на всех клиентов.
Два класса. Повторное распознавание заменяет текущий текст записи, включая правки, внесённые руками. Публикация записи в командный канал делает её видимой коллегам, и удаление постфактум не отменяет прочтения. Теги, названия и имена спикеров — это ярлыки, их можно вернуть обратно в приложении.