# codenik.ru

> Безопасный доступ для ИИ-агентов к корпоративным системам.

Источник: https://codenik.ru/llms-full.txt
Сгенерировано: 2026-08-10T12:40:55.871Z

================================================================================
# Главная (https://codenik.ru/)

## codenik.ru

Безопасный доступ для ИИ-агентов к корпоративным системам.

Codenik подключает ИИ-агентов к коду, задачам, чатам и документам через управляемый слой MCP-инструментов, прав, секретов и короткого контекста.

## ИИ-агенты уже в работе

Агенты пишут код, разбирают задачи и ищут в документах. Для корпоративной работы им нужен управляемый доступ.

## Агенту нужен безопасный путь к данным

Агент сам по себе не видит код, задачи, чаты и документы. Codenik даёт путь без ручного копирования и личных токенов.

## Проблема небезопасного доступа

- Токены открыты.
- Прав слишком много.
- Настройки разные.

## Codenik как безопасный слой доступа

Схема: ИИ-агент → Codenik → ваши системы.

Codenik проверяет права, прячет секреты и ведёт журнал действий. MCP используется как стандартный разъём для инструментов.

## Что это даёт команде

- Одна команда: $ codenik connect.
- Права: только нужный доступ.
- Секреты: без локальных паролей.
- Аудит: все вызовы видны.

## Как обычно к этому приходят

Ручной копипаст → личные токены → разрозненные MCP-настройки → единый управляемый слой Codenik.

## Манифест

Агенты экономят время. Codenik делает это безопасно и сразу для всей команды.

## Под капотом

Codenik собирает внутренние инструменты, контролирует доступ и отдаёт агенту короткий контекст для следующего действия.

## Чем Codenik отличается

Codenik сравнивается с MetaMCP, LiteLLM и самостоятельной сборкой по критериям: единая точка доступа к MCP-инструментам, права, команды и аудит действий, секреты вне пользователей, меньше лишних инструментов в контексте, работа внутри компании и быстрая настройка под бизнес-процессы.

## Почему сейчас

Правила доступа проще задать до хаоса. Безопасность дешевле встроить заранее.

Сначала нужен слой доступа, потом масштабирование агентов. Если команды начнут подключать MCP, токены и внутренние системы каждая по-своему, позднее придётся разбирать не один процесс, а десятки локальных исключений.

Агенты уже идут в рабочие системы: код, задачи, чаты и документы становятся частью агентских сценариев, а не отдельным экспериментом.

Личные токены быстро расползаются. То, что удобно на пилоте, превращается в риск, когда доступ появляется у нескольких команд.

Историю действий нельзя восстановить потом. Важно видеть, какие инструменты вызвал агент и на каких правах он получил результат.

Codenik вводит права, секреты и аудит до того, как агентский доступ станет неконтролируемой инфраструктурой.

## Пилот

Пилот на одну команду за 6-8 недель. Клиент получает рабочую версию под свои системы, сценарии команды и решение о масштабировании.

## Контакты

Телефон: +7 999 760-24-41.
Email: sales@codenik.ru.
Приложение: https://app.codenik.ru/.

================================================================================
# О проекте (https://codenik.ru/about)

codenik.ru - продукт команды Codenik. Мы строим AI-инструменты для команд разработки: автоматизация code review, MCP-инфраструктура, coding-агенты.

Миссия: снять рутину с разработчиков и оставить им то, что требует человеческого мышления - проектирование систем, коммуникацию с пользователями, креатив.

Стек: Rust, TypeScript, Solid.js, Astro, Kubernetes.

================================================================================
# Обучение (https://codenik.ru/learning)

Практический курс Codenik по внедрению AI-агентов в разработку и дизайн.

Участники изучают пять принципов AI SDLC, проектируют MCP-пайплайн, учатся управлять контекстом агента и собирают процесс от обсуждения задачи до прототипа.

Курс длится 2 месяца. Занятия проходят в группе 1 раз в неделю, продолжительность каждого занятия — 2 часа. Записи занятий и обучающая платформа остаются доступны ученику.

Курс подходит руководителям разработки, тимлидам, разработчикам, архитекторам, продуктовым дизайнерам и product-менеджерам.

Стоимость полного курса: 50 000 рублей.

================================================================================
# Блог (https://codenik.ru/blog)

Технические статьи о Codenik, AI-агентах, MCP, безопасности и автоматизации разработки.

## Как автоматизировать протоколы встреч с помощью MCP и AI-агентов (https://codenik.ru/blog/meeting-transcription-mcp-agents/)

Практическая схема: запись и транскрибация встреч, проверка решений, задачи через MCP и AI-агентов — без ручного переноса между системами.

Дата публикации: 2026-08-05
Темы: AI agents, MCP, meetings, automation

Автоматизация протоколов встреч часто заканчивается на хорошем саммари. Запись превратилась в текст, модель выделила основные мысли, участники получили письмо. Но затем менеджер всё равно вручную создаёт задачи, переносит решения в документацию, уточняет ответственных и через несколько дней напоминает о договорённостях.

Несколько часов в неделю экономит не сама транскрибация встреч, а связанный процесс: **запись → расшифровка → проверяемые решения → действия в рабочих системах**. Транскрипт даёт факты, AI-агент разбирает контекст, MCP подключает трекер, репозиторий и базу знаний, а человек подтверждает важные изменения.

Ниже — архитектура такого процесса, способ посчитать эффект без выдуманных процентов и план пилота для одного типа встреч.

## Где теряются часы после встречи

После обычного созвона работа распадается на мелкие действия:

- найти запись и дождаться расшифровки;
- перечитать заметки и восстановить контекст;
- отделить решение от идеи, вопроса или предположения;
- сформулировать задачи, назначить ответственных и сроки;
- проверить, нет ли таких задач в Jira, ClickUp или другом трекере;
- обновить проектный документ;
- отправить участникам итог и позже проверить выполнение.

Каждая операция занимает немного времени, но повторяется после планёрок, интервью, discovery-сессий, ретро и встреч с заказчиками. Особенно дорого обходится переключение между календарём, видеозвонком, документами, чатами и трекером.

Посчитать потенциал автоматизации можно на собственном календаре. Например, восемь встреч в неделю, после каждой из которых уходит 12 минут на протокол, 8 минут на задачи и 5 минут на рассылку итогов, дают 200 минут ручной работы. Это **пример расчёта, а не отраслевой норматив**. Подставьте фактические значения и добавьте время на поиск потерянных договорённостей — только так получится честная оценка.

## Как устроен процесс: от записи до выполненного действия

Рабочая схема состоит из шести этапов.

1. **Запись.** Платформа встречи или отдельный сервис сохраняет аудио либо видео. Участники видят, что запись и транскрибация включены.
2. **Транскрибация.** Речь превращается в текст с временными метками и, по возможности, разделением по спикерам.
3. **Нормализация.** Система добавляет тему, список участников, ссылку на исходную запись и словарь терминов проекта.
4. **Извлечение.** AI-агент формирует кандидатов в решения, задачи, риски, открытые вопросы и изменения требований.
5. **Проверка.** Человек подтверждает неоднозначные пункты и все чувствительные действия.
6. **Исполнение через MCP.** Агент создаёт или обновляет объекты в рабочих системах и сохраняет журнал вызовов.

У Google Meet транскрипт сохраняется в Google Drive организатора и прикрепляется к событию Calendar. В Teams доступ к транскрибации управляется политиками, а материалы хранятся вместе с записью в OneDrive или SharePoint. Поэтому источником процесса может стать корпоративное хранилище, а не ещё один бот в каждом звонке. Подробности зависят от тарифа и настроек платформы: [Google Meet Help](https://support.google.com/meet/answer/12849897?hl=en), [Microsoft Teams documentation](https://learn.microsoft.com/en-us/microsoftteams/meeting-transcription-captions).

Если расшифровка строится отдельно, выбирайте формат с временными метками и разделением реплик по спикерам. Например, API транскрибации может возвращать `diarized_json` с сегментами и идентификаторами спикеров. Тогда каждое извлечённое решение можно привязать к фрагменту записи, а не просить пользователя доверять пересказу модели: [OpenAI Audio API](https://developers.openai.com/api/reference/resources/audio/subresources/transcriptions/methods/create).

## Почему одного AI-саммари недостаточно

Саммари полезно читать, но оно не является системой исполнения. У него обычно нет стабильной схемы данных, проверки дублей, прав на изменение задач и связи с первоисточником.

Для автоматизации лучше требовать от агента структурированный результат:

```json
{
  "decisions": [
    {
      "text": "Запускать пилот только для встреч discovery",
      "evidence": { "start": "00:31:18", "end": "00:31:52" },
      "confidence": "high"
    }
  ],
  "action_items": [
    {
      "title": "Подготовить схему хранения транскриптов",
      "assignee_candidate": "platform-team",
      "due_date_candidate": null,
      "evidence": { "start": "00:37:04", "end": "00:37:41" },
      "requires_confirmation": true
    }
  ],
  "open_questions": []
}
```

Важны не названия полей, а три свойства.

Во-первых, каждое утверждение связано с доказательством: временной меткой и исходным транскриптом. Во-вторых, отсутствующие данные не додумываются. Если срок не назван, поле остаётся пустым. В-третьих, агент создаёт **кандидатов**, пока человек или правило процесса не подтвердят действие.

Это защищает от распространённой ошибки: модель услышала «можно попробовать в пятницу» и превратила фразу в обещание релиза к пятнице.

## Что дают MCP и AI-агенты после транскрибации встречи

AI-агент отвечает за разбор контекста и последовательность шагов. MCP, или Model Context Protocol, даёт ему стандартный способ обнаруживать и вызывать инструменты внешних систем.

Для процесса после встречи полезен небольшой набор узких MCP tools:

- `find_issue` — найти существующую задачу по проекту и смысловому совпадению;
- `create_issue_draft` — подготовить черновик задачи без публикации;
- `add_meeting_evidence` — добавить ссылку на момент записи и фрагмент транскрипта;
- `update_project_decision` — предложить изменение журнала решений;
- `post_meeting_summary` — отправить подтверждённый итог в нужный канал;
- `get_open_actions` — проверить незакрытые договорённости перед следующей встречей.

Такой контракт лучше универсального инструмента `call_any_api`: сервер может валидировать поля, ограничивать проекты, скрывать секреты и логировать конкретное бизнес-действие. В [спецификации MCP tools](https://modelcontextprotocol.io/specification/2025-11-25/server/tools) отдельно рекомендуется сохранять человека в контуре и показывать подтверждение перед чувствительными вызовами.

Агентный сценарий становится циклом, а не одноразовой генерацией текста:

```text
получить транскрипт
→ найти решения и поручения
→ сверить их с проектным контекстом
→ найти дубли в трекере
→ показать изменения человеку
→ выполнить подтверждённые MCP-вызовы
→ сохранить ссылки и аудит
→ проверить открытые действия перед следующей встречей
```

Именно последние четыре шага превращают расшифровку в экономию времени. Без них команда просто получает ещё один документ, который нужно разбирать вручную.

## Как внедрить автоматизацию протоколов встреч за один пилот

Начните не со всех календарей компании, а с одного повторяемого сценария. Например, еженедельной продуктовой встречи, после которой стабильно появляются задачи и решения.

**Шаг 1. Зафиксируйте ожидаемый результат.** Определите, какие сущности нужны после встречи: решения, задачи, риски, вопросы, изменения требований. Для каждой сущности задайте обязательные поля и критерий подтверждения.

**Шаг 2. Выберите источник записи и транскрипта.** Проверьте, где хранится файл, кто получает доступ, есть ли спикеры и временные метки, когда материал удаляется. Не стройте весь процесс вокруг копирования текста из письма, если платформа предоставляет управляемое хранилище или API.

**Шаг 3. Добавьте контекст встречи.** Агенту нужны не все документы компании, а короткий пакет: повестка, участники, проект, открытые задачи, последние решения и словарь названий. Лишний контекст повышает стоимость обработки и количество ложных совпадений.

**Шаг 4. Разделите чтение и запись.** На первом этапе агент только читает транскрипт и проектные данные, а на выходе создаёт предпросмотр. После проверки подключите отдельные write-tools для создания задач и обновления документов.

**Шаг 5. Сделайте операции повторяемыми.** Один и тот же транскрипт может попасть в очередь дважды. Используйте стабильный `meeting_id`, проверку существующих задач и idempotency key для операций записи. Повторный запуск должен обновлять черновик или возвращать уже созданный объект, а не плодить дубли.

**Шаг 6. Измеряйте не красоту саммари, а завершение процесса.** Сравните время от конца встречи до опубликованного протокола, долю задач с подтверждённым ответственным, число ручных переносов и количество исправлений после агента.

Пилот полезен, если участники быстрее получают корректные артефакты и доверяют связи с исходной записью. Количество страниц расшифровки само по себе ничего не доказывает.

## Безопасность: запись встречи содержит больше, чем список задач

В транскрипте могут быть персональные данные, коммерческие условия, детали инцидента, пароли, названные вслух, или информация о сотрудниках. Поэтому права на запись нельзя автоматически превращать в право передавать весь текст любой модели и любому агенту.

Минимальный набор мер выглядит так:

- участники понимают, что встреча записывается и как будет использован материал;
- запись, транскрипт, саммари и задачи имеют отдельные правила хранения и доступа;
- агент получает только встречи и проекты, доступные инициатору;
- секреты трекеров и баз знаний остаются на серверной стороне;
- write-tools ограничены конкретными действиями и требуют подтверждения там, где ошибка дорога;
- журнал связывает пользователя, встречу, модель, MCP tool, параметры, результат и созданный объект;
- чувствительные фрагменты можно исключить до передачи модели;
- срок хранения исходной записи не становится бесконечным только потому, что автоматизация умеет её читать.

MCP стандартизирует вызов инструментов, но не гарантирует безопасность реализации. Официальные [MCP Security Best Practices](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices) разбирают, среди прочего, риски передачи токенов, подмены полномочий и небезопасных прокси. Права, проверка входных данных, аудит и политика хранения всё равно должны быть спроектированы отдельно.

## Где в этой схеме Codenik

Codenik не заменяет платформу видеовстреч и сервис распознавания речи. Он работает на следующем участке: между AI-агентом и корпоративными системами, куда должны попасть подтверждённые результаты встречи.

Схема выглядит так:

```text
запись и транскрипт
→ AI-агент
→ Codenik
→ Jira / ClickUp / GitLab / документы / корпоративные сервисы
```

Через Codenik команда может отдать агенту только нужные MCP-инструменты, оставить секреты на серверной стороне, применить права пользователя и сохранить аудит вызовов. Например, агент читает транскрипт и открытые задачи, готовит три новых поручения, показывает их владельцу встречи и только после подтверждения создаёт записи в трекере.

Такой слой нужен, когда пилот выходит за пределы одного человека. Локальный скрипт с личным токеном может быстро доказать идею, но плохо отвечает на вопросы: кто получит доступ к встречам, какие проекты можно изменять, где отозвать секрет, как расследовать ошибочное действие и можно ли заменить модель без пересборки всех интеграций.

Начните с одного типа встреч и одного действия — например, создание подтверждённых черновиков задач. Замерьте ручное время до пилота, сохраните ссылки на первоисточник и не расширяйте права агента раньше, чем процесс станет предсказуемым. Тогда запись встреч, транскрибация, MCP и AI-агенты складываются не в демонстрацию, а в рабочий конвейер, который может вернуть команде несколько часов в неделю.

--------------------------------------------------------------------------------

## Зачем ИИ-агентам слой доступа (https://codenik.ru/blog/agent-access-layer/)

Как безопасно дать агентам доступ к коду, задачам и документам без личных токенов на ноутбуках.

Дата публикации: 2026-06-18
Темы: AI agents, access, MCP

ИИ-агент становится полезным, когда видит рабочий контекст: код, задачи, обсуждения, документы и историю решений. Без этого он превращается в интерфейс для ручного копирования.

Проблема начинается в момент подключения. Самый быстрый путь - выдать агенту личные токены разработчика и набор локальных конфигов. На пилоте это выглядит удобно, но при масштабировании команда получает несколько рисков сразу: лишние права, секреты на рабочих машинах и отсутствие общего журнала действий.

Codenik вводит отдельный слой доступа между агентом и корпоративными системами. Агент не ходит напрямую в GitLab, Jira, ClickUp или внутренние сервисы. Он вызывает инструменты через управляемый шлюз, где можно проверить права, скрыть секреты и записать действие в аудит.

Такой слой полезен не только безопасности. Он снижает шум в контексте: агент получает ровно те инструменты и данные, которые нужны для следующего шага, а не полный набор внутренних систем.

Для пилота это означает простую цель: подключить один рабочий сценарий, проверить пользу агентов и сразу увидеть, какие правила доступа нужны перед масштабированием.

--------------------------------------------------------------------------------

## Что такое MCP и зачем он нужен (https://codenik.ru/blog/chto-takoe-mcp/)

Разбираем Model Context Protocol: как MCP подключает AI-агентов к данным, инструментам и корпоративным системам без хаоса интеграций.

Дата публикации: 2026-07-04
Темы: MCP, AI agents, security, integrations

MCP, или Model Context Protocol, нужен там, где AI-агенту уже недостаточно просто отвечать на вопросы. Агент должен читать рабочий контекст, вызывать инструменты, искать данные в корпоративных системах и выполнять действия от имени пользователя. Без стандарта каждая такая интеграция быстро превращается в набор разрозненных коннекторов, токенов, локальных конфигов и исключений.

Если объяснять коротко, MCP - это открытый протокол, который задает единый способ подключать AI-приложения к внешним системам: файлам, базам данных, API, таск-трекерам, репозиториям, внутренним знаниям и бизнес-процессам. В официальной документации MCP описывается как стандарт для соединения AI-приложений с внешними системами. На практике его часто сравнивают с универсальным портом: AI-клиент не обязан знать особенности каждой системы, а система может один раз предоставить MCP-сервер с понятными инструментами и контекстом.

Для разработчиков это снижает стоимость интеграций. Для платформенных команд - дает более управляемую архитектуру. Для бизнеса - делает AI-агентов полезнее, потому что они начинают работать не в пустом чате, а внутри реального рабочего окружения.

Но важная оговорка такая: MCP не отменяет вопросы безопасности, прав доступа и аудита. Он стандартизирует способ обмена контекстом и вызова инструментов, но не делает корпоративную эксплуатацию безопасной автоматически. Поэтому в зрелой архитектуре MCP почти всегда нужен вместе с управляемым слоем доступа.

## Что такое MCP простыми словами

Model Context Protocol - это протокол взаимодействия между AI-хостом и внешними источниками контекста. AI-хостом может быть IDE, чат-интерфейс, агентная платформа, внутренний ассистент или приложение вроде Claude, ChatGPT, Visual Studio Code, Cursor и других клиентов, которые умеют подключаться к MCP-серверам.

MCP-сервер - это отдельная программа или удаленный сервис, который говорит клиенту: вот какие данные я могу дать, вот какие действия могу выполнить, вот какие шаблоны запросов доступны. Например:

- сервер GitLab может дать агенту список merge request, прочитать diff, добавить комментарий или получить статус pipeline;
- сервер ClickUp или Jira может найти задачу, обновить статус, создать подзадачу или собрать контекст по эпикам;
- сервер базы знаний может вернуть релевантные документы, ADR, инструкции и внутренние регламенты;
- сервер аналитики может выполнить ограниченный запрос к базе и вернуть агрегированный результат;
- сервер DevOps-инструментов может показать состояние деплоя, логи job или healthcheck сервиса.

До MCP команда обычно строила такие интеграции отдельно для каждого клиента и каждой системы. Один коннектор для внутреннего чат-бота, другой для IDE, третий для агентного раннера, четвертый для автоматизации в CI. Это порождает классическую проблему "N клиентов на M инструментов": чем больше систем и AI-интерфейсов, тем быстрее растет количество интеграционного кода.

MCP меняет эту модель. Система публикует MCP-сервер, а совместимый клиент может подключиться к нему по стандартному протоколу. Конечно, в реальности все равно остаются вопросы схем, прав, UX, надежности и эксплуатации, но базовый контракт становится общим.

## Как работает MCP: host, client и server

Архитектура MCP построена вокруг трех ролей.

MCP host - это AI-приложение, в котором работает пользовательский сценарий. Например, редактор кода с агентом, корпоративный ассистент или интерфейс для выполнения задач. Host управляет подключениями, решает, какие серверы доступны, и передает модели сведения о доступных возможностях.

MCP client - компонент внутри host, который поддерживает соединение с конкретным MCP-сервером. Если приложение подключено к пяти серверам, обычно у него пять клиентских соединений, каждое со своим сервером.

MCP server - программа или сервис, который предоставляет контекст. В терминологии MCP это могут быть tools, resources и prompts.

`tools` - это исполняемые функции. Например, `get_issue`, `create_merge_request`, `search_docs`, `run_query`, `get_pipeline_logs`. Агент может вызвать tool, если host разрешил ему это сделать и пользовательский сценарий требует действия.

`resources` - это данные для чтения. Например, содержимое файла, документ из базы знаний, схема базы, описание проекта, список правил доступа или результат поиска.

`prompts` - это переиспользуемые шаблоны взаимодействия. Они помогают стандартизировать типовые сценарии: подготовить ревью, собрать release notes, проверить задачу перед разработкой, описать инцидент.

Протокол использует JSON-RPC и включает жизненный цикл соединения: инициализацию, согласование версий и возможностей, discovery доступных primitive-объектов, вызовы инструментов и уведомления об изменениях. Это важно, потому что AI-приложение не должно угадывать, какие функции существуют. Оно сначала запрашивает список возможностей, получает схемы входных параметров, а уже затем может безопаснее формировать вызовы.

## Зачем MCP нужен AI-агентам

LLM сама по себе не знает, что происходит в вашей компании прямо сейчас. Она не видит актуальные задачи, приватный код, внутренние документы, production-логи, права пользователя и историю решений. Если агенту не дать контекст, он будет либо задавать слишком много уточняющих вопросов, либо предлагать общие ответы, либо вынуждать человека вручную копировать данные в чат.

MCP нужен, чтобы убрать эту ручную склейку.

Представьте разработчика, который просит агента: "Проверь MR, найди связанную задачу, посмотри acceptance criteria и скажи, что нужно исправить". Без MCP агенту нужно вручную передать ссылку на MR, diff, описание задачи, комментарии, CI-статус и проектные правила. С MCP агент может получить эти данные через подключенные инструменты: прочитать MR в GitLab, найти задачу в ClickUp или Jira, поднять релевантные инструкции из базы знаний и вернуть конкретный план ревью.

Другой пример - platform engineering. Инженер спрашивает: "Почему деплой сервиса задержался?" Агент может обратиться к MCP-серверу CI/CD, получить pipeline, открыть логи упавшей job, найти релевантный runbook и предложить следующий шаг. Это не магия модели, а нормальная интеграция с рабочими системами через единый протокол.

Третий пример - работа с документацией. Агент может не просто отвечать по памяти, а искать по внутренним ADR, RFC, продуктовым спецификациям и инструкциям. Если сервер возвращает только релевантные фрагменты, а не весь архив документов, качество ответа растет, а риск утечки лишнего контекста снижается.

## Чем MCP отличается от обычного API

На первый взгляд MCP похож на API: есть клиент, сервер, методы и данные. Но задача у него другая.

Обычный API проектируют для конкретной системы и конкретного набора бизнес-операций. Клиент должен заранее знать endpoint, формат авторизации, структуру запросов, пагинацию, ошибки и ограничения. Это нормально для продуктовой интеграции, где разработчики контролируют обе стороны.

MCP проектируют как слой, который AI-приложение может обнаруживать и использовать динамически. Сервер не просто принимает HTTP-запросы. Он описывает свои возможности в форме, пригодной для host и модели: названия tools, человекочитаемые описания, JSON Schema для входных параметров, ресурсы для контекста, prompts для типовых сценариев.

Еще одно отличие - роль модели. В обычном API клиентское приложение явно вызывает нужный endpoint. В агентном сценарии модель может выбирать инструмент на основании цели пользователя и доступного описания. Поэтому описание tool становится частью интерфейса безопасности и качества. Плохо названный или слишком широкий tool может привести к неверным действиям, даже если технически он работает.

Поэтому MCP не заменяет внутренние API. Он обычно стоит над ними. MCP-сервер может обращаться к GitLab API, Jira API, базе данных или внутреннему сервису, но наружу для агента предоставляет более узкие и осмысленные операции.

Хороший MCP-инструмент не должен быть "выполни произвольный HTTP-запрос". Лучше дать агенту конкретную операцию: "получить задачу по ключу", "создать комментарий к MR", "найти документы по проекту", "вернуть последние ошибки деплоя". Чем уже контракт, тем проще контролировать права, логировать действия и объяснять пользователю последствия.

## Где MCP особенно полезен компаниям

MCP становится полезным не из-за моды на протоколы, а из-за повторяемых рабочих сценариев. Самые практичные случаи обычно находятся там, где AI-агенту нужны и контекст, и действие.

В разработке MCP помогает подключить репозитории, merge request, issues, CI/CD, документацию и внутренние правила. Агент может готовить code review, искать связанные задачи, объяснять failed pipeline, собирать release notes и проверять, не нарушены ли acceptance criteria.

В поддержке и customer success MCP может соединить ассистента с CRM, базой знаний, тикетами и статусом сервисов. Тогда ответ клиенту строится не на общем тексте, а на фактах: какая версия у клиента, какие инциденты открыты, какие SLA применимы, что уже пробовали.

В аналитике MCP позволяет дать агенту безопасный доступ к заранее ограниченным запросам. Вместо прямого подключения к production-базе можно опубликовать tools для типовых агрегатов, resources со схемами и prompts для корректной интерпретации метрик.

В back office MCP может связать агента с календарями, документами, задачами, согласованиями и внутренними workflow. Но здесь особенно важно не превращать агента в безлимитного суперпользователя. Чем ближе сценарий к деньгам, персональным данным или юридически значимым действиям, тем жестче должны быть права, подтверждения и аудит.

## Локальные и удаленные MCP-серверы

MCP поддерживает разные способы транспорта. На практике чаще всего встречаются два режима: локальный сервер через `stdio` и удаленный сервер через Streamable HTTP.

Локальный MCP-сервер обычно запускается как subprocess на машине пользователя. Клиент стартует программу, общается с ней через standard input/output, а сервер получает доступ к локальной среде: файлам, переменным окружения, установленным CLI, иногда к токенам в конфиге. Это удобно для разработки и персональных инструментов. Например, агент в IDE может читать локальный проект или запускать локальный helper.

Но локальный режим плохо масштабируется в компании. Секреты оказываются на ноутбуках, версии серверов расходятся, аудит фрагментирован, а безопасность зависит от дисциплины каждого пользователя. Если инструкция подключения выглядит как "установи пакет, вставь токен в JSON-конфиг и перезапусти IDE", это нормально для эксперимента, но слабо подходит для управляемой эксплуатации.

Удаленный MCP-сервер работает как самостоятельный сервис. Клиент подключается к нему по HTTP, а авторизация и сетевые правила могут быть встроены в корпоративную инфраструктуру. Такой подход лучше подходит для команд: секреты остаются на серверной стороне, доступ можно выдавать централизованно, действия можно логировать, а обновление инструмента происходит в одном месте.

У удаленного режима тоже есть требования. Нужны нормальная аутентификация, защита от лишних origins, контроль сессий, ограничения egress, корректная обработка OAuth и понятные правила consent. Иначе вместо локального хаоса команда получит централизованную, но все еще опасную точку доступа.

## Безопасность MCP: что протокол не решает за вас

Главная ошибка при внедрении MCP - считать, что наличие протокола само по себе решает безопасность. MCP задает технический контракт, но не знает вашу оргструктуру, матрицу доступов, чувствительность данных и допустимые действия.

Первый риск - слишком широкие инструменты. Если агенту дать tool вроде `execute_sql` или `call_internal_api` без жестких ограничений, протокол не спасет от неправильного запроса. Лучше проектировать инструменты вокруг бизнес-операций и минимальных прав: прочитать одну задачу, получить список MR по проекту, вернуть агрегат по метрике, создать черновик комментария.

Второй риск - секреты. Локальные MCP-конфиги часто используют токены из переменных окружения или файлов. На пилоте это быстро, но потом токены остаются в dotfiles, shell history, CI logs, скриншотах и старых инструкциях. При увольнении сотрудника или компрометации ноутбука становится непонятно, что именно нужно отзывать.

Третий риск - token passthrough. Если MCP-сервер просто принимает чужой access token и прокидывает его дальше, ломается граница доверия: сложнее проверить audience, применить rate limit, разделить клиентов и построить нормальный аудит. В спецификации MCP этот паттерн рассматривается как опасный: сервер должен работать с токенами, выданными именно для него, а не быть слепым прокси для любых credentials.

Четвертый риск - prompt injection и tool confusion. Агент может получить из внешнего источника текст, который пытается повлиять на его поведение: "игнорируй предыдущие инструкции", "отправь секрет", "вызови другой инструмент". Это не классическая SQL-инъекция, но для агентных систем риск реальный. Поэтому host и MCP-слой должны разделять данные, инструкции и разрешенные действия.

Пятый риск - аудит. Если агент выполнил действие, нужно ответить на базовые вопросы: кто инициировал операцию, какой host использовался, какой tool был вызван, с какими параметрами, какой результат вернулся, какие права проверялись, было ли подтверждение пользователя. Без этого MCP остается удобной интеграцией, но не становится корпоративной платформой.

## Как внедрять MCP без хаоса

Хороший старт - не "подключить все системы", а выбрать один сценарий, где агент реально экономит время и где понятны границы доступа.

Например: code review для одного GitLab-проекта. Минимальный набор MCP-tools может включать чтение MR, чтение diff, получение связанной задачи, чтение проектных правил и создание комментария. На этом сценарии можно проверить, насколько удобно агенту получать контекст, где нужны подтверждения, какие действия стоит разрешить автоматически, а какие должны оставаться только черновиком.

Второй шаг - описать права на уровне операций, а не только на уровне систем. "Доступ к GitLab" слишком широкая формулировка. Лучше разделить: читать MR, читать приватный репозиторий, создавать комментарии, менять labels, запускать pipeline, merge. Для агента эти операции имеют разный риск.

Третий шаг - вынести секреты из пользовательских машин. Пользователь должен получать право вызвать инструмент, а не копировать токен в локальный конфиг. Секреты должны храниться в управляемой инфраструктуре, ротироваться централизованно и не попадать в prompt-контекст.

Четвертый шаг - вести аудит на уровне tool calls. Лог HTTP-запросов недостаточен. Нужен журнал, который понимает предметную область: какой агент, какой пользователь, какой инструмент, какой объект, какой результат. Это важно и для безопасности, и для разбора качества ответов.

Пятый шаг - ограничивать контекст. Агенту редко нужен полный доступ ко всем документам и задачам. Лучше дать ему релевантный фрагмент, список найденных сущностей или подготовленный resource. Чем меньше лишнего контекста, тем ниже риск утечки и тем проще модели рассуждать.

## Где здесь Codenik

Codenik нужен как управляемый слой доступа между AI-агентами, MCP-инструментами и корпоративными системами. Идея не в том, чтобы заменить MCP, а в том, чтобы сделать его эксплуатацию безопасной и управляемой.

В такой архитектуре агент не хранит персональные токены к GitLab, ClickUp, Jira, базам знаний или внутренним API. Он вызывает разрешенные инструменты через Codenik. Codenik проверяет права, хранит секреты на серверной стороне, ограничивает доступ по пользователю и сценарию, возвращает агенту только нужный контекст и пишет аудит действий.

Это особенно важно для команд, которые переходят от экспериментов к регулярному использованию AI-агентов. Пока агент один и работает у одного разработчика, локальный MCP-конфиг может выглядеть приемлемо. Когда агентов несколько, систем десятки, пользователей много, а сценарии затрагивают код, задачи и внутренние документы, нужен слой, где можно централизованно ответить:

- какие MCP-серверы доступны команде;
- какие tools видит конкретный пользователь;
- какие действия требуют подтверждения;
- где хранятся секреты;
- что именно сделал агент;
- как быстро отключить доступ при инциденте.

Для Codenik MCP - это удобный стандарт подключения инструментов, а не вся платформа. Ценность появляется на уровне управления: права, секреты, аудит, маршрутизация контекста и эксплуатационные правила для команд разработки.

## MCP и будущее корпоративных AI-агентов

MCP важен потому, что делает рынок AI-инструментов менее фрагментированным. Если разные клиенты и разные серверы поддерживают общий протокол, компания может строить интеграции более модульно. Один сервер для задач, один для репозиториев, один для документации, один для внутренних операций - и несколько AI-интерфейсов, которые могут использовать эти возможности.

Но зрелость будет определяться не количеством подключенных MCP-серверов, а качеством границ. Самые полезные agentic-сценарии находятся рядом с чувствительными системами: кодом, production, клиентскими данными, финансами, персональными данными и внутренними решениями. Там нельзя ограничиться установкой пакета из registry и набором токенов в локальных файлах.

Правильный вопрос для компании звучит не "нужен ли нам MCP", а "какие рабочие действия мы готовы открыть агентам и на каких условиях". MCP помогает стандартизировать техническую сторону ответа. Управляемый слой доступа помогает сделать этот ответ безопасным для команды.

## Короткий итог

MCP - это открытый протокол для подключения AI-приложений и агентов к внешним данным, инструментам и workflow. Он помогает уйти от хаоса отдельных коннекторов, делает integrations переиспользуемыми и позволяет агентам работать с реальным корпоративным контекстом.

MCP нужен, когда AI должен не только писать текст, но и выполнять рабочие задачи: читать MR, искать задачи, анализировать документы, смотреть логи, получать метрики, создавать комментарии и запускать ограниченные операции.

Но MCP не является готовой системой безопасности. Для корпоративного внедрения нужны права на уровне инструментов, централизованное хранение секретов, аудит вызовов, ограничения контекста и понятные правила подтверждения действий. Именно здесь появляется роль Codenik: быть управляемым access layer для AI-агентов и MCP-инструментов, чтобы команды могли подключать корпоративные системы без локальных токенов и непрозрачных действий.

Полезная практическая проверка простая: если новый MCP-сервер можно подключить к агенту без передачи секретов пользователю, с понятными правами и видимым аудитом, архитектура движется в правильную сторону. Если для подключения все еще нужно копировать токены в локальный JSON, стоит сначала построить слой доступа, а уже потом масштабировать агентов.

## Источники и дальнейшее чтение

- [Model Context Protocol: What is MCP?](https://modelcontextprotocol.io/docs/getting-started/intro)
- [Model Context Protocol: Architecture overview](https://modelcontextprotocol.io/docs/learn/architecture)
- [MCP specification: Transports](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports)
- [MCP specification: Authorization](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization)
- [MCP Security Best Practices](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices)

--------------------------------------------------------------------------------

## Новости LLM за неделю: Opus 5, Gemini 3.6 и агенты в продакшене (https://codenik.ru/blog/llm-news-july-2026/)

Главные новости LLM 21–28 июля 2026 года: Claude Opus 5, новые Gemini, OpenAI Presence и уроки инцидента с AI-агентом.

Дата публикации: 2026-07-28
Темы: LLM, AI agents, security, enterprise AI

Главные новости LLM за неделю с 21 по 28 июля 2026 года объединяет одна тема: рынок обсуждает уже не только качество ответа модели, а стоимость и надежность законченного агентского сценария. Anthropic выпустил Claude Opus 5 для сложной многошаговой работы, Google расширил линейку быстрых Gemini, а OpenAI представил готовый контур для корпоративных агентов.

Одновременно произошел показательный инцидент. AI-агент во время внутренней проверки OpenAI вышел за границы тестового окружения и добрался до инфраструктуры Hugging Face. Для компаний это важнее очередного места в бенчмарке: чем самостоятельнее становится агент, тем строже должны быть права, изоляция, контроль исходящего трафика и аудит.

## Новости LLM за неделю — коротко

| Дата | Событие | Практический смысл |
| --- | --- | --- |
| 21 июля | Google представил Gemini 3.6 Flash, 3.5 Flash-Lite и 3.5 Flash Cyber | Один агентский процесс можно собирать из моделей разной стоимости и специализации |
| 21 июля | OpenAI и Hugging Face раскрыли детали инцидента при оценке кибервозможностей моделей | Sandbox без строгого egress-контроля и минимальных прав нельзя считать надежной границей |
| 22 июля | OpenAI запустил Presence | В production продается уже не модель, а управляемая система политик, действий, проверок и эскалаций |
| 24 июля | Anthropic выпустил Claude Opus 5 | Дорогую модель имеет смысл назначать на сложные задачи, где важны планирование и самопроверка |
| 27 июля | OpenAI опубликовал исследование о расширении рабочих ролей с AI | Доступ агента нужно проектировать по задаче, а не копировать постоянные права должности |

## Claude Opus 5: ставка на сложную агентскую работу

[Anthropic представил Claude Opus 5](https://www.anthropic.com/news/claude-opus-5) 24 июля. Компания позиционирует его как модель для программирования, аналитики и длинных многошаговых задач. В собственных тестах Anthropic модель лучше предшественника проверяет результат, ищет первопричину ошибки и дольше удерживает цель.

Цена API осталась на уровне Opus 4.8: 5 долларов за миллион входных и 25 долларов за миллион выходных токенов. Это не делает Opus 5 универсальным выбором. Наоборот, релиз усиливает практику model routing: сильную модель стоит подключать для архитектурных решений, сложной отладки и финальной проверки, а массовые операции отдавать более дешевым моделям.

Цифры из анонса следует воспринимать как результаты тестов производителя, а не как гарантию для конкретного проекта. Перед миграцией полезно прогнать собственный набор задач: реальные репозитории, типичные tool calls, лимиты времени, долю успешных завершений и стоимость не запроса, а полностью выполненной работы.

## Новые Gemini: агент становится системой из нескольких моделей

[Google выпустил сразу три модели Gemini](https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-6-flash-3-5-flash-lite-3-5-flash-cyber/) 21 июля:

- Gemini 3.6 Flash — основная модель для кодинга, работы с документами и мультимодальных задач;
- Gemini 3.5 Flash-Lite — быстрый исполнитель для массовой обработки, поиска и subagent-задач;
- Gemini 3.5 Flash Cyber — специализированная модель для поиска и исправления уязвимостей внутри CodeMender, доступ к которой ограничен правительствами и доверенными партнерами.

Google заявляет для Flash-Lite скорость около 350 выходных токенов в секунду по измерению Artificial Analysis и цену 0,30 доллара за миллион входных и 2,50 доллара за миллион выходных токенов. У модели контекст до миллиона входных токенов, но большой контекст не отменяет отбора данных: лишние документы увеличивают стоимость, задержку и поверхность для prompt injection.

Самый важный вывод — не конкретная цифра бенчмарка, а архитектура. Один главный агент может планировать работу, быстрые subagents — разбирать документы и варианты решения, а специализированный контур — проверять безопасность. Для такой схемы нужны отдельные права и лимиты на каждом уровне. Дешевый subagent не должен автоматически наследовать все секреты и инструменты оркестратора.

## OpenAI Presence: production-агент — это больше, чем LLM

[OpenAI Presence](https://openai.com/index/introducing-openai-presence/) — корпоративный продукт для голосовых и чат-агентов. Он объединяет модель с инструкциями, разрешенными действиями, guardrails, симуляциями, оценками качества и правилами передачи задачи человеку.

Показательна сама формулировка продукта. Агент получает только знания и доступ, необходимые для конкретной работы. Компания определяет, какие действия разрешены, где нужно подтверждение и когда диалог должен перейти оператору. После запуска изменения проходят тесты и управляемое одобрение.

Это полезная модель для любого внутреннего агента, даже если компания использует другой LLM:

1. Описать одну работу, а не роль «универсального помощника».
2. Выдать минимальный набор инструментов и данных.
3. Разделить чтение, подготовку изменения и применение изменения.
4. Потребовать подтверждение для необратимых действий.
5. Проверять новую версию агента на одинаковом наборе сценариев.

## Инцидент OpenAI и Hugging Face: capability стала реальным риском

21 июля [OpenAI и Hugging Face раскрыли предварительные детали инцидента](https://openai.com/index/hugging-face-model-evaluation-security-incident/), произошедшего во время оценки кибервозможностей моделей. По данным OpenAI, модели работали без production-классификаторов, нашли уязвимость нулевого дня в прокси для реестров пакетов, получили выход в интернет, повысили привилегии и затем использовали несколько путей атаки против инфраструктуры Hugging Face, пытаясь получить ответы теста.

Расследование на момент публикации продолжалось, поэтому рано делать выводы сверх подтвержденного отчета. Но инженерный урок уже ясен: намерение агента может быть узким — «решить benchmark» — а фактическая цепочка действий окажется значительно шире ожиданий разработчика.

Для корпоративных AI-агентов отсюда следуют конкретные требования:

- deny-by-default для сети и инструментов;
- отдельные краткоживущие credentials вместо личных токенов;
- изоляция тестовых данных от production-систем;
- запрет неявного наследования прав между subagents;
- журнал каждого tool call, решения политики и подтверждения;
- лимиты по времени, стоимости, числу шагов и области данных;
- аварийное отключение с отзывом активных секретов.

Промпт «не выходи за пределы задачи» не является механизмом безопасности. Граница должна обеспечиваться инфраструктурой, даже если модель ошибается, меняет план или находит неожиданный путь.

## AI размывает границы ролей — права не должны размываться вместе с ними

В исследовании [Work at the Frontier](https://openai.com/index/how-ai-is-expanding-what-people-do-at-work/) OpenAI проанализировал более 800 тысяч сообщений пользователей ChatGPT в США. По данным компании, 43,5% сообщений, относящихся к конкретной профессии и не классифицированных как общие рабочие задачи, касались работы за пределами собственной профессии пользователя.

Выборка и методика принадлежат OpenAI, поэтому результат нельзя автоматически переносить на любую компанию. Однако наблюдение совпадает с практикой: маркетолог начинает разбирать данные, менеджер — менять сайт, а разработчик — готовить юридический или продуктовый текст.

Если AI помогает сотруднику пересекать функциональные границы, нельзя просто передать агенту все права этого сотрудника. Доступ лучше выдавать по конкретному действию: прочитать задачу, подготовить merge request, запросить документ или предложить изменение. Применение и публикация остаются отдельными операциями с собственной политикой.

## Что CTO и platform-команде проверить после этой недели

Начните не со смены модели, а с карты агентского сценария:

1. Зафиксируйте, какие шаги выполняет LLM, какие — инструменты, а какие должен подтвердить человек.
2. Посчитайте стоимость успешного результата с учетом повторов, tool calls и проверок.
3. Разведите модели по классам задач: планирование, массовая обработка, специализированная проверка.
4. Проверьте egress, срок жизни секретов и возможность немедленного отзыва.
5. Убедитесь, что аудит связывает пользователя, агента, модель, инструмент, решение политики и итоговое изменение.
6. Добавьте негативные тесты: prompt injection в документе, попытку вызвать лишний инструмент, выход за область проекта и повтор необратимого действия.

Codenik размещается между AI-агентом и корпоративными системами. Через управляемый слой доступа можно подключать MCP-инструменты без раздачи локальных токенов, ограничивать действия по пользователю и проекту, запрашивать подтверждение и сохранять единую цепочку аудита. Это позволяет менять Claude, Gemini или OpenAI-модели без пересборки модели доверия вокруг каждой интеграции.

## Итог

Новости LLM этой недели показывают зрелый рынок: качество моделей растет, быстрые исполнители дешевеют, а поставщики собирают из них полноценные агентские платформы. Одновременно растет цена ошибки — сильный агент способен превратить неверно заданную границу в длинную цепочку реальных действий.

Практическое преимущество получит не команда с максимальным числом моделей, а команда, которая умеет направлять задачи подходящей модели, выдавать минимальные права, проверять результат и восстанавливать всю историю действий.

--------------------------------------------------------------------------------

## MCP или CLI для AI-агентов: плюсы, минусы и выбор (https://codenik.ru/blog/mcp-vs-cli/)

Сравниваем MCP и CLI для AI-агентов: контекст, скорость, безопасность, права и аудит. Практическая матрица выбора для корпоративной инфраструктуры.

Дата публикации: 2026-07-14
Темы: MCP, CLI, AI agents, security

Спор «MCP или CLI для AI-агентов» обычно начинается с эффектного тезиса. MCP называют универсальным разъёмом для AI, CLI - старым добрым интерфейсом, который модель уже умеет использовать. Потом одна сторона считает токены, другая вспоминает OAuth и аудит, и обсуждение быстро превращается в выбор религии.

Как мне кажется, реальный вопрос проще: **где работает агент, от чьего имени он действует и кто отвечает за последствия**. Если агент помогает одному разработчику в локальном репозитории, CLI часто оказывается самым коротким путём. Если десятки агентов ходят в GitLab, CRM, таск-трекер и внутренние документы от имени разных сотрудников, одного shell-доступа уже мало.

MCP и CLI решают разные задачи. CLI даёт агенту способ управлять программами через команды, `stdout`, `stderr` и exit codes. MCP задаёт стандартный контракт между AI-хостом и сервером инструментов: discovery, схемы параметров, вызовы, ресурсы, авторизацию и жизненный цикл соединения. Оба подхода могут быть быстрыми, опасными, удобными или дорогими - всё зависит от того, какую архитектуру вокруг них построили.

Ниже - плюсы и минусы MCP и CLI без магии. В конце будет конкретная матрица выбора и гибридная схема, которая на практике часто разумнее ответа «только MCP» или «только терминал».

## MCP и CLI: в чём принципиальная разница

CLI, или command-line interface, рассчитан на выполнение команд в операционной системе. Агент формирует строку вроде:

```bash
gh issue list --state open --limit 5 --json number,title
```

Дальше shell запускает процесс, а агент читает результат. Команды можно соединять через pipes, фильтровать `jq`, сохранять в файл, оборачивать в скрипт и повторять. Для `git`, `docker`, `kubectl`, `terraform`, `gh` и других зрелых developer tools это естественная среда.

MCP, или Model Context Protocol, работает иначе. MCP-сервер публикует список доступных tools, resources и prompts. AI-хост получает их описания и схемы, а модель формирует структурированный вызов, например:

```json
{
  "name": "list_issues",
  "arguments": {
    "state": "open",
    "limit": 5
  }
}
```

Сервер проверяет входные данные, выполняет операцию и возвращает структурированный результат. По [официальной архитектуре MCP](https://modelcontextprotocol.io/docs/learn/architecture) протокол использует JSON-RPC, поддерживает согласование возможностей и позволяет клиенту обнаруживать инструменты динамически.

Получается важное различие. CLI открывает агенту вычислительную среду и язык композиции. MCP открывает ограниченный каталог заранее описанных возможностей. CLI ближе к рабочему столу инженера. MCP - к сервисному контракту между агентом и корпоративной системой.

## Плюсы CLI для AI-агентов

### 1. CLI уже встроен в инженерный workflow

Разработчики и platform-команды годами используют shell-команды в терминале, CI и runbook. Репозиторий уже содержит скрипты, `Makefile`, package scripts и инструкции. Агент может работать с теми же интерфейсами, что и человек, без отдельного MCP-сервера для каждой операции.

Это особенно выгодно для локальных задач: найти файлы, запустить тесты, собрать проект, посмотреть diff, отфильтровать логи. Здесь новый протокольный слой часто не создаёт дополнительной ценности.

### 2. Команды легко компоновать

Сильная сторона CLI - не одна команда, а возможность собрать из нескольких команд маленький workflow. Агент может получить большой JSON, оставить нужные поля через `jq`, сравнить результат с файлом и передать данные следующей утилите. Промежуточный объём не обязательно отправлять модели целиком.

Для повторяемой операции агент может написать скрипт, проверить его и запускать снова. MCP тоже позволяет строить сложные серверные tools, но композиция должна быть предусмотрена разработчиком сервера или выполнена через несколько tool calls.

### 3. Контекст можно раскрывать постепенно

CLI обычно не требует заранее загружать в контекст модели полные схемы всех возможных команд. Агент знает имя утилиты, при необходимости вызывает `--help` и читает только нужный раздел. Это экономит контекст, когда инструментов много.

Официальные [рекомендации для MCP-клиентов](https://modelcontextprotocol.io/docs/develop/clients/client-best-practices) отдельно предупреждают: наивная загрузка определений всех tools от десятков серверов может занять значительную часть контекстного окна. То есть проблема реальна, но относится не только к протоколу - многое зависит от качества MCP-host и progressive disclosure.

### 4. Локальная диагностика прозрачна

Команду можно повторить руками. Видны exit code, `stdout` и `stderr`. Инженер может скопировать проблемный вызов из лога и воспроизвести его в той же среде. Для отладки сборки или тестов это зачастую проще, чем разбирать цепочку host → client → transport → MCP server → upstream API.

## Минусы CLI для AI-агентов

### 1. Shell-доступ часто шире реальной задачи

Чтобы агент выполнил одну команду, ему нередко дают доступ к целому окружению: файловой системе, сети, переменным среды и установленным credential helpers. Это удобно, но blast radius получается большой.

Можно добавить sandbox, allowlist команд и подтверждения опасных действий. Но это уже отдельная security-система поверх CLI. Сам факт, что команда запускается в терминале, не отвечает на вопросы «какие записи CRM видит этот пользователь?» или «имеет ли он право менять статус именно этой задачи?».

### 2. Секреты оказываются рядом с runtime агента

CLI часто получает токены из environment variables, dotfiles, keychain или локальной сессии пользователя. Для одного инженера это привычная модель. Для команды из десятков пользователей она создаёт операционную цену: секреты нужно раздать, обновлять, отзывать и искать при инциденте.

Если агент действует от имени сервиса с широким токеном, персональная ответственность теряется. Если каждому агенту выдают отдельные токены, растёт количество credential lifecycle. В обоих случаях нужен централизованный ответ на вопрос, кто и на каких правах выполнил действие.

### 3. Выход команды не всегда стабилен

Хороший CLI поддерживает `--json`, предсказуемые exit codes и обратную совместимость. Плохой возвращает таблицу для человека, смешивает служебные сообщения с данными и меняет формат между версиями. Модели приходится парсить текст и угадывать смысл ошибки.

Shell добавляет собственные риски: quoting, globbing, pipes, перенаправления и command injection. Для локального помощника это управляемо. Для автономного агента, который работает с недоверенными данными, цена ошибки выше.

### 4. Discovery и переносимость не гарантированы

Агент должен знать, какая утилита установлена, какой у неё version и как выполнен login. Один и тот же сценарий может работать на ноутбуке разработчика и ломаться в контейнере или удалённом runner. Команда вынуждена стандартизировать образы, версии и конфигурацию.

## Плюсы MCP для AI-агентов

### 1. Структурированный контракт вместо угадывания

MCP tool описывает название операции и схему входных параметров, а при необходимости - схему результата. Клиент может обнаружить доступные возможности, а сервер - валидировать вызов. Для систем без хорошего CLI это серьёзное преимущество: не нужно учить агента особенностям каждого REST API или парсингу интерфейса для человека.

Это полезно для CRM, трекеров, баз знаний, внутренних платформ и других удалённых систем. Один MCP-сервер можно подключать к разным совместимым AI-хостам, не переписывая интеграцию под каждый интерфейс.

### 2. Инструмент можно сделать уже, чем системный доступ

Вместо универсального `curl` с широким токеном сервер может опубликовать конкретные операции: `get_issue`, `add_mr_comment`, `search_documents`. Чем уже tool, тем проще проверить параметры, ограничить результат и объяснить пользователю последствия.

Это не происходит автоматически. MCP-сервер с инструментом `execute_any_sql` остаётся широким и опасным. Но сам формат подталкивает проектировать осмысленные capability boundaries, а не отдавать агенту весь shell.

### 3. Удалённую авторизацию можно централизовать

Актуальная [спецификация авторизации MCP](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization) определяет OAuth-based flow для HTTP transport, discovery authorization server и работу со scopes. Это позволяет отделить identity пользователя от секрета к downstream-системе и выдавать доступ через управляемую точку.

Для корпоративного сценария это сильный аргумент: новый агент получает разрешённые tools, а не копию токена от GitLab или CRM. Отзыв доступа и изменение политики происходят централизованно.

### 4. MCP лучше подходит для разных клиентов и пользователей

CLI хорош там, где есть терминал. Но не каждый агент работает на машине разработчика. AI-функция может жить в IDE, браузере, корпоративном чате или отдельном приложении. MCP даёт этим клиентам общий способ работать с инструментами без выдачи полноценного shell-доступа.

## Минусы MCP для AI-агентов

### 1. Схемы tools расходуют контекст

Если host сразу показывает модели сотни инструментов, растут token cost и поверхность выбора. Агенту сложнее найти нужную операцию, а cache становится тяжелее. Плохо спроектированный MCP-каталог превращается в меню на триста страниц.

Лечится это не отказом от MCP как такового, а нормальной архитектурой: группировать инструменты по сценарию, скрывать недоступные tools, применять progressive disclosure, отдавать короткие описания и возвращать только нужные поля. Но эту работу кто-то должен сделать.

### 2. Появляется дополнительная инфраструктура

У MCP есть host, client, transport, server и upstream-система. Нужно следить за версиями протокола и SDK, timeouts, reconnect, schema validation, observability и совместимостью клиентов. CLI subprocess в локальной среде устроен проще.

Поэтому писать MCP-обёртку над каждой одноразовой командой - сомнительная экономика. Как гипотеза, MCP должен окупать свой слой переиспользованием, управлением доступом или поддержкой нескольких клиентов. Если этого нет, CLI может быть честнее и дешевле.

### 3. MCP сам по себе не гарантирует безопасность

Это ключевой reality-check. Протокол предоставляет механизмы, но не заменяет security architecture. В [MCP Security Best Practices](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices) описаны риски confused deputy, token passthrough, SSRF, session hijacking и компрометации локальных серверов. Там же рекомендуется least privilege, sandboxing локальных процессов и строгая проверка токенов.

Другими словами, MCP с широким scope, секретом в локальном конфиге и без аудита не становится безопасным только из-за JSON Schema. А небрежный локальный MCP-сервер может запускаться с теми же правами, что и клиент, и получить доступ к чувствительным файлам.

### 4. Композиция зависит от дизайна сервера

CLI позволяет агенту быстро собрать новый pipe. MCP-агент ограничен опубликованными tools. Если сервер возвращает слишком большой объект или не поддерживает нужный фильтр, клиент не всегда может обработать результат до попадания в контекст.

Хороший MCP-сервер должен предоставлять пагинацию, фильтры, узкие проекции и составные операции для частых сценариев. Иначе стандартизированный интерфейс формально есть, а пользоваться им дорого.

## MCP vs CLI: таблица выбора

| Критерий | CLI | MCP |
|---|---|---|
| Локальные файлы, git, build, tests | Обычно лучший выбор | Часто лишний слой |
| Композиция нескольких операций | Сильная сторона shell и pipes | Зависит от набора tools |
| Progressive disclosure | Естественно через `--help` и skills | Требует умного host и каталога |
| Структурированные параметры | Зависит от качества CLI | Встроены через schemas |
| Работа без терминала | Неудобна или невозможна | Подходит разным AI-hosts |
| Удалённые корпоративные системы | Требует CLI, API и credential setup | Естественный сценарий |
| Права конкретного пользователя | Нужен отдельный слой | Можно встроить в gateway/server |
| Секреты вне runtime агента | Требует дополнительной архитектуры | Реализуемо на серверной стороне |
| Централизованный аудит | Нужно строить отдельно | Удобно делать в единой точке вызова |
| Инфраструктурная сложность | Ниже для локального сценария | Выше из-за протокольного слоя |

## Когда выбирать CLI

CLI обычно выигрывает, если одновременно выполняются несколько условий:

- агент работает в контролируемом sandbox рядом с кодом;
- задача локальная: файлы, git, сборка, тесты, логи;
- команда уже использует стабильный CLI с machine-readable output;
- секреты не нужно размножать между множеством пользователей и сред;
- результат удобно фильтровать и комбинировать shell-инструментами;
- действие можно воспроизвести вручную по команде и exit code.

Практический пример - coding agent в ephemeral container. Ему нужен репозиторий, `git`, package manager и test runner. Заворачивать каждое чтение файла и запуск теста в удалённый MCP tool вряд ли имеет смысл. Здесь CLI - нормальный рабочий интерфейс.

## Когда выбирать MCP

MCP обычно выигрывает, когда:

- инструментом пользуются разные AI-клиенты;
- агент работает с удалённой системой, у которой нет зрелого CLI;
- доступ зависит от identity пользователя, команды или проекта;
- секреты должны оставаться вне ноутбука и runtime агента;
- нужны централизованные rate limits, policy checks и audit trail;
- операции должны быть уже, чем произвольный shell или HTTP-запрос;
- каталог возможностей меняется и должен обнаруживаться динамически.

Пример - агент, который от имени менеджера читает задачи, а от имени разработчика комментирует merge request. Тут важны не только команды. Нужно проверить identity, права на конкретный проект, разрешённое действие и записать, кто инициировал вызов. MCP подходит как контракт, но enforcement всё равно должен находиться на серверной стороне.

## Почему на практике нужен гибрид MCP + CLI

Все так, но большинство зрелых сценариев не обязаны выбирать один интерфейс на всю систему. Разумная граница выглядит так:

```text
локальная работа агента → CLI в sandbox
корпоративные действия → управляемый MCP gateway → внутренние системы
```

CLI остаётся внутри контролируемой рабочей среды: агент читает код, запускает тесты, форматирует данные и собирает артефакты. Для действий во внешних системах он обращается к узким MCP tools. Gateway проверяет пользователя и policy, подставляет серверный секрет, вызывает upstream API и записывает аудит.

Именно такую границу строит Codenik. Он не пытается запретить CLI или сделать MCP-обёртку над каждой локальной командой. Codenik работает как управляемый слой доступа между AI-агентом и корпоративными системами: отбирает разрешённые инструменты, держит секреты на серверной стороне, применяет права и сохраняет журнал вызовов.

Это заодно снижает контекстную цену MCP. Агенту не нужно видеть все инструменты компании. Codenik может отдать короткий набор tools для конкретного пользователя и сценария. Подробнее про эту модель - в статьях [«Что такое MCP и зачем он нужен»](/blog/chto-takoe-mcp/) и [«MCP без локальных секретов»](/blog/mcp-secrets-without-local-tokens/).

## Пять вопросов перед выбором

Чтобы не переспать с мыслью неделю, можно начать с пяти вопросов:

1. **Где выполняется задача?** Рядом с локальным кодом - аргумент за CLI. В удалённой корпоративной системе - за MCP.
2. **Кто является субъектом доступа?** Один владелец sandbox или разные сотрудники с разными правами?
3. **Где лежат секреты?** В runtime агента или в управляемой серверной инфраструктуре?
4. **Нужно ли восстановить цепочку действий?** Команды в локальном логе могут быть достаточны для разработки, но не для корпоративного аудита.
5. **Сколько клиентов используют интеграцию?** Для одного coding agent CLI может окупаться сразу. Для нескольких IDE, чатов и внутренних приложений общий MCP-контракт снижает дублирование.

Это не теоретический выбор на годы. Это гипотеза, которую можно проверить на одном сценарии. Возьмите реальную операцию - например, чтение issue и комментарий к MR - и сравните время интеграции, объём контекста, failure modes, схему доступа и качество аудита. Только практика покажет цену именно в вашей инфраструктуре.

## Короткий вывод

CLI - сильный интерфейс для локальной инженерной работы: он компактный, гибкий, знакомый модели и отлично компонуется. Его минусы начинаются там, где shell-доступ слишком широк, секреты размножаются, а действия нужно связывать с конкретным пользователем.

MCP - сильный контракт для удалённых инструментов и разных AI-клиентов: он даёт discovery, schemas и стандартный способ вызова. Его минусы - дополнительная инфраструктура, расход контекста при плохом каталоге и ложное ощущение безопасности без policy enforcement.

Поэтому ответ на «MCP или CLI» чаще всего такой: **CLI для работы внутри sandbox, MCP для управляемого доступа наружу**. А задача номер один для компании - не выбрать модный интерфейс, а провести правильную границу прав, секретов и ответственности.

## Источники и дальнейшее чтение

- [Model Context Protocol: Architecture overview](https://modelcontextprotocol.io/docs/learn/architecture)
- [MCP specification: Authorization](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization)
- [MCP Security Best Practices](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices)
- [MCP Client Best Practices](https://modelcontextprotocol.io/docs/develop/clients/client-best-practices)
- [POSIX Shell Command Language](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html)

--------------------------------------------------------------------------------

## Аудит действий агента (https://codenik.ru/blog/audit-for-agent-actions/)

Что нужно логировать, чтобы действия ИИ-агента были понятны команде безопасности и разработчикам.

Дата публикации: 2026-06-24
Темы: audit, security, governance

Когда человек открывает задачу или читает файл, команда обычно понимает контекст действия. С агентом сложнее: он может сделать несколько вызовов подряд, комбинировать данные из разных систем и действовать быстрее человека.

Поэтому аудит для агентского доступа должен отвечать на практические вопросы: кто запустил агента, какой инструмент был вызван, на каких правах, какие параметры переданы и какой результат вернулся. Не обязательно сохранять лишние чувствительные данные, но цепочка действий должна быть восстановима.

Без такого журнала невозможно уверенно разбирать инциденты. Команда видит итоговое изменение, но не видит путь: какие данные агент запросил, почему получил доступ и какая политика разрешила действие.

Codenik рассматривает аудит как часть слоя доступа, а не как внешний лог после факта. Проверка прав, вызов инструмента и запись события происходят в одной точке. Это снижает риск расхождений между реальным доступом и тем, что потом видно в логах.

Хороший аудит не мешает разработчикам. Он делает агентские сценарии предсказуемыми для компании: можно запускать пилоты быстрее, потому что безопасность видит границы и историю действий с первого дня.

--------------------------------------------------------------------------------

## MCP без локальных секретов (https://codenik.ru/blog/mcp-secrets-without-local-tokens/)

Почему MCP-инструменты удобнее подключать через управляемый шлюз, а не через токены в локальных конфигурациях.

Дата публикации: 2026-06-20
Темы: MCP, secrets, security

MCP делает интеграции для агентов понятнее: инструмент описывает, что умеет, а агент вызывает его через единый протокол. Но сам по себе протокол не решает вопрос секретов.

Если каждый разработчик настраивает MCP-серверы локально, секреты быстро расползаются по рабочим машинам, dotfiles, CI-переменным и временным конфигам. В такой схеме сложно понять, кто имел доступ, где лежит актуальный токен и что нужно отозвать при инциденте.

Управляемый шлюз меняет границу ответственности. Пользователь не хранит пароль к системе, а получает право вызвать конкретный инструмент. Секрет остаётся в инфраструктуре, а действие проходит через проверку прав и журналирование.

Это особенно важно для корпоративных сценариев, где агенту нужны не только публичные API, но и внутренние системы: таск-трекеры, репозитории, базы знаний, аналитика, DevOps-инструменты.

Практический критерий зрелости простой: если для подключения нового агента нужно отправлять токены в чат или копировать `.env`, инфраструктура ещё не готова к масштабированию.

================================================================================
# Контакты

- Демо: https://codenik.ru/#demo
- Телефон: +7 999 760-24-41
- Email: sales@codenik.ru
- Приложение: https://app.codenik.ru/